Problembehandlung bei der eingeschränkten Kerberos-Delegierung

SSO-Methoden (Single Sign-On) variieren zwischen Anwendungen. Der Microsoft Entra-Anwendungsproxy stellt standardmäßig eine eingeschränkte Kerberos-Delegierung (KCD) bereit. Im Anwendungsproxy authentifiziert sich ein Benutzer mithilfe von Kerberos bei einer privaten Anwendung.

In diesem Artikel wird beschrieben, wie Sie die häufigsten Probleme bei der KCD-Konfiguration beheben. Es enthält Diagnoseschritte, die Sie für komplexere Implementierungen ausführen können.

Dieser Artikel geht von den folgenden Annahmen aus:

• Der Microsoft Entra-Anwendungsproxy wird bereitgestellt und hat allgemeinen Zugriff auf Nicht-KCD-Anwendungen.

  Weitere Informationen finden Sie unter "Erste Schritte mit dem Anwendungsproxy".

• Eine veröffentlichte Anwendung basiert auf Internetinformationsdienste (IIS) und der Microsoft-Implementierung von Kerberos.

• Server- und Anwendungshosts befinden sich in einer einzigen Microsoft Entra-Domäne.

  Weitere Informationen domänenübergreifenden und Gesamtstrukturszenarien finden Sie im Whitepaper Grundlegendes zur eingeschränkten Kerberos-Delegierung mit dem Anwendungsproxy.

• Die Anwendung wird in einem Microsoft Entra-Mandanten mit aktivierter Vorauthentifizierung veröffentlicht. Benutzern wird erwartet, dass sie mithilfe der formularbasierten Authentifizierung authentifiziert werden.

  Rich-Client-Authentifizierungsszenarien werden in diesem Artikel nicht behandelt.

Überlegungen

In der folgenden Liste werden grundlegende Überlegungen zur KCD-Konfiguration und Verwendung mit dem Microsoft Entra-Anwendungsproxy beschrieben:

• Grundlegende Fehlkonfigurationen oder allgemeine Fehler verursachen die meisten Probleme. Bevor Sie mit der Problembehandlung beginnen, überprüfen Sie alle Voraussetzungen in der Verwendung von KCD-SSO mit Anwendungsproxy.

• Connectorhosts sind nicht auf die Kommunikation mit einem bestimmten lokalen Domänencontroller (DC) beschränkt. Überprüfen Sie den von Ihnen verwendeten DC, da er sich möglicherweise ändert.

• Domänenübergreifende Szenarien basieren auf Empfehlungen, die einen Connectorhost an DCs weiterleiten, die sich möglicherweise außerhalb des lokalen Netzwerkperimeters befinden. In diesen Fällen ist es ebenso wichtig, Datenverkehr weiter an DCs zu senden, die andere entsprechende Domänen darstellen. Wenn Sie das nicht tun, schlägt die Delegierung fehl.

• Vermeidung aktiver Intrusion Prevention System (IPS)- oder Intrusion Detection System (IDS)-Geräte zwischen Connector-Hosts und Domänencontrollern (DCs), da sie den Kernverkehr von Remoteprozeduraufrufen (RPC) stören können.

• Testen Sie die Delegierung in einem einfachen Szenario. Je mehr Variablen Sie in einem Szenario einführen, desto komplexer ist die Konfiguration und Problembehandlung. Um Zeit zu sparen, beschränken Sie Ihre Tests auf einen einzelnen Connector. Fügen Sie weitere Connectors hinzu, nachdem das Problem behoben wurde.

• Umweltfaktoren können zur Ursache eines Problems beitragen. Um diese Faktoren zu vermeiden, minimieren Sie die Architektur während des Tests so weit wie möglich. Beispielsweise sind falsch konfigurierte interne Firewall-Zugriffssteuerungslisten (ACLs) üblich. Senden Sie nach Möglichkeit den gesamten Datenverkehr von einem Connector direkt an die DCs und die Back-End-Anwendung.

• Der beste Ort zum Positionieren von Verbindern ist so nah wie möglich an ihren Zielen. Eine Firewall, die beim Testen des Connectors inline geschaltet ist, fügt unnötige Komplexität hinzu und kann Ihre Untersuchungen verzögern.

