Freigeben über

Nicht eingeschränkte Kerberos-Double-Hop-Authentifizierung mit Microsoft Edge (Chromium)

Gilt für: Internetinformationsdienste

Einführung

Das Einrichten der Windows-Authentifizierung basierend auf dem Kerberos-Authentifizierungsprotokoll kann ein komplexer Vorgang sein, insbesondere bei Szenarien wie der Delegierung der Identität von einem Front-End-Standort zu einem Back-End-Dienst im Kontext von IIS und ASP.NET. Führen Sie die Schritte dieses Artikels aus, um die Delegierung von Authentifizierungstickets einzurichten und Dienste mit einem modernen Browser wie Microsoft Edge Version 87 oder höher zu verwenden.

In diesem Artikel wird davon ausgegangen, dass Sie eine Architektur einrichten, die dem im folgenden Diagramm dargestellten ähnelt:

Diagramm, das die Architektur der Windows-Authentifizierung basierend auf dem Kerberos-Authentifizierungsprotokoll zeigt.

  • Der Computer "Workstation-Client1" ist Teil desselben Active Directory wie der primäre Webserver, der als Primary-IIS-SRV bezeichnet wird, und dem Back-End-Webserver, der als Back-End-Web-SRV bezeichnet wird.
  • Benutzer des Computers Workstation-Client1 melden sich mit dem Windows Active Directory-Konto beim Computer an.
  • Anschließend startet er einen Browser (Microsoft Edge), navigiert zu einer Website, die sich auf dem Webserver befindet. Dabei handelt es sich um den Aliasnamen, der für Primary-IIS-SRV verwendet wird, und die Authentifizierung über integrierte Windows-Authentifizierung mithilfe von Kerberos.
  • Die Website, die sich auf Dem Webserver befindet, führt HTTP-Aufrufe mithilfe der Anmeldeinformationen des authentifizierten Benutzers an API-Server (der Alias für Back-End-Web-SRV) aus, um Anwendungsdaten im Auftrag von Benutzern mithilfe der Kerberos-Anmeldeinformationsdelegierung abzurufen.

Die folgenden Schritte helfen Ihnen bei der Problembehandlung bei diesem Szenario: Das Setup funktioniert mit Internet Explorer, aber wenn Benutzer Microsoft Edge einführen, können sie das Feature für die Delegierung von Anmeldeinformationen nicht mehr verwenden. Informationen zur Verwendung der Kerberos-Anmeldeinformationsdelegierung finden Sie zuerst bei der Problembehandlung bei Kerberos-Fehlern in Internet Explorer .

Eingeschränkte oder nicht eingeschränkte Delegierung

In dem oben genannten Szenario ermöglichen beide Konfigurationen benutzern das Delegieren von Anmeldeinformationen von ihrer Benutzersitzung auf Computer Workstation-Client1 an den Back-End-API-Server, während eine Verbindung über den Front-End-Webserver hergestellt wird.

In einer nicht eingeschränkten Kerberos-Delegierungskonfiguration wird die Anwendungspoolidentität auf Dem Webserver ausgeführt und in Active Directory so konfiguriert, dass sie für die Delegierung an einen beliebigen Dienst vertrauenswürdig ist. Das Konto des Anwendungspools, das auf Dem Webserver ausgeführt wird, kann die Anmeldeinformationen authentifizierter Benutzer der Website, die auf diesem Server gehostet wird, an einen anderen Dienst im Active Directory delegieren. Beispielsweise ein SMTP-Server, ein Dateiserver, ein Datenbankserver, ein anderer Webserver usw. Dies wird als nicht eingeschränkte Delegierung bezeichnet, da das Anwendungspoolkonto über die Berechtigung (nicht eingeschränkt) verfügt, Anmeldeinformationen an jeden Dienst zu delegieren, den es kontaktiert.

