Freigeben über

Behandeln von Kerberos-Fehlern in Internet Explorer

Dieser Artikel hilft Ihnen, die Ursachen verschiedener Fehler zu isolieren und zu beheben, wenn Sie auf Websites zugreifen, die für die Verwendung der Kerberos-Authentifizierung in Internet Explorer konfiguriert sind. Die Anzahl potenzieller Probleme ist fast so groß wie die Anzahl der Tools, die zur Lösung verfügbar sind.

Häufiges Symptom, wenn Kerberos fehlschlägt

Sie versuchen, auf eine Website zuzugreifen, auf der Windows Integrated Authenticated konfiguriert wurde und Sie erwarten, dass Sie das Kerberos-Authentifizierungsprotokoll verwenden. In diesem Fall fordert Ihr Browser Sie sofort zur Eingabe von Anmeldeinformationen auf:

Screenshot der Aufforderung zur Eingabe von Anmeldeinformationen.

Obwohl Sie einen gültigen Benutzernamen und ein gültiges Kennwort eingeben, werden Sie erneut aufgefordert (insgesamt drei Eingabeaufforderungen). Anschließend wird ein Bildschirm angezeigt, der angibt, dass Sie nicht auf die gewünschte Ressource zugreifen dürfen. Auf dem Bildschirm wird ein HTTP 401-Statuscode angezeigt, der dem folgenden Fehler ähnelt:

Nicht autorisiert
HTTP-Fehler 401. Für die angeforderte Ressource ist eine Benutzerauthentifizierung erforderlich.

Screenshot des H T T P-Fehlers 401.

Auf dem Microsoft-Internetinformationsdienste(IIS)-Server enthalten die Websiteprotokolle Anforderungen, die in einem Statuscode 401.2 enden, z. B. das folgende Protokoll:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

Oder auf dem Bildschirm wird ein Statuscode 401.1 angezeigt, z. B. das folgende Protokoll:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Ermitteln, ob Kerberos verwendet wird

Bei der Behandlung von Kerberos-Authentifizierungsfehlern wird empfohlen, die Konfiguration auf ein Minimum zu vereinfachen. Das heißt, ein Client, ein Server und eine IIS-Website, die auf dem Standardport ausgeführt wird. Darüber hinaus können Sie einige grundlegende Schritte zur Problembehandlung ausführen. Verwenden Sie beispielsweise eine Testseite, um die verwendete Authentifizierungsmethode zu überprüfen. Wenn Sie ASP.NET verwenden, können Sie diese ASP.NET Authentifizierungstestseite erstellen.

Wenn Sie klassische ASP verwenden, können Sie die folgende Testkerb.asp Seite verwenden:

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

Sie können auch die folgenden Tools verwenden, um zu bestimmen, ob Kerberos verwendet wird:

  • Fiddler
  • HttpWatch
  • Netzwerkmonitor
  • Die Entwicklertools in Ihrem Browser

Weitere Informationen dazu, wie solche Ablaufverfolgungen generiert werden können, finden Sie unter clientseitige Ablaufverfolgung.

Wenn Kerberos verwendet wird, ist die vom Client gesendete Anforderung groß (mehr als 2.000 Byte), da der HTTP_AUTHORIZATION Header das Kerberos-Ticket enthält. Die folgende Anforderung ist für eine Seite vorgesehen, auf der die Kerberos-basierte Windows-Authentifizierung zum Authentifizieren eingehender Benutzer verwendet wird. Die Größe der GET-Anforderung beträgt mehr als 4.000 Bytes.

Screenshot von Anforderungen, die mehr als 4.000 Bytes sind.

Wenn der NTLM-Handshake verwendet wird, ist die Anforderung viel kleiner. Die folgende clientseitige Erfassung zeigt eine NTLM-Authentifizierungsanforderung. Die GET-Anforderung ist wesentlich kleiner (weniger als 1.400 Bytes).

Screenshot von Anforderungen, die kleiner als 1.400 Bytes sind.

Nachdem Sie festgestellt haben, dass die Kerberos-Authentifizierung fehlschlägt, überprüfen Sie jedes der folgenden Elemente in der angegebenen Reihenfolge.

Was zu überprüfen ist, ob die Kerberos-Authentifizierung fehlschlägt

In den folgenden Abschnitten werden die Punkte beschrieben, mit denen Sie überprüfen können, ob die Kerberos-Authentifizierung fehlschlägt.

