Kerberos: Cross Domain/Realm Issue

3405321

I ran into an issue while I was helping a customer to configure SSO (with Kerberos) for our Software.

But first, let's give you some context:

As you can see in the attatched krb5.ini we want to do Cross Domain/Realm Kerberos and we have four different (Active Directory; all have 2008 R2 forest/domain function level) domains.

1) test.local 2) subdomain.test.local (which is obviously a child domain of test.local) 3) example.local 4) dummy.local

A two-way transitive trust was (manually) setup between test.local and example.local as well as between test.local and example.local.

And there is (of course) the default trust between test.local and subdomain.test.local.

[libdefaults]default_realm = TEST.LOCALdefault_tkt_enctypes = rc4-hmac aes128-cts aes256-cts des-cbc-crc des-cbc-md5 default_tgs_enctypes = rc4-hmac aes128-cts aes256-cts des-cbc-crc des-cbc-md5 permitted_enctypes = rc4-hmac aes128-cts aes256-cts des-cbc-crc des-cbc-md5 [realms] TEST.LOCAL = {  kdc = dc001.TEST.local  kdc = dc002.TEST.local}EXAMPLE.LOCAL = {  kdc = dc001.example.local  kdc = dc002.example.local}SUBDOMAIN.TEST.LOCAL = {  kdc = dc001.SUBDOMAIN.TEST.local  kdc = dc002.SUBDOMAIN.TEST.local}DUMMY.LOCAL = {  kdc = dc001.dummy.local  kdc = dc002.dummy.local}[domain_realm]test.local=TEST.LOCAL.test.local=TEST.LOCALexample.local=EXAMPLE.LOCAL.example.local=EXAMPLE.LOCALdummy.local=DUMMY.LOCAL.dummy.local=DUMMY.LOCALsubdomain.test.local=SUBDOMAIN.TEST.LOCAL.subdomain.test.local=SUBDOMAIN.TEST.LOCAL

Cross domain name resolution works just fine.

The webserver is a linux box (if I remember correctly it was a RedHat or CentOS installation). The fqdn is web001.test.local.

The clients (separately from the domain they are a member of) treat the fqdn web001.test.local as member of the local intranet zone.

We successfully created a service user and a corresponding keytab file for the webserver. If we query test.local and search for the spn we get the correct response:

<service user)>HTTP/[email protected]/web001.test.localHTTP/web001

After that we started testing and Kerberos worked just fine (if the users are members of test.local or subdomain.test.local) until we tried to login with a test user from dummy.local and example.local.

Every time a user tries to login from these particular domains we get the following stacktrace:

09:44:25.447 WARN  REQUEST[10.50.50.45]o.s.s.k.w.a.SpnegoAuthenticationProcessingFilter - Negotiate Header wasinvalid: Negotiate YIIJ...org.springframework.security.authentication.BadCredentialsException:Kerberos validation not successfulCaused by: java.security.PrivilegedActionException: nullCaused by: sun.security.krb5.KrbCryptoException: Checksum failedCaused by: java.security.GeneralSecurityException: Checksum failed

As I said before: Kerberos works with clients/users within the test.local and the subdomain.test.local realm/domain.

But I don't get why it is not working with the other domains/realms.

Can someone enlighten me or at least give me a hint?

Thanks in advance.

P.S. Regarding debugging/responding: I do not have direct access to the customer domains (active directories) and the webserver. So debugging and responding to your answers may take a few days.

3405321

Okay, the issue was the trust configuration! As mentioned before, it was a two way transitive trust. Sadly it was neither (except for the child domain) a child nor a forest trust. It was an external trust. This way, there was no name routing convention for kerberos active.

I found this article (https://jorgequestforknowledge.wordpress.com/2011/09/14/kerberos-authentication-over-an-external-trust-is-it-possible-part-6/) and we configured the name routing manually via a GPO. This did the trick.

3405321

Okay, the issue was the trust configuration! As mentioned before, it was a two way transitive trust. Sadly it was neither (except for the child domain) a child nor a forest trust. It was an external trust. This way, there was no name routing convention for kerberos active.

I found this article (https://jorgequestforknowledge.wordpress.com/2011/09/14/kerberos-authentication-over-an-external-trust-is-it-possible-part-6/) and we configured the name routing manually via a GPO. This did the trick.