Problembehandlung bei 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 der potenziellen 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 davon ausgehen, dass Sie das Kerberos-Authentifizierungsprotokoll verwenden. In diesem Fall werden Sie von Ihrem Browser sofort zur Eingabe von Anmeldeinformationen aufgefordert, wie folgt:
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. Die angeforderte Ressource erfordert eine Benutzerauthentifizierung.
Auf dem server Microsoft-Internetinformationsdienste (IIS) enthalten die Websiteprotokolle Anforderungen, die in einem 401.2-Statuscode 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
Auf dem Bildschirm wird auch der 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 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 Authentifizierungstestseiteerstellen.
Wenn Sie klassisches ASP verwenden, können Sie die folgende Seite "Testkerb.asp" 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 richtet sich an eine Seite, 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 jedes der folgenden Elemente in der angegebenen Reihenfolge.
Dinge, die überprüft werden müssen, ob 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 Client und 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:
- Client und Server befinden sich nicht in derselben Domäne, sondern in zwei Domänen derselben Gesamtstruktur.
- Client und Server befinden sich in zwei unterschiedlichen Gesamtstrukturen.
Diese möglichen Szenarien werden im Abschnitt "Warum schlägt die Kerberos-Delegierung zwischen meinen beiden Gesamtstrukturen fehl" erläutert, obwohl sie in diesem Artikel verwendet wurde.
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 der Zone "Lokales Intranet" des Browsers zugeordnet sind.
- 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 Eigenschaftenfenster wird die Zone angezeigt, in der sich der Browser entschieden hat, die Website einzuschließen, zu der Sie browsen.
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 die automatische Anmeldung ausgewählt ist. (In der Regel ist dieses Feature standardmäßig für die Zonen "Intranet" und "Vertrauenswürdige Sites" aktiviert).
Hinweis
Selbst wenn diese Konfiguration nicht üblich ist (da der Client Zugriff auf einen DC benötigt), 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 wurden 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
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 Windows <providers> Authentifizierungsanbieter. Sie können über die Anbietereinstellung der Windows-Authentifizierungsdetails im IIS-Manager auf die Konsole zugreifen.
Hinweis
Standardmäßig ist die NTAuthenticationProviders-Eigenschaft nicht festgelegt. Dies führt dazu, dass IIS sowohl Negotiate- 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 abrufen?
Mit dem Kerberos-Listentool (KLIST) können Sie ü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.
Hinweis
KLIST ist ein systemeigenes Windows-Tool seit Windows Server 2008 für serverseitige Betriebssysteme und Windows 7 Service Pack 1 für clientseitige Betriebssysteme.
Wenn die Kerberos-Ticketanforderung fehlschlägt, wird die Kerberos-Authentifizierung nicht verwendet. Ntlm-Fallback kann auftreten, da der angeforderte SPN dem DC unbekannt ist. Wenn der DC nicht erreichbar ist, tritt kein NTLM-Fallback auf.
Informationen zum Deklarieren eines SPN finden Sie im folgenden Artikel:
Verwendet der Webserver einen anderen Port als den Standardport (80)
Standardmäßig enthält Internet Explorer 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. (Informationen zum Deklarieren des Schlüssels finden Sie im Abschnitt mit den Featureschlüsseln von Internet Explorer.) Diese Einstellung erzwingt, dass Internet Explorer die Portnummer in den SPN einschließt, 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 zuerst 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 in die Internet Explorer-Adressleiste eingegebene URL http://MYWEBSITE lautet, 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. (Informationen zum Deklarieren des Schlüssels finden Sie unter den Internet Explorer-Featureschlüsseln.)
Eine Netzwerküberwachungsablaufverfolgung ist eine gute Methode zum Überprüfen des SPN, 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 spn zugeordneten Konto.
Wenn ein Kerberos-Ticket von Internet Explorer an einen IIS-Server gesendet wird, wird das Ticket mithilfe eines privaten Schlüssels 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:
Internet Explorer ermittelt einen SPN mithilfe der URL, die in die Adressleiste eingegeben wird.
Der SPN wird über eine Security Support Provider Interface (SSPI)-API (InitializeSecurityContext) an die Systemkomponente übergeben, die für Windows Sicherheit (den LSASS-Prozess (Local Security Authority Subsystem Service) zuständig ist. 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.
LSASS verwendet den übergebenen SPN, um ein Kerberos-Ticket für einen DC anzufordern. Wenn der DC die Anforderung (bekannter SPN) bereitstellen kann, wird ein Kerberos-Ticket erstellt. Anschließend wird das Ticket mithilfe eines Schlüssels verschlüsselt, der aus dem Hash des Benutzerkontokennworts für das Konto erstellt wird, das dem SPN zugeordnet ist. LSASS sendet das Ticket dann an den Client. Für Internet Explorer ist das Ticket ein undurchsichtiges Blob.
Internet Explorer kapselt das Kerberos-Ticket, das von LSASS im Header bereitgestellt
Authorization: Negotiatewird, und sendet das Ticket dann an den IIS-Server.IIS verarbeitet die Anforderung und leitet sie mithilfe des angegebenen Hostheaders an den richtigen Anwendungspool weiter.
Der Anwendungspool versucht, das Ticket mithilfe von SSPI/LSASS-APIs und den folgenden Bedingungen zu entschlüsseln:
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 angibt, dass das Ticket während des Transports auf irgendeine 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 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 den HTTP/mywebsite-SPN mithilfe des UserAppPool1- oder UserAppPool2-Kennworts verschlüsselt wird. Diese Konfiguration generiert in der Regel KRB_AP_ERR_MODIFIED Fehler. Verwenden Sie die im folgenden Artikel dokumentierten Tools, um festzustellen, ob Sie sich in diesem Szenario mit fehlerhaften doppelten 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.
Außerdem wird empfohlen, die folgenden Artikel zu lesen:
Schlägt die Kerberos-Authentifizierung in IIS 7 und neueren 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 Übergänge zwischen Kernelmodus und Benutzermodus nicht mehr vorgenommen werden.
- Die Kerberos-Ticketdecodierung erfolgt mithilfe des Computerkontos und nicht der Anwendungspoolidentität. Mit dieser Änderung können Sie mehrere Anwendungspools unter verschiedenen Identitäten ausführen, 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-Hostnamen deklariert. Um dieses Problem zu vermeiden, verwenden Sie eine der folgenden Methoden:
- 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 Neu in IIS 7 – Kernelmodusauthentifizierung.
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. Die Kerberos-Delegierung ist nur für intranet- und vertrauenswürdige Sites zulässig. (Mit anderen Worten: Internet Explorer legt das
ISC_REQ_DELEGATEKennzeichen beim Aufrufen von InitializeSecurityContext nur fest, wenn die zone, die bestimmt wird, intranet- oder vertrauenswürdige Sites ist.)Für das Benutzerkonto für den IIS-Anwendungspool, der Ihren Standort hostet, muss das Flag "Vertrauenswürdig für Delegierung" in Active Directory festgelegt sein.
Wenn die Delegierung weiterhin 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 zugeordneten SPNs für die Zielkonten diagnostizieren und beheben. Weitere Informationen finden Sie im README.md. Sie können das Tool hierherunterladen.
Warum erhalte ich 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 steht im Gegensatz zu Authentifizierungsmethoden, die ntlm verwenden. Standardmäßig ist NTLM sitzungsbasiert. Dies bedeutet, dass der Browser nur eine Anforderung authentifiziert, wenn die TCP-Verbindung mit dem Server geöffnet wird. Jede nachfolgende Anforderung auf derselben 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öher ausgeführt werden. Wenn die Eigenschaft auf "true" festgelegt ist, wird Kerberos sitzungsbasiert. Andernfalls ist sie anforderungsbasiert. Die Leistung wird schlechter sein, da wir eine größere Menge an Daten einschließen müssen, die jedes Mal an den Server gesendet werden. Weitere Informationen finden Sie unter Anforderungsbasierte im Vergleich zur sitzungsbasierten Kerberos-Authentifizierung (oder dem Parameter AuthPersistNonNTLM).
Hinweis
Es ist möglicherweise nicht sinnvoll, die Kerberos-Authentifizierung für alle Objekte blind zu verwenden. Die Verwendung der Kerberos-Authentifizierung zum Abrufen von Hunderten von Bildern mithilfe bedingter GET-Anforderungen, die wahrscheinlich 304 nicht geänderte Antworten generieren, entspricht dem Versuch, eine Fliegt mithilfe eines Hammers zu killen. Eine solche Methode bietet auch keine offensichtlichen Sicherheitsvorteile.
Warum schlägt die Kerberos-Delegierung zwischen meinen beiden Gesamtstrukturen fehl, obwohl sie früher funktioniert hat
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.
- Sie haben eine Vertrauensstellung zwischen den Gesamtstrukturen.
In diesem Szenario funktioniert die Kerberos-Delegierung möglicherweise nicht mehr, obwohl sie zuvor funktioniert hat 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 für die TGT-Delegierung bei eingehenden Vertrauensstellungen in Windows Server.
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 definiertHKEY_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 entsprechenden Pfad erstellt werden. Innerhalb des Schlüssels sollte ein benannter DWORD-Wert iexplorer.exe deklariert werden. Der Standardwert jedes Schlüssels sollte je nach der gewünschten Einstellung des Features entweder "true" oder "false" lauten. Standardmäßig ist der Wert von beiden Featureschlüsseln FEATURE_INCLUDE_PORT_IN_SPN_KB908209 und FEATURE_USE_CNAME_FOR_SPN_KB911149 , false. 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 auf "true" festgelegt werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001