Resolving Issues with Active Directory Access in Pharos Blueprint Enterprise

Background and Purpose

Pharos Blueprint Enterprise utilizes Active Directory for many functions:

1. User authentication at a terminal (iMFP solution or Omega) for copier access or Secure Release Here job release.

2. ID card registration at a terminal for copier access or Secure Release Here job release.

3. User authentication when using either the Windows or MacOS Print Agent in "unauthenticated user" mode.

4. Policy Print assignment.

Some things, like the authentication script for terminals and Print Agents, can be explicitly defined with a designated account with sufficient permission to browse and read Active Directory objects. But in most cases, installations of Blueprint Enterprise rely on a set of access assumptions and default behaviors that are not valid in specific environments. This article will discuss those assumptions and default behaviors, and how to render configuration changes so that the software can work successfully in any environment, regardless of security protocol.

"Out of the Box" Behaviors

When installing Blueprint Analyst or Collector software, the Tracker and EDI web services that are also installed rely upon an "Application Pool" to connect with the underlying Microsoft .Net functions that are used to do the work. Prior to IIS 7.5 (introduced with Service Pack 2 for Microsoft Windows 2008 Server and included in Microsoft Wndows 2008 R2 Server), application pools could use, by default, either the built-in LocalSystem or Network Service special accounts. Using Network Service allowed the web application, via the application pool, to access local files (and do so in a very protected manner) as well as access network services (like Active Directory) by masquerading/presenting itself as the server's domain machine account (as DOMAIN\MACHINE$). However, with IIS 7.5, Microsoft retooled this configuration such that a new, limited-function credential was created called "ApplicationPoolIdentity." This special-use account is local to the server and is expressed as "IIS AppPool\<AppPool Name>" for access/permissions purposes. When this identity is used to access a network service or resource, it also presents as the server's domain machine account.

Impact

By default, either Network Service or the ApplicationPoolIdentity should allow browsing of Active Directory and for its objects to be "read". However, security constraints within Active Directory can cause this to fail.

Resolving Active Directory Access Issues

The best method for resolving Active Directory access issues when the default behavior model falls short is to explicitly define the PharosSystemsAppPool with a domain user account that fulfills the following criteria:

1. Has been added to the local "IIS_IUSRS" security group.

2. Has sufficient credentials to read the Active Directory domain (and, by extension, any other domains in the forest and - as required - other forests).

3. Has a non-expiring password.

To set the new identity:

1. Start IIS Manager on the server and browse to the "Application Pools" group.

   

2. Select the "PharosSystemsAppPool" and then click "Advanced Settings" link under "Edit Application Pool".

3. Under the "Process Model" group, click inside the value for "Identity" (the value will be listed as ApplicationPoolIdentity). Then, click the "Browse" button (the small box with the ellipsis: "..." in it).

   

4. Choose "Custom Account" and then click the "Set..." button.

   

5. Provide credentials as follows:

   

   1. User name: Use the format <Domain>\<User>. In the screenshot above, I used "blueprint\pharossvc" since "blueprint" is my environment's domain name.

   2. Password. Type as-is assigned.

6. Click "OK" until you are returned to the main IIS Manager interface to commit the change.

7. Stop and Start the PharosSystemsAppPool. Note that you may need to wait a few seconds (I count to 5) before attempting to start, or you may get a weird error message:

   

   This can be readily dismissed and then a start of the application pool will be successful. You've just been impatient, and Windows is not ready for you yet.

An Alternate Path

If you choose not to manage the configuration this way, it is also possible to access Active Directory as if it were LDAP (at its core, it is X.500). The LDAP configuration under the Blueprint Administrator's Device Management > Authentication Methods section:

allows for a defined "BindDN" which bypasses the inherent permissions defined for the ApplicationPoolIdentity user.