Ich stieß auf ein Problem, während ich einem Kunden half, SSO (mit Kerberos) für unsere Software zu konfigurieren.Kerberos: Cross Domain/Realm Problem
Aber zunächst wollen wir Ihnen einige Kontext geben:
Wie Sie in der attatched krb5.ini wir Cross Domain/Realm Kerberos wollen sehen, tun und wir haben vier verschiedene (Active Directory, alle haben 2008 R2 Wald/Domänenfunktionsebene) Domänen.
1) test.local 2) subdomain.test.local (die Domäne von test.local offensichtlich ein Kind ist) 3) example.local 4) dummy.local
Ein Zwei-Wege transitives Vertrauen war (manuell) zwischen test.local und example.local sowie zwischen test.local und example.local.
Und es gibt (natürlich) die Standardvertrauensstellung zwischen test.local und 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 Auflösung funktioniert gut.
Der Webserver ist eine Linux Box (wenn ich mich richtig erinnere, war es eine RedHat oder CentOS Installation). Der FQDN ist web001.test.local.
Die Clients (getrennt von der Domäne, der sie angehören) behandeln das fqdn web001.test.local als Mitglied der lokalen Intranetzone.
Wir haben erfolgreich einen Service-Benutzer und eine entsprechende Keytab-Datei für den Webserver erstellt.
Wenn wir test.local und die Suche nach dem spn abfragen wir die richtige Antwort erhalten:
<service user)>
HTTP/[email protected]
HTTP/web001.test.local
HTTP/web001
Danach begannen wir Tests und Kerberos funktionierte gut (wenn die Benutzer Mitglieder test.local oder Sub-Domain sind .test.local), bis wir versuchen, uns mit einem Testbenutzer von dummy.local und example.local anzumelden.
Jedes Mal, wenn ein Benutzer von diesen speziellen Domänen wir folgende stacktrace erhalten einzuloggen versucht:
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
Wie gesagt: Kerberos arbeitet mit Kunden/Anwender im test.local und die subdomain.test. lokaler Bereich/Domäne.
Aber ich verstehe nicht, warum es nicht mit den anderen Domänen/Realms funktioniert.
Kann mich jemand aufklären oder mir wenigstens einen Hinweis geben?
Vielen Dank im Voraus.
P.S. Zum Debugging/Reagieren: Ich habe keinen direkten Zugriff auf die Kundendomains (aktive Verzeichnisse) und den Webserver. Das Debuggen und Antworten auf Ihre Antworten kann einige Tage dauern.
Haben Sie wirklich überprüft, dass der Client in der example.local-Domain ein Serviceticket für HTTP/web001.test.local erhalten hat? Das KDC von example.local kann ein solches Serviceticket nicht ausgeben. Stattdessen muss der KDC von example.local dem Client mitteilen, dass er KDC test.local verwenden soll, um ein solches Serviceticket zu erhalten. Sie können einen Blick auf https: // technet.microsoft.com/en-us/library/bb742516.aspx –
Ich, persönlich, habe das nicht überprüft. Aber ich werde den Kunden bitten, das zu überprüfen. Aber soweit ich weiß, wird das KDC von example.local ein Serviceticket ausgeben. Aber nicht direkt zum Client, sondern stattdessen das Serviceticket (über den Trust) von test.local (https://adsecurity.org/?p=1588; 2. Bild) "überkreuzen". Aber meine Hauptsorge ist, dass ich nicht verstehe, warum das sowohl für test.local als auch für subdomain.test.local funktioniert, aber nicht für die anderen beiden Domänen. Also muss es einen Unterschied geben. – hlpinform
Der Link, auf den Sie verwiesen haben, ist eine Sicherheitsverletzung, nicht die Art und Weise, wie sie richtig funktioniert –