All Products: Login Delays or Failures Caused by Timeouts

Symptoms

• ERROR: "Session not authorized" message attempting to log into a terminal.

• Subsequent login attempt is successful.

• Delay during terminal login, with or without error message.

• Timeout error logging into Pharos Print Center.

Environment

• Pharos Systems Blueprint Enterprise 5.0

• Pharos Systems Blueprint Enterprise 5.1

• Pharos Systems Blueprint Enterprise 5.2 R1

• Pharos Systems Blueprint Enterprise 5.2 R2

• Pharos Systems Uniprint 9.0

• Pharos Systems Uniprint 9.1

• Pharos Systems MobilePrint 2.x

Cause

To provide our customers the safety and security of verified and trusted applications, Pharos Systems digitally signs, via a trusted Certificate Authority, our applications and DLLs and registers them with Microsoft. In many cases, signed applications run normally on the operating system because Windows itself does not check, nor validate, the signature. However, applications which run under .NET (like most of ours) can be an exception, and .Net can request signature validation, and this requires an expensive network-based request. Part of this network request will attempt to contact the Certificate Authority owner and Microsoft to determine if the certificate has been revoked by looking at a Certificate Revocation List (the "CRL"). In many cases, the server hosting the Pharos software is unable to reach an external network (VLAN rules, Internet proxy server restrictions, etc.), and so the request eventually times out.

However, this check for the CRL -- and its eventual time out -- occurs during the authentication component of the user's terminal session, and so contributes to the "Inactivity Timeout" or delay associated with the terminal login. This causes the error message observed on the terminal's display, or just a long login time. The subsequent log in (and log in attempts for the next several minutes) are successful because .Net temporarily "remembers" that it was not able to verify the signature for a short time and chooses not to validate the signature during that time.

Resolution

Microsoft Windows provides, via Group Policy Object, a way to manage certificate checking for systems not able to connect to the Internet. This is described in Microsoft KB article 2677070. The following extract of this article describes the "how to" process to disable the network check.

If you cannot avoid installing this update on disconnected systems, you can disable the network retrieval of the trusted and untrusted CTLs. To do this, you disable automatic root updates by using Group Policy settings. To disable automatic root updates by using policy settings, follow these steps:

1. Create a Group Policy or change an existing Group Policy in the Local Group Policy Editor.

2. In the Local Group Policy Editor, double-click Policies under the Computer Configuration node.

3. Double-click Windows Settings, double-click Security Settings, and then double-click Public Key Policies.

4. In the details pane, double-click Certificate Path Validation Settings.

5. Click the Network Retrieval tab, select Define these policy settings, and then clear the Automatically update certificates in the Microsoft Root Certificate Program (recommended) check box.

6. Click OK, and then close the Local Group Policy Editor.

7. In an administrative command prompt, run GPUPDATE to force the local Computer policies (note: this also refreshes the current user's policies as well). Alternately, the computer can be rebooted, but this is not necessary.

After you make this change, automatic root updates are disabled on those systems to which the policy is applied. We recommend that the policy be applied only to those systems that do not have Internet access or that are prevented from accessing Windows Update because of firewall rules.

Further to this advice, it is recommended to disable (uncheck) "Allow issuer certificate (AIA) retrieval during path validation." A completed policy is shown below:

If simply removing the online check does not resolve the problem, then the next step is to remove certificate-based communications within the Microsoft Windows Communication Foundation (WCF) calls we make between services.

1. Browse to C:\Program Files (x86)\PharosSystems\Blueprint\bin, or wherever the Blueprint software was installed (the path from \PharosSystems will be the same). Open the file PharosSystems.Blueprint.Taskmaster.exe.config in Notepad or other text editor. Note that you will need to launch your text editor as an Administrator, since this file lives in a part of the protected file system.

2. Within the <Configuration> section, add the following (it can be added as the next several lines directly under the initial <Configuration> tag line):

   <runtime>         <generatePublisherEvidence enabled="false"/>     </runtime>

3. Once the change has been made, save the file and close it.

4. Restart the Pharos Systems Taskmaster service.

Once these changes have been made, the log in time will remain consistent between terminals, no matter when a user logs in.

Blueprint 5.1 and 5.2 Extra:

The same edit will need to be made to the PharosSystems.SecureRelease.SecureReleaseService.exe.config file found in C:\Program Files (x86)\PharosSystems\SecureRelease. This file already has a <runtime> section, so you just need to add the generatePublisherEvidence line. The Secure Release Service will need to be restarted for this to take effect.

ADVANCED: FOR PHAROS INTERNAL AND RESELLER USE ONLY

If simply setting the "generatePublisherEvidence" function is not solving the problem, a more drastic edit will need to be engaged to combat the struggle with certificate chaining in .Net. The primary issue with this effort is that all Blueprint servers, regardless of function, will need to have these edits made, or they will be "offline" and unable to connect to, or update themselves with, the Analyst server (which must also have the edits made). In Blueprint 5.0, there is only one file that needs to be edited:

• C:\Program Files (x86)\PharosSystems\Blueprint\bin\global.serviceModel.bindings.config

In Blueprint 5.1 and 5.2, the changes need to be made in:

• C:\Program Files (x86)\PharosSystems\Blueprint\bin\global.serviceModel.bindings.config

• C:\Program Files (x86)\PharosSystems\SecureRelease\PharosSystems.SecureRelease.SecureReleaseService.exe.config

Within global.serviceModel.bindings.config, every instance of

      <security mode="Transport">        <transport clientCredentialType="Certificate" />      </security>

needs to be changed to read

      <security mode="None" />

Within PharosSystems.SecureRelease.SecureReleaseService.exe.config, look for the <netTcpBinding> section and change all instances of

      <security mode="Transport">        <transport clientCredentialType="Certificate" />      </security>

to read

      <security mode="None" />

When saved (note: run Notepad.exe in Administrator mode to make the changes, as the files are in protected folders), restart the Pharos Systems TaskMaster server (Blueprint 5.0, 5.1, 5.2) and the Pharos Systems Secure Release Service (Blueprint 5.1 and 5.2).

MobilePrint Extra:

If you are also running Pharos MobilePrint, you must also edit C:\Program Files (x86)\PharosSystems\MobilePrint\mobileprint.wcf.bindings.config file and change

            <security mode="Transport">                <transport clientCredentialType="Certificate"/>            </security>

to reflect

      <security mode="None" />

After saving, all MobilePrint services must be restarted.