In einer eingeschränkten Delegierungskonfiguration kann das Active Directory-Konto, das als Anwendungspoolidentität verwendet wird, die Anmeldeinformationen authentifizierter Benutzer nur an eine Liste der Dienste delegieren, die zum Delegieren autorisiert wurden. Wenn die Webanwendung, die sich auf dem Server namens "Web-Server" befindet, auch eine Datenbank kontaktieren und sich im Namen des Benutzers authentifizieren muss, muss dieser Dienstprinzipalname (SPN) der Liste der autorisierten Dienste hinzugefügt werden.

Eingeschränkte Delegierung ist sicherer als nicht eingeschränkte Delegierung basierend auf dem Prinzip der geringsten Rechte. Eine Anwendung erhält die Rechte, die sie benötigen, um zu funktionieren und nichts mehr, während eine nicht eingeschränkte Delegierung einer Anwendung erlaubt, ressourcen zu kontaktieren, die er nicht im Namen des Benutzers kontaktieren sollte.

Wie sie wissen, ob das auf dem Client abgerufene Kerberos-Ticket, das an den Webserver gesendet werden soll, eingeschränkte oder nicht eingeschränkte Delegierungen verwendet?

Verwenden Sie das in Windows vorhandene klist-Befehlstool, um den Cache von Kerberos-Tickets vom Clientcomputer aufzuführen (Workstation-Client1 im obigen Diagramm). Suchen Sie nach einem Ticket mit dem Namen HTTP/<Name des Webservers>. Hinweis: <Der Name des Webservers> ist der SPN des Diensts, den Sie über Kerberos kontaktieren und authentifizieren möchten. Das Ticket enthält auch ein paar Flags. Zwei davon sind von Interesse: forwardable und ok_as_delegate.

  • Das erste Kennzeichen gibt an, forwardabledass das KDC (Key Distribution Center) bei Bedarf ein neues Ticket mit einer neuen Netzwerkmaske ausgeben kann. Dies ermöglicht es einem Benutzer, sich bei einem Remotesystem anzumelden und für das Remotesystem ein neues Ticket im Namen des Benutzers zu erhalten, um sich bei einem anderen Back-End-System anzumelden, als ob sich der Benutzer lokal beim Remotesystem angemeldet hatte.

  • Das zweite Flag gibt an, ok_as_delegate dass das Dienstkonto des Diensts, bei dem der Benutzer versucht, sich zu authentifizieren (im Falle des obigen Diagramms, das Anwendungspoolkonto des IIS-Anwendungspools, der die Webanwendung hostet) für nicht eingeschränkte Delegierung vertrauenswürdig ist.

Wenn diese Dienste eine nicht eingeschränkte Delegierung verwenden, enthalten die Tickets auf dem Clientcomputer die ok_as_delegate Kennzeichen und forwardable Kennzeichnungen. In den meisten Fällen, wenn eingeschränkte Delegierung konfiguriert ist, enthalten die Tickets nicht das ok_as_delegate Kennzeichen, sondern die forwardable Kennzeichnung.

Warum funktioniert die nicht eingeschränkte Delegierung in Internet Explorer und nicht in Microsoft Edge?

Wenn versucht wird, sich mit kerberosbasierter Authentifizierung bei einer Website zu authentifizieren, ruft der Browser eine Windows-API auf, um den Authentifizierungskontext einzurichten. Die betreffende API lautet InitializeSecurityContext. Diese API erhält möglicherweise eine Reihe von Flags, um anzugeben, ob der Browser das delegatable Ticket zulässt, das der Benutzer erhalten hat. Das Ticket ist als delegatable gekennzeichnet, da der Dienst, den der Benutzer authentifiziert, das Recht hat, Anmeldeinformationen auf nicht eingeschränkte Weise zu delegieren. Das bedeutet jedoch nicht, dass die Anwendung, die versucht, sich zu authentifizieren (in diesem Fall der Browser), diese Kapazität verwenden sollte.

