Kerberos: can't get TGT for HOST/abc@abc.com - Realm not local to KDC

Are you presenting a username to Kerberos SSO that is in the same realm?

Hi Kevin,

Thanks for picking it up.

Yes I extract the username and present that within the SSO rather map it as session.logon.last username

Totally understand that, but in many environments the username and realm, whether you're using the email address or SAN UPN, doesn't match the actual username and Active Directory domain name. In fact the only time that would probably happen is if the domain itself was issuing the certificates. So as a more concrete example, let's say the AD domain name is DOMAIN.COM. Is the value that you're pulling from the cert (email or SAN UPN) of the same realm (ie. user@domain.com)? If not, do you have an alternate UPN suffix value in the domain for that certificate user realm?

here you go it is session.ssl.cert.subject = username and matches the AD UPN username@domain.com

Two things:

1. The session.ssl.cert.subject is rarely ever just username@domain.com, but usually a full DN string. Are you parsing the username out of the subject?

    

2. You need to split the username@domain.com into two values (at the "@"): the username source for Kerberos SSO should just be the username, and the realm source should either be the cert realm or a statically assigned realm.

    

Yes i am parsing the username out of the subject.

as i just have the username to parse i assign the domain statically within the realm.

the syntax though looks fine within the debug, however it just complains that the realm is not local to KDC.

I have even tried to modify the /etc/krb5.conf to set the domain, but still the error persists.

Okay, let's try a few things:

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

    

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

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

    

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

    

5. Make sure there are no duplicate SPNs in the AD (setspn -x)

    

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

    

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

Thanks for the helpful checklist. I have verified all settings and had to change the UPN setting as we also use it for exchange.

Once that was done now i get SU4 -> OK However what i got further is GSSAPI Init_sec_context returned code 0 GSSAPI token of length 4759 bytes will be sent back

So i have changed the send authorization to = On 401 Status code once that was done the matter even got worse

ssoMethod: kerberos usernameSource: session.logon.last.username userRealmSource: session.logon.last.domain Realm: ABC.COM KDC: server@abc.com AccountName: HOST/xyz@abc.com spnPatterh: HTTP/%s@abc.com TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 1

If this is for a Microsoft product, you'll likely want to keep authorization set to Always. So where does it fail? The S4U -> OK would suggests that APM is successfully retrieving a ticket, so is it possible that the app is rejecting it? WireShark will show you which Kerberos message is failing.

Thanks a lot. For MS i still get a logon prompt. so just debugging it.