Forum Discussion
Okay, let's try a few things:
-
Create a variable assignment in your access policy, directly before the ending Allow block and set the username and domain session variables statically. This is just a test configuration to eliminate any client side issues. So whatever your Kerberos SSO profile needs for username and realm source, create and populate those session variables in the variable assignment agent.
-
Again, just for testing, edit the properties of the AD user account you created to do the Kerberos delegation:
- User Logon Name (UPN) - create an arbitrary SPN value here (ex. host/krb-sso.domain.com)
- Pre-Windows 2000 name - doesn't matter
- If you have AD Users and Computers in Advanced View, go to the Attribute Editor tab, find the servicePrincipalName attribute, and fill it with the same SPN from above.
- Close and re-open the account properties and then go to the Delegation tab. Add the HTTP/ SPN for each web server (or a single SPN if you're using a domain user account as the app pool owner)
-
In your Kerberos SSO profile, enter the Kerberos Realm (all uppercase). The Account Name field should be the same SPN value from above (ex. host/krb-sso.domain.com). If you're using a single user account as the owner of all of the app pool resources, put its SPN in the SPN Pattern field.
-
Ensure that, from the BIG-IP command line, you can successfully resolve (forward and reverse) the domain realm name. If the apps are owned by the local systems, make sure you get good forward and reverse DNS resolution of those as well.
-
Make sure there are no duplicate SPNs in the AD (setspn -x)
-
Edit the /etc/krb5.conf file and set default_realm to your local AD domain name (all uppercase). Set dns_lookup_realm to false, and dns_lookup_kdc to true. Remove every mention of EXAMPLE.COM if it exists.
-
Enable debug mode for APM SSO
Some or all of this you may have already done, but this constitutes a baseline working configuration for Kerberos SSO, so best to level set on a standard config. If at all possible, install WireShark on the domain controller and watch both Kerberos and DNS traffic. This is by far the best way to troubleshoot Kerberos issues.