Sind der Client und der Server in derselben Domäne

Die Verwendung von Kerberos erfordert eine Domäne, da ein Kerberos-Ticket vom Domänencontroller (DC) bereitgestellt wird. Erweiterte Szenarien sind auch möglich, wenn:

  • Der Client und der Server befinden sich nicht in derselben Domäne, sondern in zwei Domänen derselben Gesamtstruktur.
  • Der Client und der Server befinden sich in zwei verschiedenen Gesamtstrukturen.

Diese möglichen Szenarien werden unter " Warum schlägt die Kerberos-Delegierung zwischen meinen beiden Gesamtstrukturen fehl, obwohl sie für die Arbeit in diesem Artikel verwendet wurde.

Ist IIS für die Verwendung der integrierten Authentifizierung konfiguriert

Screenshot der Einstellung für die Windows-Authentifizierung.

In Internet Explorer aktivierte integrierte Authentifizierung

Wählen Sie auf der Seite

Gibt an, welche URL in eine Sicherheitszone aufgelöst wird, für die Anmeldeinformationen gesendet werden können.

Führen Sie diese Überprüfung immer für die folgenden Websites aus:

  • Websites, die mit der Zone "Lokales Intranet" des Browsers übereinstimmen.
  • Websites in der Zone "Vertrauenswürdige Sites".

Sie können überprüfen, in welcher Zone Sich Ihr Browser entscheidet, die Website einzuschließen. Öffnen Sie dazu das Menü "Datei" von Internet Explorer, und wählen Sie dann "Eigenschaften" aus. Im Fenster "Eigenschaften " wird die Zone angezeigt, in der sich der Browser entschieden hat, die Website einzuschließen, zu der Sie navigieren.

Überprüfen Sie die Zone in den Eigenschaften von Internet Explorer.