• Was weist auf ein KCD-Problem hin? Mehrere häufige Fehler deuten darauf hin, dass KCD-SSO fehlschlägt. Die ersten Anzeichen eines Problems werden im Browser angezeigt.

  Beide der folgenden Screenshots zeigen dasselbe Symptom für SSO-Fehler: Der Benutzerzugriff auf die Anwendung wird verweigert.

  

  

Fehlersuche

Sie können KCD-Probleme in drei Phasen behandeln. Überprüfen Sie diese Teile des KCD-Prozesses in der folgenden Reihenfolge:

• Clientvorauthentifizierung
• Der Delegierungsdienst
• Die Zielanwendung

Clientvorauthentifizierung

Clientvorauthentifizierung bezieht sich auf einen externen Benutzer, der über einen Browser in einer Anwendung authentifiziert wird. Die Möglichkeit, die Microsoft Entra-ID vorab zu authentifizieren, ist erforderlich, damit KCD SSO funktioniert.

Testen Sie zuerst die Clientvorauthentifizierung, und beheben Sie alle Probleme. Die Vorauthentifizierungsphase bezieht sich nicht auf KCD oder auf die veröffentlichte Anwendung. Es ist einfach, Abweichungen zu korrigieren, indem Sie überprüfen, ob das Betreffkonto in der Microsoft Entra-ID vorhanden ist. Überprüfen Sie, ob die Anwendung nicht verfügbar oder blockiert ist. Die Fehlerantwort im Browser ist in der Regel beschreibend genug, um die Ursache zu erklären.

Der Delegierungsdienst

Der Kerberos-Delegierungsdienst ist der private Netzwerkconnektor, der ein Kerberos-Dienstticket aus einem Kerberos-Schlüsselverteilungszentrum (Kerberos Key Distribution Center, KDC) abruft. Der App-Benutzer authentifiziert sich über das Ticket mit der Anwendung.

Die externe Kommunikation zwischen dem Client und dem Azure-Front-End hat keine Auswirkungen auf die eingeschränkte Delegierung. Diese Kommunikation stellt nur sicher, dass KCD funktioniert. Dem Anwendungsproxydienst wird eine gültige Benutzer-ID zur Verfügung gestellt, mit der ein Kerberos-Ticket ausgestellt wird. Ohne diese ID kann KCD nicht auftreten, und SSO schlägt fehl.

Browserfehlermeldungen enthalten nützliche Informationen dazu, warum die Anmeldung fehlschlägt. Notieren Sie die Werte für TransactionID und Timestamp in der Antwort auf die Anwendungsanmeldung. Die Informationen helfen beim Korrelieren des Verhaltens mit Ereignissen, die im Anwendungsproxyereignisprotokoll angezeigt werden.

Die entsprechenden Einträge im Ereignisprotokoll sind Ereignis-IDs 13019 oder 12027. Um die Connectorereignisprotokolle anzuzeigen, wechseln Sie zu Anwendungs- und Dienstprotokolle>Microsoft>Privates Microsoft Entra-Netzwerk>Connectors>Admin.

So beheben Sie ein Problem mit eingeschränkter Delegierung:

1. Verwenden Sie in Ihrem internen Domain Name System (DNS) für die Anwendungsadresse einen A-Eintrag und keinen CNAME-Eintrag.
2. Stellen Sie sicher, dass der Connectorhost mit Berechtigungen zum Delegieren an den Dienstprinzipalnamen des Zielkontos konfiguriert ist. Stellen Sie sicher, dass "Authentifizierungsprotokoll verwenden " ausgewählt ist. Weitere Informationen finden Sie unter SSO-Konfiguration.
3. Stellen Sie sicher, dass nur eine Instanz des SPN in der Microsoft Entra-ID vorhanden ist. Führen Sie zum Überprüfen eines einzelnen SPN an einer Eingabeaufforderung auf einem beliebigen Domänenmitgliedshost setspn -x aus.
4. Überprüfen Sie, ob eine Domänenrichtlinie, die die maximale Größe ausgestellter Kerberos-Token begrenzt, erzwungen wird. Die Richtlinie verhindert, dass der Connector ein Token abruft, wenn die Tokengröße ein festgelegtes Maximum überschreitet.
5. Das Ausführen einer Netzwerkablaufverfolgung, die den Austausch zwischen dem Connectorhost und einer Domänen-KCD erfasst, ist der nächste beste Schritt, um weitere Details zum Problem zu erhalten. Weitere Informationen finden Sie im ausführlichen Whitepaper zur Problembehandlung des Microsoft Entra-Anwendungsproxys.

