Behandeln von Kerberos-Fehlern in Internet Explorer

Dieser Artikel hilft Ihnen, die Ursachen verschiedener Fehler beim Zugriff auf Websites zu isolieren und zu beheben, die für die Verwendung der Kerberos-Authentifizierung in Internet Explorer konfiguriert sind. Die Anzahl der potenziellen Probleme ist fast so groß wie die Anzahl der Tools, die zu ihrer Lösung zur Verfügung stehen.

Häufiges Symptom, wenn Kerberos fehlschlägt

Sie versuchen, auf eine Website zuzugreifen, auf der die integrierte Windows-Authentifizierung konfiguriert wurde und Sie erwarten, dass sie das Kerberos-Authentifizierungsprotokoll verwenden. In diesem Fall werden Sie von Ihrem Browser sofort wie folgt zur Eingabe von Anmeldeinformationen aufgefordert:

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-status Code angezeigt, der dem folgenden Fehler ähnelt:

Nicht autorisiert
HTTP-Fehler 401. Die angeforderte Ressource erfordert eine Benutzerauthentifizierung.

Auf dem Microsoft-Internetinformationsdienste -Server (IIS) enthalten die Websiteprotokolle Anforderungen, die mit einem 401.2-status-Code 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 der Bildschirm zeigt einen 401.1 status Code an, 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

Bestimmen, ob Kerberos verwendet wird

Bei der Behandlung von Kerberos-Authentifizierungsfehlern wird empfohlen, die Konfiguration auf ein Minimum zu vereinfachen. Das sind ein Client, ein Server und ein IIS-Standort, der 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 Bytes), da der HTTP_AUTHORIZATION Header das Kerberos-Ticket enthält. Die folgende Anforderung bezieht sich auf eine Seite, die die Kerberos-basierte Windows-Authentifizierung verwendet, um eingehende Benutzer zu authentifizieren. Die Größe der GET-Anforderung beträgt mehr als 4.000 Bytes.

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

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

Zu überprüfende Punkte, wenn die Kerberos-Authentifizierung fehlschlägt

In den folgenden Abschnitten werden die Dinge beschrieben, die Sie verwenden können, um zu überprüfen, ob die Kerberos-Authentifizierung fehlschlägt.

Befinden sich 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) übermittelt wird. Erweiterte Szenarien sind auch in folgenden Fällen möglich:

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

Diese möglichen Szenarien werden im Abschnitt Warum schlägt die Kerberos-Delegierung zwischen meinen beiden Gesamtstrukturen fehl, obwohl sie früher funktionierte in diesem Artikel.

Ist IIS für die Verwendung der integrierten Authentifizierung konfiguriert?

Ist die integrierte Authentifizierung in Internet Explorer aktiviert

Wird die verwendete URL in eine Sicherheitszone aufgelöst, 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 abgeglichen werden.
• Websites in der Zone Vertrauenswürdige Sites.

Sie können überprüfen, in welcher Zone Ihr Browser die Website einschließt. Öffnen Sie hierzu das Menü Datei von Internet Explorer, und wählen Sie dann Eigenschaften aus. Im Fenster Eigenschaften wird die Zone angezeigt, in der der Browser die Website, zu der Sie navigieren, eingeschlossen hat.

Sie können überprüfen, ob die Zone, in der die Website enthalten ist, die automatische Anmeldung zulässt. Öffnen Sie dazu das Menü Internetoptionen 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 Automatische Anmeldung ausgewählt ist. (In der Regel ist dieses Feature für die Zonen Intranet und Vertrauenswürdige Sites standardmäßig aktiviert.)

Ist der IIS-Server für das Senden des Headers WWW-Authenticate: Negotiate konfiguriert?

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

Sind Client und 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 erhalten kann. In diesem Beispiel lautet der Dienstprinzipalname (SPN) http/web-server.

Wenn die Kerberos-Ticketanforderung fehlschlägt, wird die Kerberos-Authentifizierung nicht verwendet. Es kann ein NTLM-Fallback auftreten, da der angeforderte SPN für den Domänencontroller 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 in Internetinformationsdiensten gehostet werden

Verwendet der Webserver einen anderen Port als den Standardwert (80)

Standardmäßig enthält Internet Explorer nicht die Portnummerinformationen im SPN, der zum Anfordern eines Kerberos-Tickets verwendet wird. Es kann ein Problem sein, wenn Sie IIS verwenden, um mehrere Websites unter verschiedenen Ports und Identitäten zu hosten. In dieser Konfiguration funktioniert die Kerberos-Authentifizierung möglicherweise nur für bestimmte Standorte, auch wenn alle SPNs ordnungsgemäß in Active Directory deklariert wurden. Um dieses Problem zu beheben, müssen Sie den FEATURE_INCLUDE_PORT_IN_SPN_KB908209 Registrierungswert festlegen. (Informationen zum Deklarieren des Schlüssels finden Sie im Abschnitt Internet Explorer Featureschlüssel.) 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. Auch wenn die URL, die in die Adressleiste des Internets Explorer eingegeben wird, lautet, fordert http://MYWEBSITEInternet 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. (Informationen zum Deklarieren des Schlüssels finden Sie unter Internet Explorer Featureschlüssel.)

Eine Netzwerkmonitor-Ablaufverfolgung 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:

