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

Dieser Artikel hilft Ihnen bei der Lösung der Probleme des Kerberos-Authentifizierungsfehlers, wenn ein Benutzer zu vielen Gruppen gehört.

Ursprüngliche Produktversion:   Windows 10 – alle Editionen, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Ursprüngliche KB-Nummer:   327825

Problembeschreibung

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 Nachricht wie HTTP 400 - Ungültige Anforderung (Anforderungsheader zu lang) angezeigt. Der Benutzer hat auch 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) responses to HTTP requests.

Hinweis

Unter ähnlichen Bedingungen funktioniert die Windows NTLM-Authentifizierung wie erwartet. Möglicherweise wird das Problem mit der Kerberos-Authentifizierung nur angezeigt, wenn Sie das Verhalten von Windows analysieren. In solchen Szenarien kann Windows jedoch möglicherweise keine Gruppenrichtlinieneinstellungen aktualisieren.

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

Ursache

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

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

Das Token hat eine feste maximale Größe ( MaxTokenSize ). Transportprotokolle wie RPC (Remote Procedure Call) und HTTP verwenden den Wert, wenn sie Puffer für MaxTokenSize 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üheren Versionen sowie Windows 7 und frühere Versionen: 12.000 Byte
  • Windows Server 2012 und neueren Versionen und Windows 8 und neueren Versionen: 48.000 Byte

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

Hinweis

Andere Faktoren wirken sich auch auf die maximale Anzahl von Gruppen aus. SiDs für globale und domänen lokale Gruppen haben beispielsweise geringere Speicherplatzanforderungen. Windows Server 2012 und neueren Versionen fügen Anspruchsinformationen zum Kerberos-Ticket 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 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.

Wichtig

Durch eine fehlerhafte Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Sichern Sie vor dem Ändern die Registrierung für die Wiederherstellung,falls Probleme auftreten.

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

Weitere Informationen zum Bestimmen eines neuen Werts für finden Sie im Abschnitt "Berechnen der maximalen MaxTokenSize Tokengröße" in diesem Artikel.

Stellen Sie sich beispielsweise einen Benutzer vor, der eine Webanwendung verwendet, die auf einem SQL Server basiert. Im Rahmen des Authentifizierungsprozesses übergibt SQL Server Client das Benutzertoken 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 A0

In Windows Server 2012 (und späteren 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 ändern MaxTokenSize müssen.

TokenSize = 1200 + 40d + 8s

Für Windows Server 2012 (und spätere Versionen) definiert diese Formel ihre Komponenten wie folgt:

  • 1200. Der geschätzte Mehraufwandswert für ein Kerberos-Ticket. Dieser Wert kann abhängig von 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 von SIDs, die im Attribut des Kontos gespeichert sIDHistory sind. 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änen lokalen Gruppen.
    • Die Anzahl der Mitgliedschaften in globalen Gruppen.

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

Bei einem Wert von MaxTokenSize 0x0000FFFF (64K) können Sie möglicherweise ca. 1600 d-Klassen-SIDs oder ca. 8.000 s -Klassen-SIDs puffern. Eine Reihe anderer Faktoren beeinflussen jedoch den Wert, den Sie sicher verwenden können, einschließlich MaxTokenSize der folgenden:

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

  • Wenn Sie mehrere Vertrauensstellungen haben, konfigurieren Sie die Vertrauensstellungen so, dass SIDs gefiltert werden. Diese Konfiguration verringert die Auswirkungen der Kerberos-Ticketgröße.

  • Wenn Sie eine Windows Server 2012 oder eine spätere Version verwenden, wirken sich die folgenden Faktoren auch auf die Anforderungen an den SPEICHERPLATZ der SID aus:

    • Es gibt ein neues Schema zum Komprimieren der SIDs im PAC. Weitere Informationen finden Sie unter Komprimierung der KDC-Ressourcen-SID. Mit diesem Feature wird die größe reduziert, die für SIDs im Ticket erforderlich ist.
    • Die dynamische Zugriffssteuerung fügt dem Ticket Active Directory-Ansprüche hinzu, was die Größenanforderungen erhöht. Nach der Bereitstellung von Ansprüchen mit Windows Server 2012 dateiservern können Sie jedoch davon aus gehen, dass eine erhebliche Anzahl von Gruppen, die den Dateizugriff steuern, aus dem Weg gehen wird. Durch diese Reduzierung kann wiederum die größe reduziert werden, die für das Ticket erforderlich ist. Weitere Informationen finden Sie unter Dynamic Access Control: Scenario Overview.
  • Wenn Sie Kerberos für die Verwendung der nicht-kontrollierten Delegierung konfiguriert haben, müssen Sie den Wert aus der Formel verdoppeln, um eine gültige Schätzung von TokenSize zu MaxTokenSize erhalten.

    Wichtig

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

    Da die Komprimierung der Ressourcen-SID weit verbreitet ist und die nicht mehr komprimierte Delegierung veraltet ist, sollten 48.000 oder mehr für alle Szenarien MaxTokenSize ausreichen.

Bekannte Probleme, die MaxTokenSize betreffen

Ein MaxTokenSize Wert von 48.000 Bytes sollte für die meisten Implementierungen ausreichen. Dies ist der Standardwert in Windows Server 2012 und späteren 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

    This issue is similar in that a user who has too many group memberships cannot authenticate, but the calculations and conditions that govern the issue are different. Dieses Problem kann beispielsweise auftreten, wenn der Benutzer entweder die Kerberos- oder die Windows NTLM-Authentifizierung verwendet. Weitere Informationen finden Sie unter Protokollierung für ein Benutzerkonto, das Mitglied von mehr als 1.010Gruppen ist, kann auf einem Windows Server-basierten Computer fehlschlagen.

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

    Um einen Denial-of-Service-Angriffsvektor zu verringern, verwendet Internet Information Server (IIS) eine begrenzte Größe des HTTP-Anforderungspuffers von 64 KB. Ein Kerberos-Ticket, das Teil einer HTTP-Anforderung ist, wird als Base64 codiert (6 Bit auf 8 Bit erweitert). Daher verwendet das Kerberos-Ticket 133 Prozent seiner ursprünglichen Größe. Wenn die maximale Puffergröße in IIS also 64 KB beträgt, kann das Kerberos-Ticket 48.000 Byte verwenden.

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

    Weitere Informationen zu den Größen von IIS-Puffern 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 Werten von MaxTokenSize größer als 65.535

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

    Wir haben außerdem festgestellt, dass das IPSEC-IKE-Protokoll nicht zu lässt, dass ein Sicherheits-BLOB größer als 66.536 Byte wird, und es würde auch fehlschlagen, wenn ein größerer Wert festgelegt MaxTokenSize ist.