Wir haben ein etwas kompliziertes IDAM-Setup:
Das heißt, der Computer und der Browser des Endbenutzers befinden sich in einem Netzwerk mit dem übergeordneten AD, und unsere Jetty-basierte Anwendung und der AD, mit dem er kommunizieren kann (lokaler AD), befinden sich im anderen.
Zwischen den beiden ADs besteht eine wechselseitige Vertrauensstellung. Der Browser im übergeordneten Netzwerk verfügt über die lokale Domäne an vertrauenswürdigen Sites.
Das Setup des Jetty-Servers ist wie folgt:
- Es wird eine Keytab-Datei verwendet, die für einen Principal im lokalen AD generiert wurde
- Es wird als Windows-Dienst unter einem im lokalen AD definierten Benutzer ausgeführt
- Realm, Domain-Realm-Mapping und kdc werden für die Domain des lokalen AD definiert
- es verwendet spnego - isInitiator ist auf false gesetzt; doNotPrompt ist wahr; storeKey ist wahr
Das Problem ist:
- Als Test funktioniert der Zugriff auf den Server über einen Browser im lokalen Netzwerk (dh mit dem lokalen AD verknüpft). Kerberos-Debug-Informationen werden in den Protokollen angezeigt. Ich kann die korrekte Kerberos-Aushandlung im HTTP-Verkehr sehen und der Benutzer wird automatisch angemeldet . Brillant.
Der Zugriff auf den Server über einen Browser im übergeordneten Netzwerk (so werden unsere Benutzer die Dinge tun) funktioniert jedoch nicht! Der Browser erhält eine unauth 401 zurück, fordert dann aber zur Eingabe von Anmeldeinformationen auf, die bei Eingabe einen leeren Bildschirm ergeben. Wenn Sie dann in die Adressleiste klicken und die Eingabetaste drücken, haben Sie zwei Möglichkeiten, je nachdem, ob die Anmeldeinformationen für die Remote- oder die lokale AD gelten:
- Lokale AD-Anmeldeinformationen melden sich dann einwandfrei an, wobei Kerberos von Grund auf in den Protokollen enthalten ist (GET-Anforderung, 401 nicht authentifizierte Antwort, Kerberos-Header-Anforderung usw.)
- Remote - AD - Anmeldeinformationen sich nicht einloggen (GET - Anfrage, 401 unauth Antwort, was aussieht wie ein NTLM - Header:
Authorization: Negotiate <60 or so random chars>)
In jedem Fall ist die Tatsache, dass es dazu auffordert, falsch!
Gibt es eine Erklärung für diese Symptome? Kann das Setup, das wir haben, tun, was wir wollen?
In Bezug auf die obige Beschreibung könnte dies falsch sein: Jede Konfiguration, die ich in Bezug auf den Jetty-Server erwähnt habe, sollte genau sein, so wie ich es getan habe. Gerne gebe ich weitere Details bekannt. Jede Konfiguration in Bezug auf AD oder den übergeordneten Netzwerkbrowser ist möglicherweise verdächtig, da sie nicht unter meiner Kontrolle steht und mir die Konfiguration gemeldet wurde, anstatt sie selbst zu sehen.
quelle
Antworten:
Ohne die Paketerfassung zu sehen, muss der SPN HTTP / www.website.com für das Konto registriert sein, auf dem die Anwendung ausgeführt wird. Das Directory Services-Team von Microsoft hat einen großartigen mehrteiligen Beitrag zu diesem Thema unter der folgenden URL.
https://blogs.technet.microsoft.com/askds/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1/
Führen Sie in jeder Umgebung eine Paketerfassung (Netmon, Wireshark) von einem Client aus, um festzustellen, welcher SPN gesucht wird. Sobald dies festgestellt wurde, registrieren Sie es mit dem Befehl setspn cmd bei dem Konto, auf dem die Anwendung ausgeführt wird.
FWIW, Kerberos funktioniert nur im LAN. Wenn jemand Zugriff benötigt, auf den die Domänencontroller nicht zugreifen können, sollten Sie ein SSO wie Shibboleth oder ADFS in Betracht ziehen.
BEARBEITEN: Wie von @ alex-h erwähnt , müssen die Browser so konfiguriert werden, dass sie sich stillschweigend über Kerberos authentifizieren.
Schließlich ist dies ein häufiges Problem bei Microsoft Sharepoint-Bereitstellungen. Sie möchten, dass SSO über Kerberos stillschweigend ausgeführt wird, sobald sich Benutzer bei der Domäne authentifiziert haben. Wenn die oben genannten Antworten Ihr Problem nicht lösen, überprüfen Sie die Foren wie die folgenden:
Kerberos auf Chrome, Safari oder FireFox
quelle
Bitte versuchen Sie es zuerst in einem Browser, in dem NTLM nicht aktiviert ist (Chrome / Firefox). Es scheint, dass das Problem darin besteht, dass Sie die Vorauthentifizierung aktiviert haben und möglicherweise die Zwei-Wege-Vertrauensstellung nicht vorhanden ist.
Die Vorauthentifizierung finden Sie hier https://support.microsoft.com/en-us/kb/2749007 und hier https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html .
quelle