Diagnoseseiten für die Problembehandlung bei der integrierten Windows-Authentifizierung

Die Problembehandlung bei Fehlern bei der integrierten Windows-Authentifizierung kann schwierig sein, insbesondere wenn Sie mit der Kerberos-Anmeldeinformationsdelegierung umgehen. Obwohl es eine detaillierte Checkliste gibt, wie Sie sicherstellen können, dass Sie über die richtige Konfiguration für Internetinformationsdienste (IIS) verfügen, um mit der integrierten Windows-Authentifizierung zu arbeiten und optional die Delegierung von Anmeldeinformationen zu verwenden, zielt dieser Artikel speziell auf die folgenden Szenarien ab:

• Sie können sich über den Clientcomputer bei Ihrer Zielwebsite anmelden, aber Sie sind nicht sicher, ob Sie NTLM oder Kerberos als Authentifizierungsmechanismus verwenden.
• Sie können sich bei Ihrer Zielwebsite anmelden, aber Sie werden aufgefordert, sich nur nach der Eingabe einer Benutzernamen- und Kennwortkombination anzumelden.
• Sie können auf Ihre Zielwebsite auf dem Front-End-Server zugreifen, schlägt jedoch fehl, wenn Sie eine Aktion initiieren, die den Front-End-Server erfordert, um einen Back-End-HTTP-Endpunkt mithilfe der Anmeldeinformationen des authentifizierten Benutzers aufzurufen.

Berücksichtigen Sie für die Zwecke dieses Artikels das folgende Layout:

• Client 1 ist die in die Domäne eingebundene Arbeitsstation oder laptop, von der der hypothetische Benutzer alle Verbindungsversuche initiiert.

• Web-serv1 ist der Front-End-IIS-Server, auf dem eine ASP.NET -Website (auf .NET Framework) gehostet wird, die die integrierte Windows-Authentifizierung verwendet und mit der Identität eines Dienstkontos ausgeführt wird: domäne\serviceaccount.

• Web-serv2 ist der Back-End-Webserver, der auch eine ASP.NET -Website (auf .NET Framework) hostet, die API-Endpunkte für die Front-End-Anwendung verfügbar macht. Es ist auch so konfiguriert, dass Anforderungen zugelassen werden, die die integrierte Windows-Authentifizierung verwenden und in einem Anwendungspool ausgeführt werden, der domäne\serviceapiaccount als Anwendungspoolidentität verwendet.

Um die Datensammlung für diese Szenarien zu vereinfachen und nicht auf externe Datenerfassungstools wie Fiddler oder WireShark zu verlassen (da Verbindungen zwischen den drei Computern HTTPS verwenden und daher alle Austausche zwischen ihnen verschlüsselt werden), verwenden Sie die beiden eigenständigen Diagnoseseiten in ASP.NET Eigenständige Seiten zur Problembehandlung von Windows Integrated Authentication-Problemen in IIS.

Problembehandlung für Seiten

Die beiden Seiten werden in ASP.NET Webformularen codiert. Sie sollen den Code und das Markup für die Seite in einer Datei bündeln, die in den Stamm der Webanwendung kopiert werden kann, die Sie behandeln möchten, ohne dass kompiliert oder bereitgestellt werden muss. Die Seiten sind:

• WhoAmI.aspx – Diese Seite ermöglicht das Dumping authentifizierungsbezogener Informationen wie:

  • Die Authentifizierungsmethode, die für den Zugriff auf die Zielwebsite verwendet wird. Wenn die Methode auf dem Aushandlungsanbieter für die integrierte Windows-Authentifizierung basiert, zeigt die Seite an, ob Kerberos oder NTLM zum Authentifizieren des Benutzers verwendet wird.

  • Die Identität des Kontos, das den Anwendungspool ausführt, der die Website hosten soll.

  • Die Identitätswechselebene für den authentifizierten Benutzer. Wenn Kerberos für die Authentifizierung und nicht eingeschränkte Delegierung von Anmeldeinformationen verwendet wird, wird die Identitätswechselstufe als Stellvertretung markiert. Andernfalls wird sie im Falle einer eingeschränkten Delegierung oder eines einfachen Identitätswechsels als Identitätswechsel markiert.

  • Die Identität des authentifizierten Benutzers und der Gruppen, zu denen der Benutzer gehört.

  • Die Identität des Kontos, das den Code der Seite ausführt (es kann sich um einen authentifizierten Benutzer oder einen Anwendungspoolbenutzer handeln, abhängig von den Identitätswechseleinstellungen ).

  • Alle Werte der Anforderungsheader für Anforderungen, die auf der Seite WhoAmI.aspx wiederhergestellt aus den IIS-Servervariablen stammen.

    

