Troubleshooting Active Directory Authentication / AD login issues

“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.

Check the obvious stuff

• Is numlock or caps lock on? (We have to ask).
• Confirm the problem only affects domain-synced accounts. See if someone can authenticate with an internal user account, like the built-in admin (by logging into the user web interface, or printing through Mobility). If so, then the problem may only be affecting Windows Active Directory accounts.
• Make sure the password for the account you’re testing with is absolutely correct. What happens when you reset the user’s password in Active Directory, and then copy/paste it into the user web interface login page?
• If this is impacting all logins or all authentication, we recommend running the PaperCut services (in this case the ‘PaperCut Application Server’ service) with a domain user account to see if security policies are blocking the ‘SYSTEM’ account used by PaperCut services by default.

Further troubleshooting

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:

Run ipconfig /all on the Application Server to determine if it’s pointed to the organization’s DNS IP. If the domain DNS IP is missing, then you’ll have a bad time establishing connections to the domain controller which will affect your ability to authenticate users via the Application Server.

Try running ‘nltest’

Run C:\Windows> nltest /sc_query:DOMAINNAME.COM

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:

• is my NIC connected?
• do I have a valid IP?
• can I ping anything outside of the App Server?
• do I have DNS server IPs configured?
• are the dns servers responding? (test with: nslookup -type=soa test.com, replacing test.com with the dns name of your Active Directory domain, which is probably what is listed in the Primary Dns Suffix line of ipconfig /all)

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.

If all else fails…

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.

How PaperCut user authentication works with the Windows Active Directory sync source

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

1. A user accesses a client system (as described above) and provides a user name and password. The client system sends the user name to the App Server in plaintext. However, keep in mind that PaperCut client systems automagically upgrade their authentication connections to the App Server from HTTP to HTTPS, so passwords will not traverse the network un-encrypted with one exception: authentication attempts through user or admin webpages using the HTTP:// URL instead of HTTPS://. In any case, the App Server computes a cryptographic hash of the password and discards the actual password.
2. The domain controller generates a 16-byte random number, called a challenge or nonce, and sends it to the App Server.
3. The App Server encrypts this challenge with the hash of the user’s password and returns the result to the Domain Controller. This is called the response.
4. The App Server sends the following three items to the domain controller: User name, Challenge and Response
5. The domain controller uses the user name to retrieve the hash of the user’s password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
6. The domain controller compares the encrypted challenge it computed (in step 5) to the response computed by the App Server (in step 3). If they are identical, authentication is successful.

Still have questions?

Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.