For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Feb 28, 2014

Okay, this is a Kerberos issue. A few things to check:

 

Configuration:

 

  1. Create a user account in the AD to serve as the delegation service account. For the User Logon Name, create an arbitrary SPN value (ex. host/krb-sso.realm.com). The pre-Windows 2000 name doesn't matter. Copy this SPN as you'll need it later.

     

  2. If you right click on the tree in AD Users and Computers, you'll see an option to set View to Advanced. Once you've done that, open up the account you just created. You should see an Attribute Editor tab now. Go to that tab, find the servicePrincipalName field, and add the SPN from before to this field.

     

  3. Close and re-open the account properties. By virtue of the servicePrincipalName value, you should now see a Delegation tab. Go to that tab, select "Trust this user for delegation to specified services only", and "Use any authentication protocol". Now find and select the HTTP/ SPN of the XML broker(s) in the delegation window.

     

  4. In the Kerberos SSO profile, you should already have session.ldap.last.attr.sAMAccountName as the Username Source. In the Account Name field, paste the same SPN value from before.

     

Troubleshooting:

 

  1. Verify time skey - no more than 5 minutes usually, but better to be in sync.

     

  2. Verify that the BIG-IP can resolve both forward (A) and reverse (PTR) for the DOMAIN itself, and all of the XML brokers.

     

  3. In the BIG-IP shell, edit (vi) the /etc/krb5.conf file. Arguably this shouldn't be necessary, but I've already seen it cause problems on a few 1.4 and 11.5 systems. Set the dns_lookup_realm value to false, set the dns_lookup_kdc value to true, set the default_realm value to your local REALM (all uppercase), and remove all references to EXAMPLE.COM.

     

  4. Verify that there are no duplicate SPNs in the AD (setspn -x).

     

You also mentioned that you don't have HF3 on XenApp yet. If this is for 6.5, make sure that you at least have XA650W2K8R2X64025. And finally, if all else fails, install WireShark on the DC, as this will be the very best way to troubleshoot Kerberos errors.