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

In diesem Artikel erfahren Sie, wie Sie die Probleme eines Kerberos-Authentifizierungsfehlers lösen, wenn ein Benutzer zu vielen Gruppen gehört.

Gilt für: Windows 10 (alle Editionen), Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Ursprüngliche KB-Nummer: 327825

Symptome

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

Weitere Informationen zum Kontext des Fehlers finden Sie unter HTTP 400 Bad Request (Anforderungsheader zu lang) Antworten auf HTTP-Anforderungen.

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 Windows-Lebenszyklus.

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.

Im Rahmen des Exchange-Authentifizierungsdiensts erstellt Windows ein Token, das den Benutzer zu Autorisierungszwecken 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. Es 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 das Token auch in der Datenstruktur active Directory Claims information (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 Plätze im Ticket belegen.

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

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

Wenn der Benutzer zu mehr als 120 universellen Gruppen gehört, erstellt der Standardwert MaxTokenSize im Allgemeinen keinen ausreichend großen Puffer, um die Informationen aufzunehmen. Der Benutzer kann sich nicht authentifizieren und erhält möglicherweise eine Meldung vom Typ "Nicht genügend Arbeitsspeicher ". Darüber hinaus kann Windows möglicherweise nicht Gruppenrichtlinie Einstellungen für den Benutzer anwenden.

Lösung

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

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 Bestimmen eines neuen Werts für MaxTokenSizefinden Sie im Abschnitt Berechnen der maximalen Tokengröße dieses Artikels.

Betrachten Sie beispielsweise einen Benutzer, 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
• 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 Gruppenrichtlinie Einstellung Computerkonfiguration\Administrative Vorlagen\System\KDC\Warning 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. Mit dieser Berechnung können Sie ermitteln, ob Sie ändern MaxTokenSizemüssen.

TokenSize = 1200 + 40d + 8s

Bei Windows Server 2012 (und höheren Versionen) definiert diese Formel die zugehörigen 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änenmitgliedschaften in lokalen Gruppen als Teil des d-Werts anstelle des s-Werts .

Wenn Sie den MaxTokenSize Wert 0x0000FFFF (64K) haben, können Sie möglicherweise ungefähr 1600 d-Klassen-SIDs oder ungefähr 8000 SIDs der s-Klasse puffern. Allerdings beeinflussen eine Reihe anderer Faktoren den Wert, den Sie sicher für MaxTokenSizeverwenden können, einschließlich der folgenden:

• Wenn Sie für Delegierungskonten vertrauenswürdig 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 auch die folgenden Faktoren auf die SID-Speicherplatzanforderungen 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.
  • Dynamische Access Control fügt dem Ticket Active Directory-Ansprüche hinzu, wodurch die Größenanforderungen erhöht werden. Nachdem Sie Jedoch Ansprüche mit Windows Server 2012 Dateiservern bereitgestellt haben, können Sie davon ausgehen, dass eine erhebliche Anzahl von Gruppen, die den Dateizugriff steuern, auslaufen wird. Diese Reduzierung kann wiederum die größe reduzieren, die im Ticket benötigt wird. Weitere Informationen finden Sie unter Dynamische Access Control: Szenarioübersicht.

• Wenn Sie Kerberos für die Verwendung der uneingeschränkten Delegierung konfiguriert haben, müssen Sie den TokenSize Wert aus der Formel verdoppeln, um eine gültige Schätzung von MaxTokenSizezu erhalten.

  Wichtig

  Im Jahr 2019 hat Microsoft Updates für Windows ausgeliefert, mit denen die Standardkonfiguration der uneingeschränkten Delegierung für Kerberos deaktiviert wurde. Weitere Informationen finden Sie unter Updates zur TGT-Delegierung über eingehende Vertrauensstellungen in Windows Server hinweg.

  Da die Ressourcen-SID-Komprimierung weit verbreitet ist und die uneingeschränkte Delegierung veraltet ist, MaxTokenSize sollte eine Größe von 48.000 oder mehr für alle Szenarien ausreichend sein.

Bekannte Probleme, die MaxTokenSize betreffen

Ein MaxTokenSize Wert von 48.000 Bytes sollte für die meisten Implementierungen ausreichend sein. Dies ist der Standardwert in Windows Server 2012 und höheren Versionen. Wenn Sie sich jedoch für die Verwendung eines größeren Werts entscheiden, überprüfen Sie die bekannten Probleme in diesem Abschnitt.

• Größenlimit von 1.010 Gruppen-SIDs für das LSA-Zugriffstoken

  Dieses Problem ist insofern ähnlich, als ein Benutzer, der zu viele Gruppenmitgliedschaften hat, sich nicht authentifizieren kann, aber die Berechnungen und Bedingungen, die das Problem steuern, sind unterschiedlich. Beispielsweise kann dieses Problem beim Benutzer bei der Verwendung der Kerberos-Authentifizierung oder der Windows NTLM-Authentifizierung auftreten. Weitere Informationen finden Sie unter Protokollierung bei einem Benutzerkonto, das Mitglied von mehr als 1.010 Gruppen ist, kann auf einem Windows Server-basierten Computer fehlschlagen.

• Bekanntes Problem bei verwendung von MaxTokenSize-Werten größer als 48.000

  Um einen Denial-of-Service-Angriffsvektor zu minimieren, verwendet Internet Information Server (IIS) eine begrenzte HTTP-Anforderungspuffergröße von 64 KB. Ein Kerberos-Ticket, das Teil einer HTTP-Anforderung ist, wird als Base64 codiert (6 Bits erweitert auf 8 Bit). Daher verwendet das Kerberos-Ticket 133 Prozent seiner ursprünglichen Größ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 48.000 Bytes ist und der Pufferspeicherplatz für SIDs verwendet wird, kann ein IIS-Fehler auftreten. Wenn Sie den MaxTokenSize Registrierungseintrag jedoch auf 48.000 Byte 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 der Verwendung von MaxTokenSize-Werten größer als 65.535

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

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