• ScrapperTest.aspx – Diese Seite wird für die Arbeit mit der WhoAmI.aspx Seite vorgenommen, sodass Anforderungen vom Front-End-Server an alle URLs auf dem Back-End-Server weitergeleitet werden können. Auf der Seite wird eine Benutzeroberfläche angezeigt, über die ein Benutzer Folgendes ermöglichen kann:

  • Geben Sie die gewünschte URL der Back-End-Serverressource ein, die die Seite laden soll.

  • Ermitteln Sie, ob sie beim Laden der ScrapperTest.aspx-Seite authentifiziert sind und ob sie authentifiziert werden, bei welchen Benutzern sie authentifiziert werden.

  • In dem Szenario, in dem der Benutzer tatsächlich authentifiziert ist, ermöglicht ein Kontrollkästchen, die Anmeldeinformationen des Benutzers wiederzuverwenden, wenn versucht wird, die im URL-Textfeld angegebene Back-End-Ressource zu laden.

    

Vorgehensweise bei der Bereitstellung

Da beide Seiten eigenständig sind, ist nur folgendes erforderlich:

1. Laden Sie die Seiten aus dem GitHub-Repository herunter.
2. Kopieren Sie die WhoAmI.aspx Seite oder beide Seiten in den Stamm ihrer Zielwebanwendungen, die in IIS ausgeführt werden.
3. Stellen Sie eine Anforderung an die URL Ihrer Website, die /WhoAmI.aspx oder /ScrapperTest.aspx anfügen, je nachdem, auf welche Seite Sie zugreifen möchten.

Verbrauch

Das erste Verwendungsszenario versucht zu ermitteln, welche Authentifizierungsmethode für den Zugriff auf eine bestimmte Website oder Webanwendung verwendet wird, die auf IIS gehostet wird. Für diese Seite können Sie Anforderungen an die WhoAmI.aspx Seite stellen, die Sie zuvor auf der Website bereitgestellt haben.

• Auf der ersten Anforderung zeigt die Seite die Authentifizierungsinformationen an. Wenn der Negotiate-Anbieter für die integrierte Windows-Authentifizierung verwendet wird, wird auch das verwendete Authentifizierungsprotokoll aufgeführt: Kerberos oder NTLM.

• Nachfolgende Anforderungen in einem Szenario, in dem Negotiate als Anbieter für die integrierte Windows-Authentifizierung verwendet wird, zeigt nur die sitzungsbasierte Bezeichnung neben dem Authentifizierungstyp an. Weitere Informationen finden Sie unter "Request-based versus Session-based Kerberos Authentication( or the AuthPersistNonNTLM parameter)".

• Alle anderen Authentifizierungsinformationen, z. B. der Anwendungspoolbenutzer, authentifizierter Benutzer, Ausführungsbenutzerdetails und die Kopfzeilen der eingehenden Anforderung, werden für jede Anforderung angezeigt.

Auf der Seite WhoAmI.aspx wird unten auch ein kleines Formular angezeigt. Mit diesem Formular können Sie Anforderungen an den Server ausgeben POST , um zu testen, wie sich der Browser verhält, wenn diese Arten von Anforderungen ausgegeben werden. Wenn die Seite länger als 60 Sekunden im Leerlauf ist, wird die TCP-Verbindung (Transmission Control Protocol) zum Herunterladen der Seite in den Browser und die Authentifizierung durch den Server aufgrund von Inaktivität getrennt. Wenn Sie also eine POST Anforderung stellen, wird eine neue TCP-Verbindung geöffnet, und Sie müssen sich erneut authentifizieren. Es gibt eine Subtilität mit POST Anforderungen:

