Policy Server Guides › Policy Design Guide › SiteMinder Kerberos Authentication › Troubleshooting SiteMinder Kerberos Authentication

Troubleshooting SiteMinder Kerberos Authentication

Be aware of the following issues when working with SiteMinder Kerberos authentication:

• Be sure that the SiteMinder system clocks are synchronized (within 2 minutes) to the KDC system clock. Otherwise, Kerberos authentication fails because of clock skew errors.
• All the hosts must have suitable entries for IP Address, fully qualified domain name (FQDN) and hostname in the /etc/hosts file. The order of these entries also matters in some cases. Also, include at least single space between these entries:

  IP Address  FQDN hostname 
  

• Use the Windows resource tool, kerbtray, to see the Kerberos tickets description. The GUI shows the various tickets received by KDC client, its flags, encryption types, and time stamp.
• Use klist (UNIX KDC clients) to list tickets present in the credential cache. The flag –f provides information about tickets flags. These tickets are forwarded to complete the Kerberos authentication process.

  For example, see sample klist output listed following.

  bash-2.05$ klist
  Ticket cache: /tmp/krb5cc_1002
  Default principal: HTTP/sol8sunone.test.com@TEST.COM
  
  Valid starting            Expires                  Service principal
  Wed Dec 26 15:00:03 2007  Wed Dec 26 21:40:03 2007 krbtgt/TEST.COM@TEST.COM
  

• Always use the kinit program for the user and service principal at the MIT KDC host and UNIX KDC client.

  The kinit syntax for user principal is:

  kinit principalname
  

  This command prompts for the password used while creating the user

  principal.

  The kinit syntax (it can vary from host to host) for service principal is:

  kinit -k [-t keytab location containing service principal] principalname
  

  The kinit command does not prompt for a password, because it uses a keytab file to authenticate the service principal.

• Install any network packet trace utility on the workstation to see the Kerberos tokens exchanged between the browser and web server. The token starting with TIR indicates NTLM tokens, and tokens starting with YII denote the Kerberos tokens.
• Log off the workstation host after any change in encryption type at the KDC. Also, restart the Policy Server and web server services after any changes are made to the Kerberos configuration or the keytab files.
• The KDC does not support post-dated tickets.
• Only DES-CBC-MD5 and DES-CBC-CRC encryption types are available for MIT interoperability.
• Always enable the Policy Server and the Web Agent logs to record the authentication error messages.
• Verify that the name and location of keytab file for any host matches the ones specified in krb5.conf file.
• The SPN is always case-sensitive. The krb5.keytab files for the Policy Server and the web server host must contain the host and service principals for the Policy Server and web server hosts.
• Always verify the version of ktpass utility. The ktpass command tool utility is included in the Windows support tools and can be installed from MSDN download or Windows 2003 SP1 CD.
• Always confirm the encryption type used while creating the keytab file. Windows by default supports RC4-HMAC encryption.
• Confirm the Kerberos version number (kvno). The kvno of the service principal must match the kvno of its keytab file. The kvno number of any keytab is displayed when it is created.
• To determine the kvno of a service account:

  For Windows Active Directory:

  The kvno number of any service principal can be confirmed using ADSI Edit as follows:

  1. Run adsiedit.msc from command prompt.
  2. Go to service account, under CN=Users, DC=domain, DC=com under drop-down Domain (fqdn_ADhost) at the left.
  3. Right-click the service account and click properties.
  4. Verify the value of the msDs-KeyVersionNumber attribute, which matches the one shown while creating the keytab file for the service account.

  The kvno for any user account changes every time its password is changed. If the version numbers do not match, create an account and keytab, or change the password to match the kvno to the kvno of the keytab.

  For UNIX MIT KDC:

  Use the kvno utility. The syntax of this command is:

  Kvno principalname
  

• On Windows:

  You can verify if your keytab file is valid by installing windows support tools on both Policy Server and Web Agent running the following command:

  Kinit -k -t <keytab file location> <respective spn>
  

  For example:

  kinit -k -t C:\Windows\webserver.keytab HTTP/websvriis6.test.com@KRISH.COM
  

  This command returns no error when the keytab file is valid.

• On Solaris:

  Verify both keytab files validity by running the following commands:

  Kinit -k -t <keytab file> <SPN>
  

  For example:

  kinit -k -t host.keytab host/<fqdn>@DOMAIN.COM
  kinit -k -t smps.keytab smps/<fqdn>@DOMAIN.COM
  

  If you get no errors, keytab files are fine, and the krb.conf file has valid values.

  If you get an error, check whether the SPN is valid in KDC using the following command:

  Kinit host/<fqdn>@DOMAIN.COM
  

  This command usually asks for password. If you provide a valid password, you do not get an error message. If this command does not ask for password, the SPN was not identified. Check the property of that object, and in Account tab your SPN can be visible, for example, host/fqdn. If it is visible, make sure no other object has the same entry set as SPN.