☰

Kerberos Single Sign On (SSO) kann nicht deaktiviert werden

tag-icon • tag-icon active-directory iis-7.5 kerberos single-sign-on
Kerberos Single Sign On (SSO) kann nicht deaktiviert werden

Ich habe Kerberos Single Sign On (SSO) untersucht, um NTLM für eine Webanwendung zu ersetzen, die intern in einer Windows-Domäne gehostet wird.

Nachdem ich Service Principal Names (SPN) für einen Testdienst erstellt habe (setspn -s), kann ich mithilfe von Fiddler oder WireShark deutlich erkennen, dass die Authentifizierung von NTLM auf Kerberos umgestellt wurde.

Mit einem umsichtigen Infrastrukturteam möchte ich beweisen, dass die Änderung schnell und einfach rückgängig gemacht werden kann. Ich möchte NTLM nicht über die Webserverkonfiguration erzwingen. Entsprechend werden die SPNs gelöscht (setspn -d) und deren Löschung bestätigt (setspn -q).

Ich führe den folgenden Befehl aus, um alle Servicetickets auf dem Client zu entfernen:

C:\>klist purge

Current LogonId is 0:0x521ac
        Deleting all tickets:
        Ticket(s) purged!

C:\>

Bei weiteren Interaktionen mit der Webanwendung wird ein weiteres Serviceticket erstellt und Kerberos bleibt weiterhin der SSO-Authentifizierungsmechanismus. Dies gilt für Benutzer, die den Dienst zuvor nicht verwendet haben. Dies ist sogar am nächsten Tag der Fall, wenn über Nacht (12-14 Stunden) keine Interaktion stattgefunden hat.

Obwohl ich wiederholt nach einer Erklärung für die beobachtete Persistenz gesucht habe, bin ich mit leeren Händen zurückgekommen. Ich glaube jedoch, in dem Artikel einen Hinweis gefunden zu haben;Die Funktion LsaLookupSids gibt möglicherweise den alten Benutzernamen anstelle des neuen Benutzernamens zurück, wenn sich der Benutzername geändert hat:

Die lokale Sicherheitsautorität (LSA) speichert die Zuordnung zwischen der SID und dem Benutzernamen in einem lokalen Cache auf dem Domänenmitgliedscomputer. Der zwischengespeicherte Benutzername wird nicht mit Domänencontrollern synchronisiert. Die LSA auf dem Domänenmitgliedscomputer fragt zuerst den lokalen SID-Cache ab. Wenn bereits eine vorhandene Zuordnung im lokalen SID-Cache vorhanden ist, gibt die LSA die zwischengespeicherten Benutzernameninformationen zurück, anstatt die Domänencontroller abzufragen. Dieses Verhalten soll die Leistung verbessern.

Bei den Cache-Einträgen kommt es zu einer Zeitüberschreitung. Es besteht jedoch die Möglichkeit, dass wiederkehrende Abfragen von Anwendungen den vorhandenen Cache-Eintrag für die maximale Lebensdauer des Cache-Eintrags am Leben erhalten.

Kann jemand bestätigen, ob das Key Distribution Center (KDC) SPN-Einträge auf ähnliche Weise zwischenspeichert (oder eine alternative Erklärung liefern)? Wenn ja, wie lang ist die maximale Lebensdauer der Cache-Einträge?

Antwort1

Ich habe das Problem entdeckt. Der DNS-Eintrag für den Dienst war kein „A“-Eintrag, sondern tatsächlich ein „CNAME“-Eintrag. Das bedeutet, dass der Browser einen Schlüssel für das Dienstkonto erstellt hat. Dies hängt mit der Einstellung „useAppPoolCredentials“ auf der Site/dem Server zusammen, die auf „False“ (Standard) eingestellt war. Die SPNs, an denen ich Änderungen vorgenommen habe, nahmen nicht an der stattfindenden Kerberos-Authentifizierung teil.

verwandte Informationen