Fehlerbehebung bei der eingeschränkten Kerberos-Delegierung (KCD)-Konfigurationen mit Microsoft Entra Anwendungsproxy

Die Methoden für einmaliges Anmelden variieren von Anwendung zu Anwendung. Der Microsoft Entra-Anwendungsproxy stellt standardmäßig eine eingeschränkte Kerberos-Delegierung (KCD) bereit. Benutzer authentifizieren sich mit Kerberos bei privaten Anwendungen.

Dieser Artikel enthält einen einzigen Referenzpunkt zur Behandlung der am häufigsten auftretenden Probleme. Zudem wird die Diagnose von komplexeren Implementierungsproblemen erläutert.

Dieser Artikel geht von den folgenden Annahmen aus.

• Bereitstellung des Microsoft Entra-Anwendungsproxys und allgemeiner Zugriff auf Nicht-KCD-Anwendungen. Weitere Informationen finden Sie unter Erste Schritte mit Anwendungsproxy.
• Die veröffentlichte Anwendung basiert auf Internetinformationsdienste (Internet Information Services, IIS) und der Microsoft-Implementierung von Kerberos.
• Die Server- und Anwendungshosts befinden sich in einer einzelnen Microsoft Entra-Domäne. Mehr Informationen zu domänen- und gesamtstrukturübergreifenden Szenarien finden Sie im Whitepaper zur eingeschränkten Kerberos-Delegierung.
• Die Anwendung wird in einem Microsoft Entra ID-Mandanten mit aktivierter Vorauthentifizierung veröffentlicht. Benutzer werden mit formularbasierter Authentifizierung authentifiziert. Szenarien mit der Rich-Client-Authentifizierung sind nicht Gegenstand dieses Artikels.

Voraussetzungen

Vielmehr liegt die Antwort in den meisten Fällen bei einfachen Fehlkonfigurationen oder allgemeinen Fehlern. Überprüfen Sie alle Voraussetzungen in Verwenden des KCD-einmaligen Anmeldens mit dem Anwendungsproxy vor der Problembehandlung.

Konnectorhosts sind nicht auf die Kommunikation mit einem bestimmten lokalen Domänencontroller (DC) beschränkt. Überprüfen Sie den DC, der verwendet wird, da er sich ändern könnte.

Domänenübergreifende Szenarien beruhen auf Verweisen, die einen Connectorhost zu DCs weiterleiten, die sich möglicherweise außerhalb des lokalen Netzwerkumkreises befinden. In diesen Fällen ist es ebenso wichtig, den Datenverkehr auch an DCs weiterzuleiten, die andere entsprechende Domänen darstellen. Geschieht dies nicht, tritt bei der Delegierung ein Fehler auf.

Vermeiden Sie aktive IPS-Geräte (Intrusion Prevention System) oder IDS-Geräte (Intrusion Detection System) zwischen Konnectorhosts und DCs. Diese Geräte sind zu intrusiv und beeinträchtigen den Remoteprozeduraufruf (Remote Procedure Call, RPC)-Datenverkehr.

Testen Sie die Delegierung in einfachen Szenarien. Je mehr Variablen Sie einführen, desto schwieriger kann sich der Vorgang gestalten. Begrenzen Sie die Tests auf einen einzelnen Connector, um Zeit zu sparen. Fügen Sie weitere Konnectors hinzu, nachdem das Problem behoben wurde.

Auch Umgebungsfaktoren tragen möglicherweise zu einem Problem bei. Um dies zu verhindern, halten Sie die Architektur während der Tests so gering wie möglich. Beispielsweise sind falsch konfigurierte interne Firewall-Zugriffssteuerungslisten (Access Control Lists, ACLs) üblich. Wenn möglich, senden Sie sämtlichen Datenverkehr von einem Connector direkt an die DCs und die Back-End-Anwendung.

Ein Connector sollte am besten so nah wie möglich beim Ziel positioniert werden. Eine Firewall, die sich bei den Tests inline befindet, vergrößert die Komplexität nur unnötig und kann die Dauer Ihrer Prüfungen verlängern.

Wodurch lässt sich ein Problem bei der KCD erkennen? Es gibt mehrere häufige Anzeichen dafür, dass KCD-Einmaliges Anmelden fehlschlägt. Die ersten Anzeichen eines Problems treten im Browser auf.