Wenn die Ticketerstellung ordnungsgemäß funktioniert, zeigen die Protokolle wahrscheinlich ein Ereignis an, das angibt, dass die Authentifizierung fehlgeschlagen ist, da die Anwendung einen Fehler von 401 zurückgegeben hat. Dieses Ereignis gibt an, dass die Zielanwendung das Ticket abgelehnt hat. Wechseln Sie zur nächsten Phase der Problembehandlung.

Die Anwendung

Die Zielanwendung verarbeitet das vom Connector bereitgestellte Kerberos-Ticket. In dieser Phase enthält der Connector ein Kerberos-Dienstticket als Header in der ersten Anwendungsanforderung an das Back-End.

So beheben Sie ein Anwendungsproblem:

1. Stellen Sie sicher, dass auf die Anwendung zugegriffen werden kann. Melden Sie sich direkt vom Browser auf dem Connectorhost mithilfe der internen URL an, die im Azure-Portal definiert ist. Wenn die Anmeldung erfolgreich ist, kann auf die Anwendung zugegriffen werden.

2. Überprüfen Sie, ob der Browser und die Anwendung Kerberos für die Authentifizierung verwenden. Verwenden Sie vom Connectorhost die DevTools von Internet Explorer (drücken Sie F12) oder Fiddler , um über die interne URL auf die Anwendung zuzugreifen. Suchen Sie in den Webautorisierungsheadern in der Antwort der Anwendung nach "Negotiate" oder "Kerberos".

   Die Browserantwort auf die Anwendung enthält ein Kerberos-Blob, das mit YII beginnt, was bestätigt, dass Kerberos ausgeführt wird. Im Gegensatz dazu beginnt immer eine Antwort von Microsoft NT LAN Manager (NTLM) mit TlRMTVNTUAAB. Wenn diese Antwort von Base64 decodiert wird, ergibt sich NTLM Security Support Provider (NTLMSSP). Wenn die Blobs mit TlRMTVNTUAABbeginnen, ist Kerberos nicht verfügbar. Ist dies nicht der Fall, ist Kerberos wahrscheinlich verfügbar.

   Hinweis

   Wenn Sie Fiddler verwenden, müssen Sie vorübergehend den erweiterten Schutz für die Anwendungskonfiguration in IIS deaktivieren.

   

   Der Blob in diesem Screenshot beginnt nicht mit TIRMTVNTUAAB. In diesem Beispiel ist Kerberos verfügbar, und das Kerberos-Blob beginnt nicht mit YII.

3. Entfernen Sie auf der IIS-Website ntLM vorübergehend aus der Anbieterliste. Greifen Sie direkt über Internet Explorer auf dem Connectorhost auf die App zu. NTLM befindet sich nicht mehr in der Liste der Anbieter, sodass Sie nur mithilfe von Kerberos auf die Anwendung zugreifen können. Wenn der Zugriff fehlschlägt, wird ein Problem mit der Konfiguration der Anwendung angegeben. Die Anwendung verarbeitet keine Kerberos-Authentifizierung.

4. Wenn Kerberos nicht verfügbar ist, überprüfen Sie die Authentifizierungseinstellungen der Anwendung in IIS. Stellen Sie sicher, dass "Negotiate" oben aufgeführt ist, und NTLM befindet sich direkt darunter. Wenn "Nicht aushandeln", "Kerberos" oder "Aushandeln" oder"PKU2U" angezeigt wird, fahren Sie nur fort, wenn Kerberos funktionsfähig ist.

   

5. Wenn Kerberos und NTLM vorhanden sind, deaktivieren Sie im Portal vorübergehend die Vorauthentifizierung für die Anwendung. Versuchen Sie, mithilfe der externen URL auf die Anwendung in einem Browser zuzugreifen. Sie werden aufgefordert, sich zu authentifizieren. Verwenden Sie dasselbe Konto, das Sie in einem vorherigen Schritt verwendet haben. Wenn Sie sich nicht authentifizieren und anmelden können, liegt ein Problem mit der Back-End-Anwendung vor, nicht bei KCD.

6. Aktivieren Sie die Vorauthentifizierung im Portal erneut. Authentifizieren Sie sich über Azure, indem Sie versuchen, über die externe URL eine Verbindung mit der Anwendung herzustellen. Wenn SSO fehlschlägt, sehen Sie eine Fehlermeldung "Verboten" im Browser und die Ereignis-ID 13022 im Protokoll.

   Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.

   

