Probleme mit der Kerberos-Authentifizierung, wenn ein Benutzer zu vielen Gruppen gehört

Dieser Artikel hilft Ihnen, die Probleme der Kerberos-Authentifizierungsfehler zu lösen, wenn ein Benutzer zu vielen Gruppen gehört.

Ursprüngliche KB-Nummer: 327825

Symptome

Ein Benutzer, der zu einer großen Anzahl von Sicherheitsgruppen gehört, hat Probleme bei der Authentifizierung. Beim Authentifizieren wird dem Benutzer möglicherweise eine Meldung wie HTTP 400 – Ungültige Anforderung (Anforderungsheader zu lang) angezeigt. Der Benutzer hat außerdem Probleme beim Zugriff auf Ressourcen, und die Gruppenrichtlinieneinstellungen des Benutzers werden möglicherweise nicht ordnungsgemäß aktualisiert.

Weitere Informationen zum Kontext des Fehlers finden Sie unter HTTP 400 Bad Request (Request Header too long) Antworten auf HTTP-Anforderungen.

Notiz

Unter ähnlichen Bedingungen funktioniert die Windows NTLM-Authentifizierung erwartungsgemäß. Möglicherweise wird das Kerberos-Authentifizierungsproblem nicht angezeigt, es sei denn, Sie analysieren das Windows-Verhalten. In solchen Szenarien ist Windows jedoch möglicherweise nicht in der Lage, Gruppenrichtlinieneinstellungen zu aktualisieren.

Dieses Verhalten tritt in einer der derzeit unterstützten Windows-Versionen auf. Informationen zu den derzeit unterstützten Versionen von Windows finden Sie im Informationsblatt zum Lebenszyklus von Windows.

Ursache

Der Benutzer kann sich nicht authentifizieren, da das Ticket, das Kerberos erstellt, um den Benutzer darzustellen, nicht groß genug ist, um alle Gruppenmitgliedschaften des Benutzers zu enthalten.

Als Teil des Authentifizierungsdiensts Exchange erstellt Windows ein Token, das den Benutzer für die Autorisierung darstellt. Dieses Token (auch als Autorisierungskontext bezeichnet) enthält die Sicherheits-IDs (SID) des Benutzers und die SIDs aller Gruppen, zu denen der Benutzer gehört. Sie enthält auch alle SIDs, die im Attribut des Benutzerkontos sIDHistory gespeichert sind. Kerberos speichert dieses Token in der PAC-Datenstruktur (Privilege Attribute Certificate) im Kerberos Ticket-Getting Ticket (TGT). Ab Windows Server 2012 speichert Kerberos auch das Token in der Active Directory-Anspruchsinformationen -Datenstruktur (Dynamic Access Control) im Kerberos-Ticket. Wenn der Benutzer Mitglied einer großen Anzahl von Gruppen ist und viele Ansprüche für den Benutzer oder das verwendete Gerät vorhanden sind, können diese Felder viele Leerzeichen im Ticket belegen.

Das Token hat eine feste maximale Größe (MaxTokenSize). Transportprotokolle wie Remoteprozeduraufruf (RPC) und HTTP basieren auf dem MaxTokenSize Wert, wenn sie Puffer für Authentifizierungsvorgänge zuordnen. MaxTokenSize hat den folgenden Standardwert, abhängig von der Version von Windows, die das Token erstellt:

• Windows Server 2008 R2 und frühere Versionen sowie Windows 7 und frühere Versionen: 12.000 Bytes
• Windows Server 2012 und höhere Versionen sowie Windows 8 und höher: 48.000 Bytes

Wenn der Benutzer zu mehr als 120 universellen Gruppen gehört, erstellt der Standardwert MaxTokenSize keinen großen Puffer, um die Informationen zu enthalten. Der Benutzer kann sich nicht authentifizieren und erhält möglicherweise eine Abwesenheitsnachricht . Darüber hinaus kann Windows möglicherweise keine Gruppenrichtlinieneinstellungen für den Benutzer anwenden.

Notiz

Andere Faktoren wirken sich auch auf die maximale Anzahl von Gruppen aus. Beispielsweise weisen SIDs für globale und domänenlokale Gruppen kleinere Platzanforderungen auf. Windows Server 2012 und höhere Versionen fügen dem Kerberos-Ticket Anspruchsinformationen hinzu und komprimieren auch Ressourcen-SIDs. Beide Features ändern die Platzanforderungen.

Lösung

Um dieses Problem zu beheben, aktualisieren Sie die Registrierung auf jedem Computer, der am Kerberos-Authentifizierungsprozess teilnimmt, einschließlich der Clientcomputer. Es wird empfohlen, alle Windows-basierten Systeme zu aktualisieren, insbesondere, wenn sich Ihre Benutzer über mehrere Domänen oder Gesamtstrukturen anmelden müssen.