Beide Bilder zeigen dasselbe Symptom: Einmaliges Anmelden-Fehler. Der Benutzerzugriff auf die Anwendung wurde verweigert.

Problembehandlung

Unterteilen Sie die Problembehandlung in drei Phasen.

Clientvorauthentifizierung

Der externe Benutzer authentifiziert sich über einen Browser. Die Möglichkeit, sich vor der Authentifizierung bei Microsoft Entra ID zu authentifizieren, ist erforderlich, damit das einmalige Anmelden (Single Sign-On, SSO) von KCD funktioniert. Testen Sie diese Möglichkeit, und beheben Sie ggf. auftretende Probleme. Die Vorauthentifizierungsphase hängt nicht mit der KCD oder der veröffentlichten Anwendung zusammen. Es ist einfach, Abweichungen zu korrigieren, indem Sie überprüfen, ob das betreffende Konto in der Microsoft Entra-ID vorhanden ist. Überprüfen Sie, ob die Anwendung nicht deaktiviert oder blockiert wurde. Die Fehlerantwort im Browser ist aussagekräftig genug, um die Ursache nachzuvollziehen.

Delegierungsdienst

Der private Netzwerkconnector, der ein Kerberos-Dienstticket für Benutzer aus einem Kerberos-Schlüsselverteilungscenter (Key Distribution Center, KDC) abruft.

Die externe Kommunikation zwischen dem Client und dem Azure-Front-End sollte keinen anderen Bezug zur KCD haben. Sie stellt lediglich die Funktionsweise der KCD sicher. Der Anwendungsproxy-Dienst wird mit einer gültigen Benutzer-ID bereitgestellt, die zum Abrufen eines Kerberos-Tickets verwendet wird. Ohne diese ID ist eine KCD nicht möglich, und ein Fehler tritt auf.

Die Fehlermeldungen im Browser bieten einige geeignete Hinweise zu den Fehlerursachen. Notieren Sie die Felder activity ID und timestamp in der Antwort. Die Informationen helfen, das Verhalten mit tatsächlichen Ereignissen im Anwendungsproxyereignisprotokoll zu korrelieren.

Die entsprechenden Einträge im Ereignisprotokoll weisen dann die Ereignis-IDs 13019 oder 12027 auf. Die Ereignisprotokolle für den Connector befinden sich unter Anwendungs- und Dienstprotokolle>Microsoft>Privates Microsoft Entra-Netzwerk>Connector>Admin.

1. Verwenden Sie einen A-Eintrag in Ihrem internen Domain Name System (DNS) für die Anwendungsadresse, und nicht CName.
2. Bestätigen Sie erneut, dass der Konnectorhost das Recht hat, den Dienstprinzipalnamen (SPN) des angegebenen Zielkontos zu delegieren. Stellen Sie außerdem erneut sicher, dass die Option Beliebiges Authentifizierungsprotokoll verwenden aktiviert ist. Weitere Informationen finden Sie im Artikel zur SSO-Konfiguration.
3. Stellen Sie sicher, dass nur eine Instanz des SPN in Microsoft Entra ID vorhanden ist. Geben Sie setspn -x über eine Eingabeaufforderung auf einem beliebigen Host aus, der Mitglied einer Domäne ist.
4. Stellen Sie sicher, dass eine Domänenrichtlinie erzwungen wird, die die Maximalgröße ausgestellter Kerberos-Token begrenzt. Die Richtlinie verhindert, dass der Konnector ein Token abruft, wenn er als überflüssig befunden wird.

Eine Netzwerkablaufverfolgung, die den Austausch zwischen dem Konnectorhost und einer eingeschränkten Kerberos-Domäne (KDC) erfasst, ist der nächste beste Schritt, um detailliertere Details zu den Problemen zu erhalten. Weitere Informationen finden Sie im vertiefenden Beitrag zur Problembehandlung.

Wenn die Ticketausstellung ordnungsgemäß funktioniert, wird in den Protokollen ein Ereignis angezeigt, laut dem ein Authentifizierungsfehler aufgetreten ist, weil die Anwendung den Code 401 zurückgegeben hat. Dieses Ereignis weist darauf hin, dass die Zielanwendung Ihr Ticket abgelehnt hat. Fahren Sie mit der nächsten Phase fort.

Zielanwendung