1. Der Browser sendet zuerst die HTTP-Anforderungsheader POST .
2. Anschließend wird der Textkörper der POST Anforderung ausgelöst, der die aus den verschiedenen Eingabefeldern auf dem AUF der Seite angezeigten HTTP-Formular erfassten Informationen enthält.

Wenn der Browser nach dem Senden der Kopfzeilen der POST Anforderung nicht wartet, sondern stattdessen den Text direkt an eine nicht authentifizierte Verbindung sendet, können die folgenden Probleme auftreten:

• Der Server empfängt die POST Anforderungsheader und da die Verbindung nicht authentifiziert wird (vorausgesetzt, die integrierte Windows-Authentifizierung oder eine andere abfragebasierte Authentifizierung wird verwendet), gibt er eine 401-Antwort mit dem entsprechenden HTTP-Header fürWWW-Authenticate die Authentifizierung aus.
• Während dieser Zeit hat der Browser den POST Anforderungstext bereits gesendet, bevor die 401-Antwort vom Server empfangen wird.
• Der Server empfängt dann einen nicht authentifizierten POST Anforderungstext für eine Verbindung, die er zuvor für den Client angegeben hat, dass die Authentifizierung erforderlich ist.
• Dies führt dazu, dass die zugrunde liegende TCP-Verbindung vom Server getrennt wird und der Browser möglicherweise eine Meldung "Webseite ist nicht verfügbar" anzeigt.

Die ScrapperTest.aspx Seite wird verwendet, um die Delegierung von Anmeldeinformationsszenarien vom Front-End-Server zum Back-End-Serverendpunkt zu testen. Sobald die Seite vom Clientbrowser angefordert wurde, bietet sie eine Benutzeroberfläche, die Folgendes zulässt:

• Geben Sie die Back-End-Endpunkt-URL ein, mit der der Front-End-Server eine Verbindung herstellen soll.
• Überprüfen, ob der Benutzer auf dem Front-End authentifiziert ist und welcher Benutzername zum Herstellen einer Verbindung mit dem Front-End-Server verwendet wird.
• Entscheiden (falls die Authentifizierung für den Zugriff auf die ScrapperTest.aspx Seite verwendet wird), wenn die Anmeldeinformationen des authentifizierten Benutzers mit der Anforderung an den Back-End-Server übergeben werden sollen (wenn Identitätswechsel und Delegierung möglich sind).

Sobald die Schaltfläche "Scrap Page " ausgewählt ist, gibt der Code der ScrapperTest.aspx Seite eine GET Anforderung für die angegebene Ziel-URL aus. Wenn das Kontrollkästchen "Anmeldeinformationen verwenden" aktiviert ist und die Authentifizierung erforderlich ist, um auf den angegebenen Back-End-Endpunkt zuzugreifen, werden die Anmeldeinformationen des authentifizierten Benutzers auch verwendet, um die Anforderung zu stellen. Wenn eine Anforderung erfolgreich ist, wird das Ergebnis im Textbereichssteuerelement der Seite als unformatierte HTTP-Ausgabe der empfangenen Antwort angezeigt.

Ein Verwendungsszenario, das wir uns vorstellen, besteht darin, die ScrapperTest.aspx Seite und die WhoAmI.aspx Seite in der ASP.NET Anwendung zu platzieren, die auf dem Back-End-Server kontaktiert werden würde. Daher wird die von der ScrapperTest.aspx Seite wiederhergestellte HTTP-Antwort die HTML-Ausgabe der WhoAmI.aspx-Seite sein, wenn sie auf dem Back-End ausgeführt wird. Diese Ausgabe kann dann ausgewertet werden, um zu verstehen, wie die Anforderung auf dem Back-End authentifiziert wurde und welche Konten verwendet wurden.

Weitere Informationen

Weitere Informationen zum Einrichten der integrierten Windows-Authentifizierung mithilfe von Kerberos finden Sie unter:

• Behandeln von Kerberos-Fehlern in Internet Explorer
• Nicht eingeschränkte Kerberos-Double-Hop-Authentifizierung mit Microsoft Edge (Chromium)
• Anforderungsbasierte und sitzungsbasierte Kerberos-Authentifizierung (oder der Parameter AuthPersistNonNTLM)