Common Issues

Browser quirks

If an IP is used in the proxy settings then the browser will fail to perform kerberos authentication (IE only). As a result, it is a best practice to use kerberos with thehostname/FQDN.

Syntax (realm isnt all caps)

When generating the keytab, it is essential that you pay attention to the syntax. A very common syntactial mistake is forgetting to use ALL CAPS in the realm (VEGAS.LOCAL).

Keytab and user version out of sync

If the password for the user account (mwg-kerb-user) has changed, then the version number will change, requiring the keytab to be re-generated. To check for a version mismatch, you must check the keytab and the user account. Keep in mind that version numbers can change for a number of different reasons (regenerate keytab file, password change, etc...).

Duplicate SPNs

In a production environment, this may not be a common problem, but during testing you may create multiple user accounts and associate the same SPN with each of those user accounts. If you do this, then this could result in issues. You must be sure that your SPN is unique. To check for duplicates, you can use ldifde again! Same command as above. In addition Server 2008, the setspn utility comes with options for checking for duplicates as well.

ldifde -f c:\dump.txt -t 3268 -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"

ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"

setspn -X SPN-SEARCH-STRING (Only works in Server 2008 this will work, but ldifdeoutput is better for troubleshooting)

Time

Time is a huge deal with Kerberos, if the time is off, your ticket may not be valid. It is very important to ensure that ALL parties involved (all workstations, KDCs, and the Secure Web Gateway) have their time in sync, the best way to do this is with NTP.

If the time between the Secure Web Gateway and the KDC is off, you can easily correct this. First, check the time on the Secure Web Gateway (using the date command from the CLI).

Then in the user interface under Configuration > Date and Time, set the Secure Web Gateway up to use an NTP server (the same server that the KDC, and the clients are using).

Once the NTP server is set, we can sync the Secure Web Gateway immediately with the timeserver, by issuing the ntpd -s command. Afterwards, check the date again to make sure the time is what you expected:

In addition to setting the system clock (date), the hardware clock (hwclock) should also be set correctly. To sync the system clock and the hardware clock, issue the hwclock --systoh ccommand, which means "write the system clock to the hardware clock".

How to access the proxy

How you generated the keytab file, controls how you should access the proxy. In the example keytab ktpass syntax above, I specified the principal as: HTTP/mandarin.vegas.local@VEGAS.LOCAL

Which means that the proxy settings should be set to mandarin.vegas.local, NOT the IP-address. If I wanted to use the IP address, the keytab ktpass syntax would be changed to reflect the IP of the Secure Web Gateway: HTTP/10.10.69.72@VEGAS.LOCAL

If you do not specify the proxy settings to match what was entered into the keytab file, this will likely result in authentication prompts from the browser.

Follow previous sections on "Generating the keytab" and "Mapping multiple SPNs to oneuser/keytab", if you want to generate the keytab for different ways of generating the keytab file.

DNS

DNS is also very important, you must be able to forward/reverse resolve the Secure Web Gateway, as well as the KDC. To check for this, you can type:

nslookup hostname.domain.tld

nslookup x.x.x.x

IE6

Internet Explorer 6 does not support Kerberos with proxy authentication (but does support NTLM).