Standardmäßig übergibt Internet Explorer das Flag an InitializeSecurityContext, das angibt, dass, wenn das Ticket delegiert werden kann, dann sollte es sein. Microsoft Edge von Version 87 und höher übergibt die Kennzeichnung InitializeSecurityContext nicht nur, weil das Ticket mit der ok_as_delegate Kennzeichnung gekennzeichnet ist. Es wird nicht empfohlen, die nicht eingeschränkte Delegierung in Anwendungen zu verwenden, da anwendungen mehr Berechtigungen als erforderlich erhalten. Anwendungen könnten die Identität des Benutzers an einen anderen Dienst in der Domäne delegieren und sich als Benutzer authentifizieren, was für die meisten Anwendungen mit der Delegierung von Anmeldeinformationen nicht erforderlich ist. Anwendungen sollten nur die Dienste in der Liste kontaktieren, die beim Einrichten der eingeschränkten Delegierung angegeben wurden.

Standardmäßig funktioniert Microsoft Edge mit eingeschränkter Delegierung, wobei die IIS-Website, die auf Webserver ausgeführt wird, nur das Recht hat, die Back-End-API-Website zu kontaktieren, die auf API-Server gehostet wird, wie in der Konfiguration des Anwendungspoolidentitätskontos aus Active Directory unten dargestellt:

Screenshot der Konfiguration des Anwendungspoolidentitätskontos.

Aktivieren von Edge-Chromium für die Arbeit mit nicht eingeschränkter Delegierung in Active Directory

Wenn Sie aus Kompatibilitätsgründen eine Anwendung mit nicht eingeschränkter Delegierung über Kerberos verwalten müssen, aktivieren Sie Microsoft Edge, um die Stellvertretung von Tickets zuzulassen. Die folgenden Schritte sind in den folgenden Abschnitten dieses Artikels beschrieben:

  1. Installieren Sie die administrativen Vorlagen für den zentralen Gruppenrichtlinienspeicher in Active Directory (sofern noch nicht vorhanden).
  2. Installieren Sie die administrativen Vorlagen von Microsoft Edge.
  3. Erstellen Sie ein neues Gruppenrichtlinienobjekt.
  4. Bearbeiten Sie die Konfiguration der Gruppenrichtlinie, um die nicht eingeschränkte Delegierung beim Authentifizieren auf Servern zuzulassen.
  5. (Optional) Überprüfen Sie, ob Microsoft Edge die richtigen Delegierungskennzeichnungen verwendet.

Schritt 1: Installieren der administrativen Vorlagen für Active Directory

  1. Laden Sie die Vorlagen aus administrativen Vorlagen (ADMX) (für Windows Server 2019) herunter.

  2. Laden Sie das Installationsprogramm herunter, und extrahieren Sie den Inhalt in einen Ordner Ihrer Wahl. Sie können es einfach in den angegebenen Standardspeicherort des Pakets extrahieren, d. h . C:\Programme (x86)\Microsoft-Gruppenrichtlinie\Windows 10 Oktober 2018 Update (1809) v2\PolicyDefinitions.

  3. Nachdem das Paket entzippt wurde, suchen Sie den Sysvol-Ordner auf Dem Domänencontroller. Der Pfad zum Ordner lautet "C:\Windows\SYSVOL\sysvol\". Innerhalb des Sysvol-Ordners ist ein Ordner mit demselben Namen wie Ihr Active Directory-Name (im Beispiel hier oddessy.local). Navigieren Sie von dort zum Ordner "Richtlinien ". Wenn sie nicht vorhanden ist, erstellen Sie einen Ordner namens "Richtliniendefinitionen ", wie unten dargestellt:

    Screenshot des Ordners

  4. Kopieren Sie den Inhalt des Ordners "PolicyDefinitions " (der aus dem Installationsprogramm in den Ordner "PolicyDefinitions " extrahiert wurde), den Sie in Ihrer Domäne im Ordner "sysvol " auf dem Domänencontroller erstellt haben.

    Notiz

    Die dateien, die vom Installationsprogramm extrahiert wurden, enthalten auch lokalisierten Inhalt. Um Speicherplatz zu sparen, übertragen Sie die lokalisierten Dateien nur für die gewünschten Sprachen. Der Ordner "fr-FR" enthält beispielsweise alle lokalisierten Inhalte in Französisch.

  5. Überprüfen Sie nach Abschluss der Übertragung, ob die Vorlagen in Active Directory verfügbar sind. Öffnen Sie dazu das Gruppenrichtlinienverwaltungs-Snap-In der Microsoft Management Console (drücken Sie Windows+R, und geben Sie dann "gpmc.msc " ein, um den Start zu starten). Suchen Sie innerhalb der Gruppenrichtlinienverwaltung nach einem Gruppenrichtlinienobjekt, und bearbeiten Sie es.

    Screenshot des Gruppenrichtlinienobjekts im Gruppenrichtlinienverwaltungs-Editor.

    Wie im obigen Screenshot unter dem Knoten "Computerkonfiguration " gezeigt, handelt es sich um einen Knoten "Richtlinien " und "Administrative Vorlagen ".