Wichtig

Wird die Registrierung falsch angepasst, können schwerwiegende Probleme auftreten. Bevor Sie sie ändern, sichern Sie die Registrierung für die Wiederherstellung, falls Probleme auftreten.

Legen Sie auf jedem dieser Computer den MaxTokenSize Registrierungseintrag auf einen größeren Wert fest. Sie finden diesen Eintrag im HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Unterschlüssel. Die Computer müssen neu gestartet werden, nachdem Sie diese Änderung vorgenommen haben.

Weitere Informationen zum Ermitteln eines neuen Werts MaxTokenSizefinden Sie im Abschnitt "Berechnen der maximalen Tokengröße " in diesem Artikel.

Ziehen Sie beispielsweise einen Benutzer in Betracht, der eine Webanwendung verwendet, die auf einem SQL Server-Client basiert. Im Rahmen des Authentifizierungsprozesses übergibt der SQL Server-Client das Token des Benutzers an eine Back-End-SQL Server-Datenbank. In diesem Fall müssen Sie den MaxTokenSize Registrierungseintrag auf jedem der folgenden Computer konfigurieren:

• Der Clientcomputer, auf dem Internet Explorer ausgeführt wird
• Der Webserver, auf dem IIS ausgeführt wird
• Der SQL Server-Clientcomputer
• Der SQL Server-Datenbankcomputer

In Windows Server 2012 (und höheren Versionen) kann Windows ein Ereignis (Ereignis-ID 31) protokollieren, wenn die Tokengröße einen bestimmten Schwellenwert überschreitet. Um dieses Verhalten zu aktivieren, müssen Sie die Gruppenrichtlinieneinstellung Computerkonfiguration\Administrative Vorlagen\System\KDC\Warnung für große Kerberos-Tickets konfigurieren.

Berechnen der maximalen Tokengröße

Verwenden Sie die folgende Formel, um die Größe des Tokens zu berechnen, das Windows für einen bestimmten Benutzer generiert. Diese Berechnung hilft Ihnen zu bestimmen, ob Sie sich ändern MaxTokenSizemüssen.

TokenSize = 1200 + 40d + 8s

Für Windows Server 2012 (und höhere Versionen) definiert diese Formel ihre Komponenten wie folgt:

• 1200. Der geschätzte Overheadwert für ein Kerberos-Ticket. Dieser Wert kann je nach Faktoren wie der Länge des DNS-Domänennamens und der Länge des Clientnamens variieren.
• d. Die Summe der folgenden Werte:
  • Die Anzahl der Mitgliedschaften in universellen Gruppen, die sich außerhalb der Kontodomäne des Benutzers befinden.
  • Die Anzahl der im Attribut des Kontos sIDHistory gespeicherten SIDs. Dieser Wert zählt Gruppenmitgliedschaften und Benutzer-SIDs.
• s. Die Summe der folgenden Werte:
  • Die Anzahl der Mitgliedschaften in universellen Gruppen, die sich innerhalb der Kontodomäne des Benutzers befinden.
  • Die Anzahl der Mitgliedschaften in domänenlokalen Gruppen.
  • Die Anzahl der Mitgliedschaften in globalen Gruppen.

Windows Server 2008 R2 und frühere Versionen verwenden dieselbe Formel. Diese Versionen betrachten jedoch die Anzahl der Domänen-lokalen Gruppenmitgliedschaften als Teil des d-Werts anstelle des Werts.

Wenn Sie einen MaxTokenSize Wert von 0x0000FFFF (64K) haben, können Sie möglicherweise ca. 1600 d-Klassen-SIDs oder ca. 8000 s-Klassen-SIDs puffern. Eine Reihe anderer Faktoren beeinflussen jedoch den Wert, für MaxTokenSizeden Sie sicher verwenden können, einschließlich der folgenden:

• Wenn Sie vertrauenswürdige Konten für Delegierungskonten verwenden, benötigt jede SID doppelt so viel Speicherplatz.

• Wenn Sie über mehrere Vertrauensstellungen verfügen, konfigurieren Sie die Vertrauensstellungen zum Filtern von SIDs. Diese Konfiguration reduziert die Auswirkungen der Kerberos-Ticketgröße.

