Skip to main content
Skyhigh Security

Common Issues

Kerberos is a very secure protocol, with that security comes important environmental variables for which it relies on to function.

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

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)

clipboard_e821c836a157e16dd39f3541e483b9bf5.png

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 "
(serviceprincipalname=*SPN-SEARCH-STRING*)"

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

Example output:

> ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*mandarin.vegas.local*)"

c:\dump.txt:

dn: CN=mwg-kerb-user,CN=Users,DC=vegas,DC=local

changetype: add

sAMAccountName: mwg-kerb-user

userPrincipalName: HTTP/mandarin.vegas.local@VEGAS.LOCAL

servicePrincipalName: HTTP/mandarin.vegas.local

servicePrincipalName: HTTP/mwg-alias.vegas.local

msDS-KeyVersionNumber: 6

 

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

clipboard_e1dc7c95d995d9b88f21cc8482443980d.png

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

clipboard_eff35608af3db349a20bdd515ff0a80ae.png

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:

clipboard_eb458b4b93922b8b4909635e3d4510c2a.png

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

clipboard_e93d74013a6897f64332c31c701b80dc4.png

 

Commands to update time (SWG version specific)

# Check current time values

date;hwclock

 

# 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

ntpd -s

 

# Check current time values

date;hwclock

 

# If 'date' is correct, but 'hwclock' is off, update the hardware clock with the software clock time

hwclock --systohc

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.

clipboard_e36853a184c67b0c88be76b530404813e.png

 

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

clipboard_e19d906dd8e71f65599e8a28bc37c78ba.png

clipboard_e2289948f5b7a6750c798841c16424492.png

 

IE6

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

  • Was this article helpful?