Schritt 2: Installieren der administrativen Microsoft Edge-Vorlagen

Obwohl Sie möglicherweise über die administrativen Richtlinienvorlagen auf dem Domänencontroller beginnen müssen, müssen Sie weiterhin die Microsoft Edge-Richtliniendateien installieren, um Zugriff auf die Richtlinie zu haben, die für die Aktivierung der delegierten Delegierung mit doppeltem Hop über diesen Browser vorgesehen ist. Führen Sie die Schritte aus, um die Microsoft Edge-Richtliniendateien zu installieren:

  1. Wechseln Sie zur Microsoft Edge for Business-Downloadwebsite.

  2. Wählen Sie die Version aus, die Sie aus der Dropdownliste "Kanal/Version " herunterladen möchten. Die neueste stabile Version wird empfohlen.

  3. Wählen Sie den gewünschten Build aus der Builddropdownliste und schließlich das Zielbetriebssystem aus der Plattformdropdownliste aus. Sobald die Auswahl getroffen wurde, werden zwei weitere Schaltflächen (eine Schaltfläche und ein Link) angezeigt.

    Screenshot der Seite

  4. Klicken Sie auf "RICHTLINIENDATEIEN ABRUFEN", und akzeptieren Sie den Lizenzvertrag, um die Datei mit dem Namen MicrosoftEdgePolicyTemplates.cab herunterzuladen. Diese Datei enthält die Richtliniendefinitionsdateien für Microsoft Edge.

  5. Doppelklicken Sie auf die Datei, um den Inhalt zu durchsuchen (ein ZIP-Archiv mit demselben Namen).

  6. Extrahieren Sie den Inhalt des ZIP-Archivs in einen Ordner auf dem lokalen Datenträger. Der extrahierte Inhalt enthält einen Ordner namens Windows , in dem Sie einen Unterordner namens Admx finden. Dies enthält die administrativen Vorlagen sowie ihre lokalisierten Versionen (Sie sollten sie in einer anderen Sprache als Englisch benötigen).

    Screenshot des Admx-Ordners.

  7. Übertragen Sie die ADMX-Dateien innerhalb desselben Ordners unter dem Sysvol-Verzeichnis, in den die administrativen Vorlagen aus dem vorherigen Verzeichnis übertragen wurden (im obigen Beispiel: C:\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions).

  8. Öffnen Sie den Active Directory-Gruppenrichtlinien-Editor, und wählen Sie ein vorhandenes Gruppenrichtlinienobjekt zum Bearbeiten aus, um das Vorhandensein der neu übertragenen Microsoft Edge-Vorlagen zu überprüfen. Diese befinden sich in einem Ordner namens Microsoft Edge , der sich unter dem Ordner "Administrative Vorlagen " in der Strukturansicht befindet:

    Screenshot des Microsoft Edge-Elements im Gruppenrichtlinienverwaltungs-Editor.