7. Überprüfen Sie die IIS-Anwendung. Stellen Sie sicher, dass der konfigurierte Anwendungspool und der SPN für die Verwendung desselben Kontos in der Microsoft Entra-ID konfiguriert sind. Wechseln Sie in IIS wie im folgenden Screenshot gezeigt zu dem Ordner:

   

   Überprüfen Sie die Identität, und stellen Sie dann sicher, dass dieses Konto mit dem SPN konfiguriert ist. Führen Sie an einer Eingabeaufforderung z. B. Folgendes aus: setspn –q http/spn.contoso.com.

   

8. Überprüfen Sie im Portal den definierten SPN anhand der Anwendungseinstellungen. Stellen Sie sicher, dass der App-Pool der Anwendung denselben SPN verwendet, der für das Microsoft Entra-Zielkonto festgelegt ist.

9. Wählen Sie in IIS die Konfigurations-Editor-Option für die Anwendung aus. Wechseln Sie zu "system.webServer/security/authentication/windowsAuthentication". Stellen Sie sicher, dass der Wert für UseAppPoolCredentials"True" lautet.

   

   Ändern Sie den Wert bei Bedarf in "True ". Entfernen Sie alle zwischengespeicherten Kerberos-Tickets vom Back-End-Server, indem Sie den folgenden Befehl ausführen:

   Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
   

10. Wenn der Kernelmodus aktiviert ist, verbessern sich Kerberos-Vorgänge. Das Ticket für den angeforderten Dienst muss jedoch auch mit dem Computerkonto entschlüsselt werden. Dieses Konto wird auch als lokales System bezeichnet. Legen Sie diesen Wert auf "True" fest, um KCD aufzubrechen, wenn die Anwendung auf mehreren Servern in einer Farm gehostet wird.

11. Deaktivieren Sie als weitere Überprüfung den erweiterten Schutz. In einigen Testszenarien brach der erweiterte Schutz KCD, wenn er in bestimmten Konfigurationen aktiviert wurde. In diesen Fällen wurde eine Anwendung als Unterordner der Standardwebsite veröffentlicht. Diese Anwendung ist nur für anonyme Authentifizierung konfiguriert. Alle Dialogfelder sind inaktiv, ohne verfügbare Auswahl, was nahelegt, dass untergeordnete Objekte keine aktiven Einstellungen erben würden. Wir empfehlen, den Test durchzuführen, aber vergessen Sie nicht, diesen Wert nach Möglichkeit wieder zu aktivieren .

    Diese zusätzliche Prüfung stellt sicher, dass Sie bereit sind, Ihre veröffentlichte Anwendung zu nutzen. Sie können weitere Connectors generieren, die auch zum Delegieren konfiguriert sind. Weitere Informationen finden Sie in der ausführlichen technischen Anleitung zur Problembehandlung beim Microsoft Entra-Anwendungsproxy.

Wenn Sie das Problem mit der Anwendungsauthentifizierung immer noch nicht beheben können, erstellen Sie ein Supportticket direkt im Portal.

Andere Szenarien

Der Microsoft Entra-Anwendungsproxy fordert ein Kerberos-Ticket an, bevor es eine Anforderung an eine Anwendung sendet. Einige Anwendungen unterstützen diese Methode der Authentifizierung nicht. Diese Anwendungen sind so eingerichtet, dass sie auf herkömmlichere Authentifizierungsschritte reagieren. Die erste Anforderung ist anonym, sodass die Anwendung durch einen 401-Fehler mit den Authentifizierungstypen reagieren kann, die sie unterstützt. Sie können diese Art der Kerberos-Aushandlung einrichten, indem Sie die Schritte ausführen, die in Eingeschränkte Kerberos-Delegierung für einmaliges Anmelden (SSO) beschrieben sind.

Die Multi-Hop-Authentifizierung wird häufig verwendet, wenn eine Anwendung gestuft wird. Die Ebenen umfassen ein Back-End und ein Front-End. Beide Ebenen erfordern eine Authentifizierung. Sie können z. B. eine mehrstufige Anwendung mithilfe von SQL Server Reporting Services erstellen. Weitere Informationen finden Sie unter Konfigurieren der eingeschränkten Kerberos-Delegierung für Webregistrierungsproxyseiten.

Verwandte Inhalte

• Einrichten von KCD für eine verwaltete Domäne