Troubleshooting Active Directory Authentication / AD login issues
Last modified on 09 August 2020 06:19 PM
“Help! My users can’t log into the PaperCut User Web Interface, Client, or Mobility Print using their Active Directory Domain credentials, but internal user accounts can sign-in just fine. What’s going on?”
Note: for a more general FAQ on PaperCut and Active Directory, head over to the Active Directory Considerations KB.
This could be an issue if you’ve linked your PaperCut Application Server to use Active Directory as its user directory source (check out the How to sync users and groups with Active Directory details)…. and for some reason the App Server is no longer to ‘talk’ to your Active Directory (AD).
Any internal user accounts that you’re using would not be impacted, since the authentication (and password) is managed entirely by PaperCut. For the same reason, the built in ‘admin’ account would also not be impacted by any issues with the AD communication.
Make sure the Netlogon Service is running on the PaperCut server
At least one customer let us know that domain users stopped being able to authenticate after they upgraded their Windows print server from 2012 to 2016. They were able to resolve the issue by following the steps in this Microsoft article on the netlogon service (see the ‘Resolution’ section, which highlights how to change the Netlogon service Startup type to Automatic, and make sure the service is then started).
The article also then recommends a server restart, even though not strictly required.
Check the Windows Security Logs
Check to see if Windows is handling the authentication requests at all. Open the Local Group Policy Editor: hit Start, type “gpedit.msc,“ and then select the resulting entry.
Go to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy. In the right-hand pane, double-click “Audit logon events” then check Success and Failure then hit OK.
To view these events, go to Event Viewer then Windows Logs > Security. A successful login attempt for PaperCut services should have four events in the log:
If the authentication attempts don’t make it into the Security log, your client system is probably pointed at the wrong Domain Controller.
Check the IP protocol settings on the App Server:
Try running ‘nltest’
A successful secure channel connection to the domain controller should look like this:
If you don’t have any results for the secure channel, start troubleshooting with the basics:
Repair the connection if needed
You can repair the App Server’s domain connection without rebooting: use the PowerShell commandlet Test-ComputerSecureChannel with the –credential –Repair options. Check out the Test-ComputerSecureChannel documentation from Microsoft.
Run the command, sign out and then sign in back in with domain credentials.
For example, to repair the relationship with the test.paper.com domain, issue the command: @@Test-ComputerSecureChannel –credential test.paper.com\Administrator –Repair
Keep in mind that only Powershell 3.0 and later have the -credential option for Test-ComputerSecureChannel.
Try re-joining the App Server to the domain. This is a more painful option, but when things just don’t seem to be working correctly, it can sometimes save the day.
The application’s user authentication depends on Microsoft NTLM protocol, also known as Windows Challenge/Response. The authentication workflow below is adapted from the KB article Microsoft NTLM.
NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user’s password over the wire. Instead, the App Server requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.
Interactive NTLM authentication with PaperCut involves three systems: a user client system (embedded device, Mobility client, PaperCut software client, user web pages), the App Server to which the user is requesting authentication, and a domain controller, where information related to the user’s password is kept. The PaperCut authentication workflow is otherwise known as noninteractive authentication.
The first step provides the user’s NTLM credentials