Der Consumer des Kerberos-Tickets, das vom Konnector bereitgestellt wurde. In dieser Phase hat der Konnector ein Kerberos-Dienstticket an das Back-End gesendet. Das Ticket ist ein Header in der ersten Anwendungsanforderung.

1. Überprüfen Sie mithilfe der internen URL der Anwendung, die im Portal definiert ist, dass direkt über den Browser auf dem Connectorhost auf die Anwendung zugegriffen werden kann. Dann können Sie sich erfolgreich anmelden. Details finden Sie auf der Seite des Connectors zur Problembehandlung.

2. Vergewissern Sie sich, dass die Authentifizierung zwischen dem Browser und der Anwendung Kerberos verwendet.

3. Führen Sie die Entwicklertools (F12) im Internet Explorer aus, oder verwenden Sie Fiddler auf dem Connectorhost. Wechseln Sie mithilfe der internen URL zur Anwendung. Überprüfen Sie die angebotenen Web-Autorisierungsheader, die in der Antwort der Anwendung zurückgegeben wurden, um sicherzustellen, dass entweder eine Aushandlung oder Kerberos vorhanden ist.

   • Das nächste Kerberos-Blob, das in der Antwort vom Browser an die Anwendung zurückgegeben wird, beginnt mit YII. Diese Buchstaben geben an, dass Kerberos ausgeführt wird. Der Microsoft NT LAN Manager (NTLM) beginnt hingegen immer mit TlRMTVNTUAAB, das NTLM Security Support Provider (NTLMSSP) lautet, wenn die Decodierung aus Base64 erfolgt ist. Wenn zu Beginn des Blobs TlRMTVNTUAAB angezeigt wird, ist Kerberos nicht verfügbar. Wenn TlRMTVNTUAAB nicht angezeigt wird, ist Kerberos voraussichtlich verfügbar.

     Hinweis

     Bei der Verwendung von Fiddler würde diese Methode die vorübergehende Deaktivierung des erweiterten Schutzes für die Konfiguration der Anwendung in den IIS erfordern.

     

   • Das Blob in dieser Abbildung beginnt nicht mit TIRMTVNTUAAB. In diesem Beispiel ist Kerberos verfügbar, weshalb das Kerberos-Blob nicht mit YII beginnt.

4. Entfernen Sie NTLM vorübergehend aus der Anbieterliste auf der IIS-Website. Rufen Sie die App direkt über den Internet Explorer auf dem Connectorhost auf. NTLM ist nicht mehr in der Anbieterliste enthalten. Sie können nur mithilfe von Kerberos auf die Anwendung zugreifen. Wenn beim Zugriff ein Fehler auftritt, liegt möglicherweise ein Problem mit der Konfiguration der Anwendung vor. Die Kerberos-Authentifizierung funktioniert nicht.

   • Wenn Kerberos nicht verfügbar ist, überprüfen Sie die Authentifizierungseinstellungen der Anwendung in den IIS. Stellen Sie sicher, dass im oberen Bereich Aushandeln und direkt darunter „NTLM“ aufgeführt wird. Wenn dort Nicht aushandeln, Kerberos oder aushandeln oder PKU2U angezeigt wird, fahren Sie nur fort, wenn Kerberos funktioniert.

     

   • Wenn Kerberos und NTLM vorhanden sind, deaktivieren Sie vorübergehend die Vorauthentifizierung für die Anwendung im Portal. Prüfen Sie, ob Sie über das Internet mithilfe der externen URL darauf zugreifen können. Sie werden aufgefordert, sich zu authentifizieren. Dies können Sie mit dem gleichen Konto tun, das Sie im vorherigen Schritt verwendet haben. Wenn dies nicht möglich ist, liegt ein Problem mit der Back-End-Anwendung vor, nicht mit der KCD.

   • Aktivieren Sie erneut die Vorauthentifizierung im Portal. Authentifizieren Sie sich über Azure, indem Sie versuchen, über die externe URL eine Verbindung mit der Anwendung herzustellen. Wenn beim einmaligen Anmelden ein Fehler auftritt, werden im Browser eine Fehlermeldung zu einem verbotenen Vorgang sowie das Ereignis 13022 im Protokoll angezeigt:

     Der private Microsoft Entra-Netzwerkconnector kann den Benutzer nicht authentifizieren, da der Back-End-Server auf Kerberos-Authentifizierungsversuche mit einem HTTP 401-Fehler reagiert.

     

   • Überprüfen Sie die IIS-Anwendung. Stellen Sie sicher, dass der konfigurierte Anwendungspool und der SPN für die Verwendung desselben Kontos in Microsoft Entra ID konfiguriert sind. Navigieren Sie in den IIS zur dargestellten Option wie in der folgenden Abbildung gezeigt.

     

     Nachdem Sie nun die Identität kennen, stellen Sie sicher, dass dieses Konto mit dem betreffenden SPN konfiguriert ist. z. B. setspn –q http/spn.wacketywack.com. Geben Sie in der Eingabeaufforderung den folgenden Text ein.

     

   • Überprüfen Sie den SPN, der über die Einstellungen der Anwendung im Portal definiert ist. Stellen Sie sicher, dass der gleiche für das Microsoft Entra-Zielkonto konfigurierte SPN vom App-Pool der Anwendung verwendet wird.

   • Navigieren Sie zu den IIS, und wählen Sie die Option Konfigurationseditor für die Anwendung aus. Navigieren Sie zu system.webServer/security/authentication/windowsAuthentication. Stellen Sie sicher, dass der Wert UseAppPoolCredentials auf True festgelegt ist.

     

     Ändern Sie den Wert in Wahr. Entfernen Sie alle zwischengespeicherten Kerberos-Tickets vom Back-End-Server, indem Sie den Befehl ausführen.

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