Stimmt die Identität des Anwendungspools mit dem Konto überein, das dem SPN zugeordnet ist?

Wenn ein Kerberos-Ticket vom 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 übergebenen SPN, um ein Kerberos-Ticket an einen Domänencontroller anzufordern. Wenn der Domänencontroller die Anforderung verarbeiten kann (bekannter SPN), wird ein Kerberos-Ticket erstellt. Anschließend wird das Ticket mit einem Schlüssel verschlüsselt, 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 das 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 das Ticket dann 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 das Ticket dies zulässt 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 der Domäne ein Computer (in diesem Fall der Server, auf dem IIS ausgeführt wird) hinzugefügt wird. Dieser Standard-SPN ist dem Computerkonto zugeordnet. Unter IIS wird 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 sie 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 den 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 doppelten SPNs befinden:

Gründe für immer noch doppelte SPNs in AD 2012 R2 und AD 2016

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.

Außerdem wird empfohlen, die folgenden Artikel zu lesen:

• Kerberos-Authentifizierungsprobleme – Probleme mit dem Dienstprinzipalnamen (Service Principal Name, SPN) – Teil 1

• Kerberos-Authentifizierungsprobleme – Probleme mit dem Dienstprinzipalnamen (Service Principal Name, SPN) – Teil 2

• Kerberos-Authentifizierungsprobleme – Probleme mit dem Dienstprinzipalnamen (Service Principal Name, SPN) – Teil 3

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. Es bietet die folgenden Vorteile:

• Die Leistung wird erhöht, da keine Übergänge des Kernelmodus in den Benutzermodus mehr vorgenommen werden.
• Die Kerberos-Ticketdecodierung erfolgt mithilfe des Computerkontos und nicht mit der Identität des Anwendungspools. Durch diese Änderung können Mehrere Anwendungspools unter unterschiedlichen Identitäten ausgeführt werden, ohne SPNs deklarieren zu müssen.

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

Überprüfen Sie in diesem Szenario folgendes:

• Das Internet Explorer Zone, die für die URL verwendet wird. Die 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 beim Aufruf von InitializeSecurityContext nur fest, wenn die Zone, die bestimmt wird, entweder Intranet oder Vertrauenswürdige Sites ist.)

• Für das Benutzerkonto für den IIS-Anwendungspool, der Ihre Website hostet, muss das Flag "Vertrauenswürdig für Delegierung " in Active Directory festgelegt sein.

Wenn die Delegierung weiterhin fehlschlägt, sollten Sie die Verwendung des Kerberos-Configuration Manager für IIS in Betracht ziehen. Mit diesem Tool können Sie IIS-Konfigurationen für die Kerberos-Authentifizierung und für die zugeordneten SPNs in den 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 ein ziemlich großes Blob sein kann) mit jeder Anforderung senden muss, die an den Server gesendet wird. Dies ist im Gegensatz zu Authentifizierungsmethoden, die auf NTLM basieren. Standardmäßig ist NTLM sitzungsbasiert. Dies bedeutet, dass der Browser nur eine Anforderung authentifiziert, wenn er die TCP-Verbindung mit dem Server öffnet. 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 ebenfalls 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 mithilfe der authPersistNonNTLM-Eigenschaft ändern, wenn Sie unter IIS 7 und höheren Versionen ausführen. Wenn die Eigenschaft auf true festgelegt ist, wird Kerberos sitzungsbasiert. Andernfalls ist sie anforderungsbasiert. Die Leistung wird schlechter, da wir jedes Mal eine größere Datenmenge einschließen müssen, die an den Server gesendet werden soll. Weitere Informationen finden Sie unter Anforderungsbasierte und sitzungsbasierte Kerberos-Authentifizierung (oder der Parameter AuthPersistNonNTLM).

Warum schlägt die Kerberos-Delegierung zwischen meinen beiden Gesamtstrukturen fehl, obwohl sie früher funktionierte

Stellen Sie sich folgendes Szenario vor:

• 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.
• Zwischen den Gesamtstrukturen besteht eine Vertrauensstellung.

In diesem Szenario funktioniert die Kerberos-Delegierung möglicherweise nicht mehr, obwohl sie früher 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 die uneingeschrä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 zur TGT-Delegierung über eingehende Vertrauensstellungen in Windows Server hinweg.

Internet Explorer Featureschlüssel

Bei diesen Schlüsseln handelt es sich um Registrierungsschlüssel, die einige Features des Browsers aktivieren oder deaktivieren. 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 der folgenden 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 entsprechenden Pfad erstellt werden. Innerhalb des Schlüssels sollte ein DWORD-Wert mit dem Namen iexplorer.exe deklariert werden. Der Standardwert der einzelnen Schlüssel sollte je nach gewünschter Einstellung des Features entweder true oder false sein. Standardmäßig ist der Wert beider Featureschlüssel und FEATURE_INCLUDE_PORT_IN_SPN_KB908209FEATURE_USE_CNAME_FOR_SPN_KB911149false. Aus Gründen der Vollständigkeit sehen Sie hier ein Beispiel für den Export der Registrierung, indem Sie den Featureschlüssel so ändern, dass Portnummern in das Kerberos-Ticket eingeschlossen werden, auf true:

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

Weitere Informationen

Diagnoseseiten zur Problembehandlung bei der integrierten Windows-Authentifizierung