Schritt 3: Erstellen eines neuen Gruppenrichtlinienobjekts

Hier erfahren Sie, wie Sie mithilfe des MMC-Snap-Ins für Active Directory-Gruppenrichtlinien-Manager ein neues Gruppenrichtlinienobjekt erstellen:

  1. Drücken Sie die WINDOWS+R-TASTE, um das Menü "Ausführen " auf Dem Domänencontroller zu öffnen.
  2. Geben Sie "Gpmc.msc " ein, um die Microsoft Management Console zu öffnen und das Active Directory-Gruppenrichtlinien-Manager-Snap-In zu laden.
  3. Suchen Sie den Knoten "Gruppenrichtlinienobjekte " in der Strukturansicht der Konsole, und klicken Sie mit der rechten Maustaste auf den Knoten, um das Kontextmenü zu öffnen.
  4. Wählen Sie das Menüelement "Neu " aus, geben Sie den Namen der Gruppenrichtlinie ein, die Sie erstellen möchten, und klicken Sie dann auf "OK".

Screenshot des neuen Menüelements im Gruppenrichtlinienverwaltungs-Editor.

Schritt 4: Bearbeiten der Konfiguration der Gruppenrichtlinie, um die nicht eingeschränkte Delegierung beim Authentifizieren auf Servern zuzulassen

Der letzte Schritt besteht darin, die Richtlinie zu aktivieren, die es dem Microsoft Edge-Browser ermöglicht, das ok_as_delegate Flag an den InitializeSecurityContext API-Aufruf zu übergeben, wenn die Authentifizierung mithilfe von Kerberos für eine integrierte Windows-Website ausgeführt wird. Wenn Sie nicht wissen, ob Ihr Microsoft Edge-Browser Kerberos zur Authentifizierung verwendet (und nicht NTLM), lesen Sie die Problembehandlung von Kerberos-Fehlern in Internet Explorer.

Wählen Sie im Active Directory-Gruppenrichtlinien-Editor das Gruppenrichtlinienobjekt aus, das auf die Computer in Ihrem Active Directory angewendet wird, aus denen Sie Endbenutzern erlauben möchten, sich über die Kerberos-Authentifizierung zu authentifizieren und ihre Anmeldeinformationen an Back-End-Dienste über nicht eingeschränkte Delegierung delegiert zu lassen. Die Richtlinie, die die nicht eingeschränkte Delegierung von Microsoft Edge aktiviert, befindet sich unter dem Http-Authentifizierungsordner der Microsoft Edge-Vorlagen , wie unten dargestellt:

Screenshot des Ordners

Verwenden Sie diese Einstellung, um eine Liste der Server zu konfigurieren, für die die Delegierung von Kerberos-Tickets zulässig ist.

Notiz

Eine Liste der Server muss bereitgestellt werden. Im Beispiel, das am Anfang dieses Artikels verwendet wird, müssen Sie der Liste den Webservernamen hinzufügen, damit die Front-End-Webserver-Webanwendung Anmeldeinformationen an den Back-End-API-Server delegieren kann.

Screenshot einer Liste von Servern.

Nachdem das neu bearbeitete Gruppenrichtlinienobjekt auf die Clientcomputer innerhalb der Domäne angewendet wurde, wechseln Sie zur Seite "Testauthentifizierung" auf Diagnoseseiten für die Problembehandlung bei der integrierten Windows-Authentifizierung, und laden Sie die whoami.aspx-Seite aus dem Repository für ASP.net Beispiele auf GitHub herunter. Sie führt zu einer Identitätswechsellevel-Einstellung von "Delegate" anstelle des Identitätswechsels , der signalisiert, dass die Delegierung von Anmeldeinformationen jetzt zulässig ist.

Screenshot der Einstellungsseite

