0

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.LOCAL
default_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.LOCAL
example.local=EXAMPLE.LOCAL
.example.local=EXAMPLE.LOCAL
dummy.local=DUMMY.LOCAL
.dummy.local=DUMMY.LOCAL
subdomain.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/web001.test.local@TEST.LOCAL
HTTP/web001.test.local
HTTP/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 was
invalid: Negotiate YIIJ...
org.springframework.security.authentication.BadCredentialsException:
Kerberos validation not successful

Caused by: java.security.PrivilegedActionException: null

Caused by: sun.security.krb5.KrbCryptoException: Checksum failed

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

hlpinform
  • 111
  • 8
  • 1
    Have you really checked that the client on the example.local domain got a service ticket for HTTP/web001.test.local? The KDC from example.local can not issue such a service ticket. Instead the KDC from example.local has to tell the client to use KDC test.local to obtain such a service ticket. You may have a look at https://technet.microsoft.com/en-us/library/bb742516.aspx – Bernhard Thalmayr Feb 27 '17 at 18:19
  • I, in person, have not checked that. But I will ask the customer to check that. But as far as I know, thet KDC from example.local will issue a service ticket. But not directly to the client but instead "cross sign" the service ticket (via the trust) from test.local as shown here (https://adsecurity.org/?p=1588 ; 2nd image). But my main concern is that I don't understand why this works for test.local as well subdomain.test.local but not for the other two domains. So there has to be difference. – hlpinform Mar 01 '17 at 06:43
  • the link you referenced is a security breach, not the way it works in a correct way – Bernhard Thalmayr Mar 01 '17 at 20:37
  • It seems that your initial thought was right. The client (from example.local or dummy.local) does not seem to get a service ticket for HTTP/web001.test.local. The question is WHY? Cause it works with test.local as well as subdomain.test.local. – hlpinform Mar 06 '17 at 07:27

1 Answers1

1

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.

Thanks to Bernhard which pointed me into the right direction with his question.

hlpinform
  • 111
  • 8