Sie können überprüfen, ob die Zone, in der die Website enthalten ist, die automatische Anmeldung zulässt. Öffnen Sie dazu das Internetoptionenmenü von Internet Explorer, und wählen Sie die Registerkarte "Sicherheit " aus. Nachdem Sie die gewünschte Zone ausgewählt haben, wählen Sie die Schaltfläche "Benutzerdefinierte Ebene " aus, um die Einstellungen anzuzeigen, und stellen Sie sicher, dass die automatische Anmeldung ausgewählt ist. (In der Regel ist dieses Feature für die Zonen "Intranet" und "Vertrauenswürdige Sites" standardmäßig aktiviert.

Überprüfen Sie, ob die automatische Anmeldung aktiviert ist.

Notiz

Auch wenn diese Konfiguration nicht üblich ist (da der Client Zugriff auf einen DC hat), kann Kerberos für eine URL in der Internetzone verwendet werden. In diesem Fall fordert der Browser den Benutzer immer zur Eingabe von Anmeldeinformationen auf, es sei denn, die Standardeinstellungen werden geändert. Die Kerberos-Delegierung funktioniert in der Internetzone nicht. Dies liegt daran, dass Internet Explorer die Kerberos-Delegierung nur für eine URL in den Zonen "Intranet" und "Vertrauenswürdige Sites" zulässt.

Ist der IIS-Server so konfiguriert, dass der WWW-Authenticate:Negotiate-Header gesendet wird

Überprüfen Sie, ob der IIS-Server so konfiguriert ist, dass der WWW-Authenticate: Negotiate-Header gesendet wird.

Wenn IIS diesen Header nicht sendet, verwenden Sie die IIS-Manager-Konsole, um den Negotiate-Header über die NTAuthenticationProviders-Konfigurationseigenschaft festzulegen. Weitere Informationen finden Sie unter Anbieter von Windows-Authentifizierungsanbietern><. Sie können über die Anbietereinstellung der Windows-Authentifizierungsdetails im IIS-Manager auf die Konsole zugreifen.

Anbietereinstellungen in der Authentifizierung.

Notiz

Standardmäßig ist die NTAuthenticationProviders-Eigenschaft nicht festgelegt. Dies bewirkt, dass IIS sowohl Aushandeln als auch Windows NT LAN Manager (NTLM)-Header sendet.

Sind der Client und der Server auf demselben Computer installiert

Standardmäßig ist Kerberos in dieser Konfiguration nicht aktiviert. Um dieses Verhalten zu ändern, müssen Sie den DisableLoopBackCheck Registrierungsschlüssel festlegen. Weitere Informationen finden Sie unter KB 926642.

Kann der Client ein Kerberos-Ticket erhalten

Sie können das Tool Kerberos-Liste (KLIST) verwenden, um zu überprüfen, ob der Clientcomputer ein Kerberos-Ticket für einen bestimmten Dienstprinzipalnamen abrufen kann. In diesem Beispiel ist der Dienstprinzipalname (SPN) http/web-server.

Notiz

KLIST ist ein systemeigenes Windows-Tool seit Windows Server 2008 für serverseitige Betriebssysteme und Windows 7 Service Pack 1 für clientseitige Betriebssysteme.

Verwenden Sie das KLIST-Tool, um zu überprüfen, ob der Clientcomputer ein Kerberos-Ticket für einen bestimmten Dienstprinzipalnamen abrufen kann.

Wenn die Kerberos-Ticketanforderung fehlschlägt, wird die Kerberos-Authentifizierung nicht verwendet. NTLM-Fallback kann auftreten, da der angeforderte SPN für den DC unbekannt ist. Wenn der DC nicht erreichbar ist, tritt kein NTLM-Fallback auf.

Informationen zum Deklarieren eines SPN finden Sie im folgenden Artikel:

Verwenden von SPNs beim Konfigurieren von Webanwendungen, die auf Internetinformationsdienste gehostet werden.

Verwendet der Webserver einen anderen Port als standard (80)

Internet Explorer enthält standardmäßig nicht die Portnummerninformationen im SPN, die zum Anfordern eines Kerberos-Tickets verwendet werden. Es kann ein Problem sein, wenn Sie IIS verwenden, um mehrere Websites unter verschiedenen Ports und Identitäten zu hosten. In dieser Konfiguration kann die Kerberos-Authentifizierung nur für bestimmte Standorte funktionieren, auch wenn alle SPNs in Active Directory ordnungsgemäß deklariert wurden. Um dieses Problem zu beheben, müssen Sie den FEATURE_INCLUDE_PORT_IN_SPN_KB908209 Registrierungswert festlegen. (Siehe Abschnitt mit Internet Explorer-Featureschlüsseln für Informationen zum Deklarieren des Schlüssels.) Diese Einstellung zwingt Internet Explorer, die Portnummer in den SPN einzuschließen, der zum Anfordern des Kerberos-Tickets verwendet wird.

Verwendet Internet Explorer den erwarteten SPN.

Wenn auf eine Website mithilfe eines Aliasnamens (CNAME) zugegriffen wird, verwendet Internet Explorer zunächst die DNS-Auflösung, um den Aliasnamen in einen Computernamen (ANAME) aufzulösen. Der Computername wird dann verwendet, um den SPN zu erstellen und ein Kerberos-Ticket anzufordern. Selbst wenn die in der Adressleiste von Internet Explorer eingegebene URL lautet http://MYWEBSITE, fordert Internet Explorer einen SPN für HTTP/MYSERVER an, wenn MYWEBSITE ein Alias (CNAME) von MYSERVER (ANAME) ist. Sie können dieses Verhalten mithilfe des FEATURE_USE_CNAME_FOR_SPN_KB911149 Registrierungsschlüssels ändern. (Siehe Internet Explorer-Featureschlüssel für Informationen zum Deklarieren des Schlüssels.)

Eine Netzwerküberwachungsablaufverfolgung ist eine gute Methode, um den SPN zu überprüfen, der dem Kerberos-Ticket zugeordnet ist, wie im folgenden Beispiel gezeigt:

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

Entspricht die Anwendungspoolidentität dem Konto, das SPN zugeordnet ist.

Wenn ein Kerberos-Ticket von Internet Explorer an einen IIS-Server gesendet wird, wird das Ticket mit einem privaten Schlüssel verschlüsselt. Der private Schlüssel ist ein Hash des Kennworts, das für das Benutzerkonto verwendet wird, das dem SPN zugeordnet ist. Daher kann nur eine Anwendung, die unter diesem Konto ausgeführt wird, das Ticket decodieren.

Das folgende Verfahren ist eine Zusammenfassung des Kerberos-Authentifizierungsalgorithmus:

  1. Internet Explorer bestimmt einen SPN mithilfe der URL, die in die Adressleiste eingegeben wird.

  2. Der SPN wird über eine SSPI-API (Security Support Provider Interface) (InitializeSecurityContext) an die Systemkomponente übergeben, die für die Windows-Sicherheit zuständig ist (der LSASS-Prozess (Local Security Authority Subsystem Service). In dieser Phase können Sie sehen, dass der Internet Explorer-Code keinen Code zum Erstellen des Kerberos-Tickets implementiert. Internet Explorer ruft nur SSPI-APIs auf.

  3. LSASS verwendet den SPN, der übergeben wird, um ein Kerberos-Ticket an einen DC anzufordern. Wenn der DC die Anforderung (bekanntes SPN) bedienen kann, wird ein Kerberos-Ticket erstellt. Anschließend verschlüsselt es das Ticket mithilfe eines Schlüssels, der aus dem Hash des Benutzerkontokennworts für das Konto erstellt wird, das dem SPN zugeordnet ist. LSASS sendet dann das Ticket an den Client. Was Internet Explorer betrifft, ist das Ticket ein undurchsichtiges Blob.

  4. Internet Explorer kapselt das Kerberos-Ticket, das von LSASS im Authorization: Negotiate Header bereitgestellt wird, und sendet dann das Ticket an den IIS-Server.

  5. IIS verarbeitet die Anforderung und leitet sie mithilfe des angegebenen Hostheaders an den richtigen Anwendungspool weiter.

  6. Der Anwendungspool versucht, das Ticket mithilfe von SSPI/LSASS-APIs zu entschlüsseln und die folgenden Bedingungen zu erfüllen:

    • Wenn das Ticket entschlüsselt werden kann, ist die Kerberos-Authentifizierung erfolgreich. Alle Dienste, die dem Ticket zugeordnet sind (Identitätswechsel, Delegierung, wenn ticket erlaubt usw.) sind verfügbar.

    • Wenn das Ticket nicht entschlüsselt werden kann, wird ein Kerberos-Fehler (KRB_AP_ERR_MODIFIED) zurückgegeben. Dieser Fehler ist ein allgemeiner Fehler, der darauf hinweist, dass das Ticket während des Transports in irgendeiner Weise geändert wurde. Das Ticket kann also nicht entschlüsselt werden. Dieser Fehler wird auch in den Windows-Ereignisprotokollen protokolliert.

Wenn Sie einen SPN nicht explizit deklarieren, funktioniert die Kerberos-Authentifizierung nur unter einer der folgenden Anwendungspoolidentitäten:

  • Netzwerkdienst
  • ApplicationPoolIdentity
  • Ein anderes Systemkonto, z. B. LOCALSYSTEM oder LOCALSERVICE

Diese Identitäten werden jedoch nicht empfohlen, da sie ein Sicherheitsrisiko darstellen. In diesem Fall wird das Kerberos-Ticket mithilfe eines Standard-SPN erstellt, der in Active Directory erstellt wird, wenn ein Computer (in diesem Fall der Server, auf dem IIS ausgeführt wird) der Domäne hinzugefügt wird. Dieser Standard-SPN ist dem Computerkonto zugeordnet. Unter IIS ist das Computerkonto dem Netzwerkdienst oder ApplicationPoolIdentity zugeordnet.

Wenn Ihr Anwendungspool eine andere Identität als die aufgeführten Identitäten verwenden muss, deklarieren Sie einen SPN (mit SETSPN). Ordnen Sie es dann dem Konto zu, das für Ihre Anwendungspoolidentität verwendet wird. Ein häufiger Fehler besteht darin, ähnliche SPNs mit unterschiedlichen Konten zu erstellen. Zum Beispiel:

  • SETSPN http/mywebsite UserAppPool1
  • SETSPN http/mywebsite UserAppPool2

Diese Konfiguration funktioniert nicht, da es keine deterministische Möglichkeit gibt, zu wissen, ob das Kerberos-Ticket für http/mywebsite SPN mit dem Kennwort "UserAppPool1" oder "UserAppPool2" verschlüsselt wird. Diese Konfiguration generiert in der Regel KRB_AP_ERR_MODIFIED Fehler. Verwenden Sie die im folgenden Artikel dokumentierten Tools, um zu ermitteln, ob Sie sich in diesem szenario mit ungültigen duplizierten SPNs befinden:

Warum Sie weiterhin doppelte SPNs in AD 2012 R2 und AD 2016 haben können

Ab Windows Server 2008 können Sie auch eine aktualisierte Version von SETSPN für Windows verwenden, die die Erkennung doppelter SPNs mithilfe des setspn –X Befehls ermöglicht, wenn Sie einen neuen SPN für Ihr Zielkonto deklarieren. Weitere Informationen finden Sie unter Setspn.

Es wird auch empfohlen, die folgenden Artikel zu überprüfen:

Schlägt die Kerberos-Authentifizierung in IIS 7 und höheren Versionen fehl, obwohl sie in IIS 6 funktioniert

Die Kernelmodusauthentifizierung ist ein Feature, das in IIS 7 eingeführt wurde. Sie bietet folgende Vorteile:

  • Die Leistung wird erhöht, da Kernelmodus-zu-Benutzer-Modus-Übergänge nicht mehr vorgenommen werden.
  • Die Kerberos-Ticketdecodierung erfolgt mithilfe des Computerkontos, nicht der Anwendungspoolidentität. Mit dieser Änderung können Sie über mehrere Anwendungspools verfügen, die unter verschiedenen Identitäten ausgeführt werden, ohne SPNs deklarieren zu müssen.

Warnung

Wenn ein SPN für ein bestimmtes Benutzerkonto deklariert wurde (auch als Anwendungspoolidentität verwendet), kann die Kernelmodusauthentifizierung das Kerberos-Ticket nicht entschlüsseln, da es das Computerkonto verwendet. Dieses Problem ist typisch für Webfarmszenarien. In diesem Szenario wird in der Regel ein SPN für den (virtuellen) NLB-Hostname deklariert. Verwenden Sie eine der folgenden Methoden, um dieses Problem zu verhindern:

  • Deaktivieren Sie die Kernelmodusauthentifizierung. (Aus Leistungsgründen nicht empfohlen.)
  • Legen Sie "useAppPoolCredentials" auf "true" fest. Dadurch bleibt der Leistungsvorteil der Kernelmodusauthentifizierung erhalten, während das Kerberos-Ticket unter der Anwendungspoolidentität decodiert werden kann. Weitere Informationen finden Sie unter Sicherheitsauthentifizierung><.

Warum schlägt die Delegierung fehl, obwohl die Kerberos-Authentifizierung funktioniert

Überprüfen Sie in diesem Szenario die folgenden Elemente:

  • Die Internet Explorer-Zone, die für die URL verwendet wird. Kerberos-Delegierung ist nur für die Zonen "Intranet" und "Vertrauenswürdige Sites" zulässig. (Mit anderen Worten, Internet Explorer legt das ISC_REQ_DELEGATE Flag fest, wenn es InitializeSecurityContext aufruft, nur wenn die zone, die bestimmt wird, intranet oder vertrauenswürdige Websites ist.)

  • Das Benutzerkonto für den IIS-Anwendungspool, der Ihren Standort hostet, muss das Flag "Vertrauenswürdig für Delegierung " in Active Directory aufweisen.

Wenn die Delegierung immer noch fehlschlägt, sollten Sie den Kerberos Configuration Manager für IIS verwenden. Mit diesem Tool können Sie IIS-Konfigurationen für die Kerberos-Authentifizierung und die zugehörigen SPNs für die Zielkonten diagnostizieren und beheben. Weitere Informationen finden Sie im README.md. Sie können das Tool hier herunterladen.

Warum erhalte ich eine schlechte Leistung, wenn ich die Kerberos-Authentifizierung verwende

Kerberos ist ein anforderungsbasiertes Authentifizierungsprotokoll in älteren Versionen von Windows Server, z. B. Windows Server 2008 SP2 und Windows Server 2008 R2. Dies bedeutet, dass der Client das Kerberos-Ticket (das kann ziemlich ein großes BLOB sein) mit jeder Anforderung senden muss, die an den Server gesendet wird. Es ist im Gegensatz zu Authentifizierungsmethoden, die auf NTLM basieren. NTLM ist standardmäßig sitzungsbasiert. Dies bedeutet, dass der Browser nur eine Anforderung authentifiziert, wenn die TCP-Verbindung mit dem Server geöffnet wird. Jede nachfolgende Anforderung für dieselbe TCP-Verbindung erfordert keine Authentifizierung mehr, damit die Anforderung akzeptiert wird. In neueren Versionen von IIS ab Windows 2012 R2 ist Kerberos auch sitzungsbasiert. Nur die erste Anforderung für eine neue TCP-Verbindung muss vom Server authentifiziert werden. Nachfolgende Anforderungen müssen kein Kerberos-Ticket enthalten.

Sie können dieses Verhalten ändern, indem Sie die authPersistNonNTLM-Eigenschaft verwenden, wenn Sie unter IIS 7 und höher ausgeführt werden. Wenn die Eigenschaft auf "true" festgelegt ist, wird Kerberos sitzungsbasiert. Andernfalls wird sie anforderungsbasiert. Es wird eine schlechtere Leistung haben, da wir jedes Mal eine größere Menge an Daten einschließen müssen, die an den Server gesendet werden. Weitere Informationen finden Sie unter "Anforderungsbasierter" im Vergleich zur sitzungsbasierten Kerberos-Authentifizierung (oder dem Parameter "AuthPersistNonNTLM").

Notiz

Möglicherweise ist es nicht sinnvoll, die Kerberos-Authentifizierung blind für alle Objekte zu verwenden. Die Verwendung der Kerberos-Authentifizierung zum Abrufen von Hunderten von Bildern mithilfe von bedingten GET-Anforderungen, die wahrscheinlich 304 nicht geänderte Antworten generieren, ist wie der Versuch, einen Fly mit einem Hammer zu beenden. Eine solche Methode wird auch keine offensichtlichen Sicherheitsgewinne bieten.

Warum schlägt die Kerberos-Delegierung zwischen meinen beiden Gesamtstrukturen fehl, obwohl sie für die Arbeit verwendet wurde

Nehmen Sie das folgende Szenario als Beispiel:

  • Die Benutzer Ihrer Anwendung befinden sich in einer Domäne innerhalb der Gesamtstruktur A.
  • Ihre Anwendung befindet sich in einer Domäne innerhalb der Gesamtstruktur B.
  • Sie haben eine Vertrauensstellung zwischen den Gesamtstrukturen.

In diesem Szenario funktioniert die Kerberos-Delegierung möglicherweise nicht mehr, obwohl sie zuvor funktionierte und Sie keine Änderungen an Gesamtstrukturen oder Domänen vorgenommen haben. Die Kerberos-Authentifizierung funktioniert in diesem Szenario weiterhin. Nur die Delegierung schlägt fehl.

Dieses Problem kann aufgrund von Sicherheitsupdates für Windows Server auftreten, die von Microsoft im März 2019 und Juli 2019 veröffentlicht wurden. Diese Updates deaktivierten nicht eingeschränkte Kerberos-Delegierung (die Möglichkeit, ein Kerberos-Token von einer Anwendung an einen Back-End-Dienst zu delegieren) über Gesamtstrukturgrenzen hinweg für alle neuen und vorhandenen Vertrauensstellungen. Weitere Informationen finden Sie unter Updates für die TGT-Delegierung über eingehende Vertrauensstellungen in Windows Server.

Internet Explorer-Featureschlüssel

Bei diesen Schlüsseln handelt es sich um Registrierungsschlüssel, mit denen einige Features des Browsers aktiviert oder deaktiviert werden. Die Schlüssel befinden sich an den folgenden Registrierungsspeicherorten:

  • HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – wenn auf Benutzerebene definiert
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - wenn auf Computerebene definiert

Featureschlüssel sollten an einem dieser Speicherorte erstellt werden, je nachdem, ob Sie das Feature aktivieren oder deaktivieren möchten:

  • für alle Benutzer auf dem Computer
  • nur für ein bestimmtes Konto

Diese Schlüssel sollten unter dem jeweiligen Pfad erstellt werden. Innerhalb des Schlüssels sollte ein DWORD-Wert deklariert werden, der benannt iexplorer.exe wird. Der Standardwert der einzelnen Schlüssel sollte je nach gewünschter Einstellung des Features " true " oder "false" lauten. Standardmäßig ist der Wert beider Featureschlüssel FEATURE_INCLUDE_PORT_IN_SPN_KB908209 und FEATURE_USE_CNAME_FOR_SPN_KB911149"false". Zur Vollständigkeit finden Sie hier ein Beispiel für den Export der Registrierung, indem Sie den Featureschlüssel so ändern, dass portnummern in das Kerberos-Ticket aufgenommen werden:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Weitere Informationen

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