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.

Gilt für:   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 Meldung 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 Ungültige Anforderungsantworten (Anforderungsheader zu lang) auf HTTP-Anforderungen.

Hinweis

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

Dieses Verhalten tritt in einer der derzeit unterstützten Windows Versionen auf. Informationen zu den derzeit unterstützten Versionen von Windows finden Sie unter Windows Lifecycle Fact Sheet.

Ursache

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

Im Rahmen der Authentifizierungsdienst-Exchangeerstellt Windows ein Token, das den Benutzer zum Zwecke der Autorisierung darstellt. Dieses Token (auch autorisierungskontext genannt) 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 gespeichert sIDHistory 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 Claims Information (Dynamic Access Control)-Datenstruktur 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 Remoteprozeduraufrufe (Remote Procedure Call, RPC) und HTTP basieren auf dem MaxTokenSize Wert, wenn sie Puffer für Authentifizierungsvorgänge zuordnen. MaxTokenSizehat je nach Version von Windows, die das Token erstellt, den folgenden Standardwert:

  • Windows Server 2008 R2 und frühere Versionen und Windows 7 und frühere Versionen: 12.000 Bytes
  • Windows Server 2012 und neuere Versionen sowie Windows 8 und neuere Versionen: 48.000 Byte

Wenn der Benutzer mehr als 120 universellen Gruppen angehört, erstellt der Standardwert im Allgemeinen MaxTokenSize keinen ausreichend großen Puffer, um die Informationen zu speichern. Der Benutzer kann sich nicht authentifizieren und erhält möglicherweise eine Nachricht mit nicht genügend Arbeitsspeicher. Darüber hinaus können 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änenlokale Gruppen weisen beispielsweise kleinere Platzanforderungen auf. Windows Server 2012 und neuere 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 ihre 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 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 finden MaxTokenSize Sie im Abschnitt "Berechnen der maximalen Tokengröße" in diesem Artikel.

Angenommen, ein Benutzer verwendet eine Webanwendung, die auf einem SQL Server Client basiert. Im Rahmen des Authentifizierungsprozesses übergibt der 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-Datenbankcomputer

In Windows Server 2012 (und neueren Versionen) können 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

Bei Windows Server 2012 (und neueren Versionen) definiert diese Formel ihre Komponenten wie folgt:

  • 1200. Der geschätzte Overheadwert 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 der im Attribut des Kontos gespeicherten sIDHistory 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änenlokalen Gruppenmitgliedschaften als Teil des d-Werts anstelle des Werts.

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

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

  • Wenn Sie über mehrere Vertrauensstellungen verfügen, konfigurieren Sie die Vertrauensstellungen, um SIDs zu filtern. 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 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.
    • 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, eingestellt wird. Diese Reduzierung kann wiederum die größe verringern, die im Ticket erforderlich ist. Weitere Informationen finden Sie unter "Dynamische Zugriffssteuerung: Szenarioübersicht".
  • Wenn Sie Kerberos für die Verwendung einer nicht eingeschränkten Delegierung konfiguriert haben, müssen Sie den TokenSize Wert aus der Formel verdoppeln, um eine gültige Schätzung von zu MaxTokenSize erhalten.

    Wichtig

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

    Da die Komprimierung der Ressourcen-SID häufig verwendet wird und die uneingeschränkte Delegierung veraltet ist, MaxTokenSize sollten von 48.000 oder mehr für alle Szenarien ausreichend sein.

Bekannte Probleme, die sich auf MaxTokenSize auswirken

Ein MaxTokenSize Wert von 48.000 Bytes sollte für die meisten Implementierungen ausreichen. Dies ist der Standardwert in Windows Server 2012 und neueren 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 sich ein Benutzer, der zu viele Gruppenmitgliedschaften hat, nicht authentifizieren kann, aber die Berechnungen und Bedingungen, die das Problem steuern, unterscheiden sich. Dieses Problem kann z. B. beim Verwenden der Kerberos-Authentifizierung oder Windows NTLM-Authentifizierung auftreten. Weitere Informationen finden Sie unter Protokollierung eines Benutzerkontos, das Mitglied von mehr als 1.010 Gruppen ist, kann auf einem Windows Server-basierten Computer fehlschlagen.

  • Bekanntes Problem bei der Verwendung von MaxTokenSize-Werten, die größer als 48.000 sind

    Um einen Denial-of-Service-Angriffsvektor zu minimieren, verwendet Internet Information Server (IIS) eine begrenzte GRÖßE von 64 KB für HTTP-Anforderungspuffer. Ein Kerberos-Ticket, das Teil einer HTTP-Anforderung ist, wird als Base64 codiert (6 Bit werden auf 8 Bit erweitert). 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 MaxTokenSize Registrierungseintrag auf einen Wert festlegen, der größer als 48.000 Byte ist und der Pufferspeicher 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 MaxTokenSize beschrieben. Wir haben jedoch festgestellt, dass Versionen von SMS-Administrator Probleme haben, wenn die Größe MaxTokenSize 100.000 Bytes oder größer ist.

    Wir haben außerdem festgestellt, dass das IPSEC-IKE-Protokoll nicht zulässt, dass ein Sicherheits-BLOB größer als 66.536 Bytes wird, und dass es auch fehlschlägt, wenn MaxTokenSize ein höherer Wert festgelegt ist.