Troubleshooting Active Directory Integration
It is recommended to follow these troubleshooting steps when Active Directory integration of Web Safety is not functioning as required.
Check the SPN is Mapped to One User Only
There should ONLY be ONE user mapped to a given SPN. If you have two or more different users mapped to a given SPN record, Kerberos authentication will ALWAYS FAIL. For more information see the following Microsoft blog entry.
You can use the queryspn.vbs script from Microsoft site to quickly check that SPN is only mapped to one user account. For example, if we search for SPN HTTP/proxy.diladele.lan@DILADELE.LAN the correct output will be one entry only:
c:\cscript queryspn.vbs HTTP/proxy*
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.
CN=squid,CN=Users,DC=diladele,DC=lan
Class: user
User Logon: squid
-- HTTP/proxy.diladele.lan
If you have more than one user mapped to a given SPN you can remove the additional mappings by running the following command in the administrator's command prompt on your domain controller. Please specify your own SPN and user name of course!
Check for User Password
Check that the domain user that you are using to test proxy authentication has a valid password in Active Directory domain and that password is not already expired. If it is expired - proxy authentication will not work and browser will continuously show authentication popup box! Ideally you should do logout/login on the desktop before any troubleshooting steps.
Check Machine is Domain Joined
Check you are accessing the proxy from DOMAIN JOINED Windows PC and from DOMAIN USER ACCOUNT if you are testing Kerberos authentication. Validate Kerberos authentication using latest version of Microsoft Internet Explorer. If neccessary, clear the credentials cache by running rundll32.exe keymgr.dll , KRShowKeyMgr and reboot the client machine.
Check FQDN Proxy Settings
Check if proxy in the browser network settings is specified by FQDN and not by IP address (i.e. proxy.example.lan is correct both 192.168.1.2 and simple proxy are incorrect). Usually the following line in cache.log illustrates this problem:
2016/02/13 17:35:07| ERROR: Negotiate Authentication validating user.
Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.
Minor code may provide more information.
No key table entry found for HTTP/proxy@EXAMPLE.LAN
Check Time
Check date and time settings in Web Safety appliance by running date in the command terminal. It should be the same as on your domain controller. It is also possible to see if the time difference on your proxy and domain controller is too big (more than 5 minutes) - in this case Kerberos authentication will always fail.
Be sure to check the timezone is setup correctly.
Check Auth Configuration
Check user authentication and authorization on your appliance is set up correctly. User names in form of user@EXAMPLE.LAN or EXAMPLE\\User need to be present in the Squid log file (usually /var/log/squid/access.log).
Check Squid Configuration File
If you have built the proxy server manually, check your Squid configuration file contains references to include files generated by Admin UI of Web Safety as explained in this article.
Check LDAP Server
Check if LDAP server settings in Admin UI / Squid Proxy / Auth / Active Directory Integration are correctly configured. Click the Test Connection button, check the output of this command.
Check LDAPS Certificate
If you are using LDAPS connections check the server certificate is correctly visible in Admin UI / Squid Proxy / Auth / LDAPS.
Check User Membership
Open Admin UI / Web Filter / Policies / Your Policy / Members / Active Directory Group and click the Search User button. Select the user which is definitely known to be in the target group and click the Search. Check the result of this command.
Check KeyTab
Finally, check keytab verification steps are successful and no errors are shown in Admin UI / Squid Proxy / Auth / Kerberos like shown on the following screenshot.