Um zu testen, ob die Richtlinie auf der Clientarbeitsstation ordnungsgemäß angewendet wurde, öffnen Sie eine neue Microsoft Edge-Registerkarte, und geben Sie edge://policy ein.

Screenshot edge://policy Seite.

Die AuthNegotiateDelegateAllowlist Richtlinie sollte so festgelegt werden, dass die Werte der Servernamen angegeben werden, für die Microsoft Edge die Delegierung von Kerberos-Tickets durchführen darf. Wenn die Richtlinie nicht in der Liste angezeigt wird, wurde sie nicht bereitgestellt oder auf den falschen Computern bereitgestellt.

Schritt 5 (Optional): Überprüfen, ob Microsoft Edge die richtigen Delegierungskennzeichnungen verwendet

Hier sehen Sie den Schritt zur Problembehandlung/optionalen Überprüfung.

Nachdem die Richtlinie konfiguriert und bereitgestellt wurde, müssen die folgenden Schritte ausgeführt werden, um zu überprüfen, ob Microsoft Edge die richtigen Delegierungskennzeichnungen IntializeSecurityContextangibt. Die Schritte verwenden Tools, die bereits in Microsoft Edge integriert sind oder als Onlinedienste verfügbar sind.

  1. Verwenden Sie das in Microsoft Edge verfügbare Protokollierungsfeature, um zu protokollieren, was der Browser beim Anfordern einer Website tut. Um die Protokollierung zu aktivieren:

    1. Öffnen Sie ein neues Microsoft Edge-Fenster, und geben Sie edge://net-export/ ein.

    2. Verwenden Sie die Option "Cookies und Anmeldeinformationen einschließen" bei der Ablaufverfolgung. Ohne diese Option werden Daten auf Ablaufverfolgungsebene der Authentifizierung weggelassen.

      Screenshot edge://net-export/ Seite.

    3. Klicken Sie auf die Schaltfläche "Protokollierung auf Datenträger starten", und geben Sie den Dateinamen an, unter dem Sie die Ablaufverfolgung speichern möchten.

    4. Öffnen Sie eine andere Microsoft Edge-Registerkarte, navigieren Sie zu der Website, für die Sie integrierte Windows-Authentifizierung mit Microsoft Edge ausführen möchten.

    5. Nachdem Sie versucht haben, sich zu authentifizieren, wechseln Sie zurück zur vorherigen Registerkarte, auf der die Ablaufverfolgung aktiviert wurde, und klicken Sie auf die Schaltfläche "Protokollierung beenden" . Die Ablaufverfolgungsschnittstelle gibt an, wo die Datei mit der Ablaufverfolgung geschrieben wurde.

  2. Verwenden Sie die JSON-Datei, die die Ablaufverfolgung enthält, um zu sehen, welche Parameter der Browser bei dem Versuch, sich zu authentifizieren, an die InitializeSecurityContext Funktion übergeben hat. Verwenden Sie die netlog_viewer, um die Ablaufverfolgung zu analysieren.

  3. Innerhalb der analysierten Ablaufverfolgung handelt es sich um ein Ereignisprotokoll, das wie folgt aussieht:

    t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                      --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                      --> spn = "HTTP/web-server.odessy.local"

    Dieses Protokoll zeigt Folgendes:

    • AUTH_LIBRARY_INIT_SEC_CTX bedeutet, dass der Browser die InitializeSecurityContext Funktion aufruft.
    • "delegated":false bedeutet, dass das Ticket nicht delegiert werden sollte, auch wenn das Ticket als delegatablegekennzeichnet ist.
    • "mutual":false bedeutet, dass der Client (Browser) nicht erfordert, dass sich der Server auch beim Client authentifizieren und seine Identität nachweisen muss. Nur der Client sollte sich beim Server authentifizieren, um seine Identität zu beweisen.
    • HTTP/web-server.odessy.local ist der SPN, der vom Browser beim Authentifizierungsaufruf verwendet wird.

Weitere Informationen

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