Wenn Sie den Kernelmodus aktiviert lassen, wird hierdurch die Leistung von Kerberos-Vorgängen verbessert. Aber es bewirkt auch, dass das Ticket für den angeforderten Dienst über das Computerkonto entschlüsselt wird. Dieses Konto wird auch als lokales System bezeichnet. Legen Sie diesen Wert auf True fest, um die KCD zu unterbrechen, wenn die Anwendung über mehr als einen Server in einer Farm gehostet wird.

• Deaktivieren Sie als weitere Überprüfung Erweiterter Schutz. In einigen Szenarien hat der Erweiterte Schutz die KCD unterbrochen, wenn sie in bestimmten Konfigurationen aktiviert wurde. In diesen Fällen wurde eine Anwendung als Unterordner der Standardwebsite veröffentlicht. Diese Anwendung ist nur für die anonyme Authentifizierung konfiguriert. Alle Dialogfelder sind ausgegraut, was darauf hindeutet, dass untergeordnete Objekte keine aktiven Einstellungen erben. Es wird empfohlen, dies zu testen. Denken Sie jedoch daran, diesen Wert sofern möglich wieder auf Aktiviert zu setzen.

  Nach dieser zusätzlichen Überprüfung sind Sie bestens vorbereitet, um die veröffentlichte Anwendung zu verwenden. Sie können mehr Konnector starten, die ebenfalls zum Delegieren konfiguriert sind. Weitere Informationen finden Sie in der ausführlicheren exemplarischen Vorgehensweise zur Problembehandlung beim Microsoft Entra-Anwendungsproxy.

Wenn dies dennoch keine Abhilfe leistet, kann Microsoft-Support Ihnen weiter helfen. Erstellen Sie direkt im Portal ein Supportticket.

Andere Szenarien

Der Microsoft Entra-Anwendungsproxy fordert vor dem Senden der Anforderung an eine Anwendung ein Kerberos-Ticket an. Bei einigen Anwendungen ist diese Authentifizierungsmethode unüblich. Bei diesen Anwendungen werden konventionellere Aushandlungen erwartet. Die erste Anforderung ist anonym, wodurch es der Anwendung ermöglicht wird, mit den Authentifizierungstypen zu antworten, die sie über eine 401-Meldung unterstützt. Diese Art der Kerberos-Aushandlung kann mithilfe der in diesem Dokument beschriebenen Schritte aktiviert werden: Eingeschränkte Delegierung von Kerberos für die einmalige Anmeldung.

Die Multi-Hop-Authentifizierung wird häufig in Szenarien verwendet, in denen eine Anwendung gestuft wird. Die Ebenen umfassen ein Back-End und ein Front-End. Beide Ebenen erfordern eine Authentifizierung. Beispiel: SQL Server Reporting Services. Weitere Informationen finden Sie unter Konfigurieren der eingeschränkten Kerberos-Delegierung für Webregistrierungsproxyseiten.

Nächste Schritte

Konfigurieren der KCD für eine verwaltete Domäne