• Wenn Sie Windows Server 2012 oder eine höhere Version verwenden, wirken sich die folgenden Faktoren auch auf die ANFORDERUNGEN an den SID-Speicherplatz aus:

  • Es gibt ein neues Schema zum Komprimieren der SIDs im PAC. Weitere Informationen finden Sie unter KDC-Ressourcen-SID-Komprimierung. Dieses Feature reduziert die größe, die für SIDs im Ticket erforderlich ist.
  • Die dynamische Zugriffssteuerung fügt dem Ticket Active Directory-Ansprüche hinzu, wodurch die Größenanforderungen erhöht werden. Nach der Bereitstellung von Ansprüchen mit Windows Server 2012-Dateiservern können Sie jedoch davon ausgehen, dass eine erhebliche Anzahl von Gruppen, die den Dateizugriff steuern, auslaufen. Diese Reduzierung kann wiederum die erforderliche Größe im Ticket reduzieren. Weitere Informationen finden Sie unter Dynamic Access Control: Scenario Overview.

• Wenn Sie Kerberos für die Verwendung nicht eingeschränkter Delegierung konfiguriert haben, müssen Sie den TokenSize Wert aus der Formel verdoppeln, um eine gültige Schätzung von MaxTokenSize.

  Wichtig

  Im Jahr 2019 hat Microsoft Updates für Windows ausgeliefert, die die Standardkonfiguration der nicht eingeschränkten Delegierung für Kerberos deaktiviert haben. Weitere Informationen finden Sie unter Updates für die TGT-Delegierung über eingehende Vertrauensstellungen in Windows Server.

  Da die Ressourcen-SID-Komprimierung weit verbreitet ist und die nicht eingeschränkte Delegierung veraltet ist, MaxTokenSize sollte 48000 oder größer für alle Szenarien ausreichend sein.

Bekannte Probleme, die Sich auf MaxTokenSize auswirken

Für die meisten Implementierungen sollte ein MaxTokenSize Wert von 48.000 Bytes ausreichen. Dies ist der Standardwert in Windows Server 2012 und höheren Versionen. Wenn Sie jedoch einen größeren Wert verwenden möchten, überprüfen Sie die bekannten Probleme in diesem Abschnitt.

• Größenbeschränkung von 1.010 Gruppen-SIDs für das LSA-Zugriffstoken

  Dieses Problem ist ähnlich, da ein Benutzer, der zu viele Gruppenmitgliedschaften hat, nicht authentifiziert werden kann, aber die Berechnungen und Bedingungen, die das Problem steuern, unterscheiden sich. Der Benutzer kann dieses Problem beispielsweise bei Verwendung der Kerberos-Authentifizierung oder der Windows NTLM-Authentifizierung feststellen. Weitere Informationen finden Sie unter Anmelden bei einem Benutzerkonto, das Mitglied von mehr als 1.010 Gruppen ist, auf einem Windows Server-basierten Computer möglicherweise fehl.

• Bekanntes Problem beim Verwenden von Werten von MaxTokenSize größer als 48.000

  Um einen Denial-of-Service-Angriffsvektor zu mindern, verwendet Internetinformationsserver (IIS) eine eingeschränkte HTTP-Anforderungspuffergröße von 64 KB. Ein Kerberos-Ticket, das Teil einer HTTP-Anforderung ist, wird als Base64 codiert (6 Bit erweitert auf 8 Bit). Daher verwendet das Kerberos-Ticket 133 Prozent seiner Originalgröße. Wenn die maximale Puffergröße in IIS 64 KB beträgt, kann das Kerberos-Ticket daher 48.000 Bytes verwenden.

  Wenn Sie den Registrierungseintrag auf einen Wert festlegen, der MaxTokenSize größer als 48000 Bytes ist und der Pufferspeicher für SIDs verwendet wird, kann ein IIS-Fehler auftreten. Wenn Sie den MaxTokenSize Registrierungseintrag jedoch auf 48.000 Bytes festlegen und den Speicherplatz für SIDs und Ansprüche verwenden, tritt ein Kerberos-Fehler auf.

  Weitere Informationen zu IIS-Puffergrößen finden Sie unter Einschränken der Headergröße der HTTP-Übertragung, die IIS von einem Client in Windows 2000 akzeptiert.

• Bekannte Probleme bei verwendung von MaxTokenSize größer als 65.535

  In früheren Versionen dieses Artikels wurden Werte von bis zu 100.000 Bytes für MaxTokenSize. Wir haben jedoch festgestellt, dass Versionen von SMS-Administrator Probleme haben, wenn die MaxTokenSize Größe 100.000 Bytes oder größer ist.

  Wir haben auch festgestellt, dass das IPSEC IKE-Protokoll nicht zulässt, dass ein Sicherheits-BLOB größer als 66.536 Bytes wird, und es würde auch fehlschlagen, wenn MaxTokenSize auf einen größeren Wert festgelegt wird.