AD FS-Problembehandlung: Integrierte Windows-Authentifizierung
Bei der integrierten Windows-Authentifizierung können sich Benutzer*innen mithilfe von Kerberos oder NTLM mit ihren Windows-Anmeldeinformationen anmelden und das einmalige Anmelden (Single Sign-On, SSO) nutzen.
Gründe für Fehler bei der integrierten Windows-Authentifizierung
Es gibt drei Hauptgründe für Fehler bei der integrierten Windows-Authentifizierung: Fehlkonfiguration des Dienstprinzipalnamens (Service Principal Name, SPN), Kanalbindungstoken und Konfiguration von Internet Explorer.
SPN-Fehlkonfiguration
Ein Dienstprinzipalname (SPN) ist ein eindeutiger Bezeichner einer Dienstinstanz. Mithilfe von SPNs wird bei der Kerberos-Authentifizierung eine Dienstinstanz einem Anmeldekonto für den Dienst zugeordnet. Dadurch kann eine Clientanwendung anfordern, dass der Dienst selbst dann ein Konto authentifiziert, wenn der Client keinen Kontonamen aufweist.
Ein Beispiel für die Verwendung eines SPN mit AD FS lautet wie folgt:
- Ein Webbrowser führt eine Abfrage für Active Directory durch, um das Dienstkonto für die Ausführung von „sts.contoso.com“ zu ermitteln.
- Active Directory informiert den Browser darüber, dass es sich um das AD FS-Dienstkonto handelt.
- Der Browser erhält ein Kerberos-Ticket für das AD FS-Dienstkonto.
Verfügt das AD FS-Dienstkonto über einen falsch konfigurierten oder falschen SPN, kann dies zu Problemen führen. In den Netzwerkablaufverfolgungen werden möglicherweise Fehler wie der KRB-Fehler „KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN“ angezeigt.
Mithilfe von Netzwerkablaufverfolgungen (z. B. Wireshark) können Sie bestimmen, welchen SPN der Browser auflösen möchte. Anschließend können Sie mithilfe des Befehlszeilentools „setspn -Q <spn>“ eine Suche für diesen SPN durchführen. Es kann sein, dass der SPN nicht gefunden wird oder einem anderen Konto (und nicht dem AD FS-Dienstkonto) zugewiesen ist.
Sie können den SPN in den Eigenschaften des AD FS-Dienstkontos überprüfen.
Kanalbindungstoken
Aktuell wird zunächst ein Transport Level Security (TLS)-Kanal eingerichtet und eine Authentifizierung über diesen Kanal durchgeführt, wenn sich eine Clientanwendung mit Kerberos, Hashwert oder NTLM mit HTTPS im Server authentifiziert.
Das Kanalbindungstoken ist eine Eigenschaft des über TLS gesicherten Außenkanals und wird zur Bindung des Außenkanals an eine Konversation über den clientauthentifizierten Innenkanal verwendet.
Bei einem Man-in-the-Middle-Angriff, bei dem der SSL-Datenverkehr entschlüsselt und neu verschlüsselt wird, stimmt der Schlüssel nicht überein. AD FS stellt fest, dass sich zwischen dem Webbrowser und dem Dienst ein weiterer Kommunikationspartner (der Angreifer) befindet. Dies führt zu einem Fehler bei der Kerberos-Authentifizierung. Es wird ein Dialogfeld vom Typ 401 anstelle einer Benutzeroberfläche für das einmalige Anmelden angezeigt.
Mögliche Ursachen:
- ein beliebiges Objekt zwischen dem Browser und AD FS
- Fiddler
- Reverseproxys, die SSL-Bridging ausführen
Die Standardeinstellung für diesen Wert in AD FS lautet „Zulassen“. Mithilfe des PowerShell-Cmdlets Set-ADFSProperties -ExtendedProtectionTokenCheck None können Sie diese Einstellung ändern.
Weitere Informationen hierzu finden Sie unter Bewährte Methoden für die sichere Planung und Bereitstellung von AD FS.
Internet Explorer-Konfiguration
Hinweis
Wenn Sie Chrome verwenden, fügen Sie den Browser der Liste der von WIA unterstützten Benutzer-Agents hinzu.
Das Standardverhalten von Internet Explorer lautet wie folgt:
- Internet Explorer erhält von AD FS eine Antwort vom Typ 401 mit dem Begriff „NEGOTIATE“ im Header.
- Daraufhin fordert der Webbrowser ein Kerberos- oder NTLM-Ticket an und sendet es an AD FS.
- Befindet sich der Begriff „NEGOTIATE“ im Header, führt Internet Explorer dies ohne Benutzerinteraktion aus (SPNEGO). Dies gilt nur für Intranetsites.
Es gibt zwei mögliche Gründe für Fehler:
In den Eigenschaften von Internet Explorer wurde das Kontrollkästchen „Integrierte Windows-Authentifizierung aktivieren“ nicht aktiviert. Dieses befindet sich unter „Internetoptionen -> Erweitert -> Sicherheit“.
Die Sicherheitszonen sind nicht ordnungsgemäß konfiguriert.
FQDNs befinden sich nicht in der Intranetzone.
Die URL von AD FS befindet sich nicht in der Intranetzone.
