Scott Olswold

Blueprint: Resolving Active Directory Authentication Problems When Using the Standard Authentication Method

Blog Post created by Scott Olswold on Sep 3, 2019

Problem

Depending upon the configuration of the Active Directory domain controllers, the Standard Authentication Script provided with Pharos Blueprint Enterprise may not be immediately successful, causing login attempts at devices and unauthenticated Print Scout clients to fail.

 

Symptoms

One or more of the following errors may be presented:

  • Message: Unable to authenticate user. Either user does not exist, or the password is incorrect.
  • Message: The server cannot handle directory requests.

 

Cause

 

One of the reasons Active Directory-based authentication may fail is binding. When a .Net application like Pharos Blueprint Enterprise attempts to authenticate a connection with Active Directory it has to present the correct context to the domain controller. The various bind options are discussed in ContextOptions Enum (System.DirectoryServices.AccountManagement) | Microsoft Docs (this article explains them in terms of .Net 4.8; it applies to any version of .Net).

 

In the case of the Standard Authentication Script, it does not actually specify a binding, which forces a Basic Authentication event. Many domain controllers are specifically configured to not allow Basic Authentication.

 

Resolution

To change binding to Active Directory in the Blueprint Standard Script, modify the following line, found in function ActiveDirectoryQueryWorker()

 

if (!adContext.ValidateCredentials(userId, password, ContextOptions.Negotiate))

 

Possible values for this can be found in the document referenced in the "Cause" above. NOTE: The only change that may generally be required is to force use of Kerberos, which is done by changing the text to:

 

if (!adContext.ValidateCredentials(userId, password, ContextOptions.Negotiate | ContextOptions.Sealing))

Outcomes