- 28 Feb 2024
- 1 Minute to read
- Print
- DarkLight
- PDF
Blueprint: Resolving Active Directory Authentication Problems When Using the Standard Authentication Method
- Updated on 28 Feb 2024
- 1 Minute to read
- Print
- DarkLight
- PDF
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))