- 3,722,431 Users
- 2,244,307 Discussions
- 7,849,830 Comments
Forum Stats
Discussions
Categories
- 16 Data
- 362.2K Big Data Appliance
- 7 Data Science
- 2K Databases
- 589 General Database Discussions
- 3.7K Java and JavaScript in the Database
- 32 Multilingual Engine
- 495 MySQL Community Space
- 7 NoSQL Database
- 7.7K Oracle Database Express Edition (XE)
- 2.8K ORDS, SODA & JSON in the Database
- 419 SQLcl
- 57 SQL Developer Data Modeler
- 185K SQL & PL/SQL
- 21.1K SQL Developer
- 2.3K Development
- 3 Developer Projects
- 32 Programming Languages
- 135.5K Development Tools
- 12 DevOps
- 3K QA/Testing
- 323 Java
- 10 Java Learning Subscription
- 12 Database Connectivity
- 70 Java Community Process
- 2 Java 25
- 11 Java APIs
- 141.2K Java Development Tools
- 8 Java EE (Java Enterprise Edition)
- 153K Java Essentials
- 135 Java 8 Questions
- 86.2K Java Programming
- 270 Java Lambda MOOC
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 14 Java SE
- 13.8K Java Security
- 3 Java User Groups
- 22 JavaScript - Nashorn
- 18 Programs
- 145 LiveLabs
- 34 Workshops
- 9 Software
- 3 Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 4 Deutsche Oracle Community
- 15 Español
- 1.9K Japanese
- 3 Portuguese
Kerberos: Cross Domain/Realm Issue

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.
Best Answer
-
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.
Answers
-
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.