Kerberos is a very secure protocol, with that security comes important environmental variables for which it relies on to function.
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...).
Check the keytab version (on the Secure Web Gateway)
# yum install krb5-workstation
# klist -tek /etc/krb5.mwg.keytab
# /usr/kerberos/bin/klist -tek /etc/krb5.mwg.keytab (on 7.2.x or older)
Check the user account version (on the DC)
To check the user account version, there are a couple of different ways to do this. The easiest I found was using a tool called ldifde, the command below will output a file containing attributes based on the search string you enter (replace SPN-SEARCH-STRING with your SPN). Included in the output is the version number associated with the user.
ldifde -f c:\dump.txt -t 3268 -l dn,sAMAccountName,msds-
keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "
ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-
keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r
> ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*mandarin.vegas.local*)"
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 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".
Commands to update time (SWG version specific)
# Check current time values
# 7.3.x and higher, update software clock (date) using NTP
service ntpd stop
service ntpdate start
service ntpd start
# 7.2.x and lower, update software clock (date) using NTP
# Check current time values
# If 'date' is correct, but 'hwclock' is off, update the hardware clock with the software clock time
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 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:
Internet Explorer 6 does not support Kerberos with proxy authentication (but does support NTLM).