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?”

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

1. Go to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy.
2. In the right-hand pane, double-click Audit logon events.
3. Check Success and Failure then click OK.
4. 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

On the Application Server, run ipconfig /all 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 command 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.

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.