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

  • Artikel

Dieser Artikel hilft Ihnen bei der Lösung der Probleme bei Kerberos-Authentifizierungsfehlern, 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 angezeigt, z. B. HTTP 400 – Ungültige Anforderung (Anforderungsheader zu lang). 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 (Request Header too long) responses to HTTP requests.

Hinweis

Unter ähnlichen Bedingungen funktioniert die Windows NTLM-Authentifizierung wie erwartet. Möglicherweise wird das Kerberos-Authentifizierungsproblem nur angezeigt, wenn Sie das Windows-Verhalten analysieren. In solchen Szenarien kann Windows jedoch möglicherweise Gruppenrichtlinie Einstellungen 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 im Windows-Lebenszyklus-Factsheet.

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.

Als Teil des Authentifizierungsdiensts Exchange 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 Active Directory-Datenstruktur für Ansprüche (Dynamic Access Control) 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 Remoteprozeduraufruf (Remote Procedure Call, RPC) und HTTP basieren auf dem MaxTokenSize Wert, wenn sie Puffer für Authentifizierungsvorgänge zuweisen. 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 neuere Versionen sowie Windows 8 und höhere Versionen: 48.000 Bytes

Wenn der Benutzer mehr als 120 universellen Gruppen angehö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 Nachricht mit nicht genügend Arbeitsspeicher . Darüber hinaus kann Windows möglicherweise Gruppenrichtlinie Einstellungen für den Benutzer nicht anwenden.

Hinweis

Andere Faktoren wirken sich auch auf die maximale Anzahl von Gruppen aus. Beispielsweise haben SIDs für globale und domänenlokale Gruppen einen geringeren Platzbedarf. Windows Server 2012 und neueren Versionen fügen dem Kerberos-Ticket Anspruchsinformationen hinzu und komprimieren außerdem Ressourcen-SIDs. Beide Features ändern den Platzbedarf.

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. Bevor Sie sie ändern, sichern Sie die Registrierung zur 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 durchgeführt haben.

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

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 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 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\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. Mit dieser Berechnung können Sie ermitteln, ob Sie eine Änderung vornehmen MaxTokenSizemü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 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 Kontoattribut gespeicherten SIDs sIDHistory . 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 s-Werts .

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

  • Wenn Sie vertrauenswürdig 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 SID-Platzanforderungen aus:

    • Es gibt ein neues Schema zum Komprimieren der SIDs im PAC. Weitere Informationen finden Sie unter KDC Resource SID Compression. Dieses Feature reduziert die für SIDs im Ticket erforderliche Größe.
    • Dynamische Access Control fügt Active Directory-Ansprüche zum Ticket hinzu, wodurch die Größenanforderungen erhöht werden. Nachdem Sie Ansprüche jedoch mit Windows Server 2012 Dateiservern bereitgestellt haben, können Sie davon ausgehen, dass eine beträchtliche Anzahl von Gruppen, die den Dateizugriff steuern, eingestellt wird. Diese Reduzierung kann wiederum die im Ticket benötigte Größe verringern. Weitere Informationen finden Sie unter Dynamic Access Control: Scenario Overview.

  • Wenn Sie Kerberos so konfiguriert haben, dass eine uneingeschränkte Delegierung verwendet wird, 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 an Windows ausgeliefert, die die Standardkonfiguration der uneingeschränkten Delegierung für Kerberos auf deaktiviert geändert haben. Weitere Informationen finden Sie unter Aktualisierungen zur TGT-Delegierung über eingehende Vertrauensstellungen in Windows Server.

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

Bekannte Probleme, die sich auf MaxTokenSize auswirken

Für MaxTokenSize die meisten Implementierungen sollte ein 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 insofern ähnlich, als ein Benutzer, der über zu viele Gruppenmitgliedschaften verfügt, sich nicht authentifizieren kann, aber die Berechnungen und Bedingungen, die für das Problem gelten, unterscheiden sich. Beispielsweise kann dieses Problem beim Verwenden der Kerberos-Authentifizierung oder der Windows NTLM-Authentifizierung auftreten. Weitere Informationen finden Sie unter Protokollierung für ein Benutzerkonto, das Mitglied von mehr als 1.010 Gruppen ist, kann auf einem Windows Server-basierten Computer fehlschlagen.

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

    Um einen Denial-of-Service-Angriffsvektor zu entschärfen, verwendet InternetInformation Server (IIS) eine begrenzte 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 also 64 KB beträgt, kann das Kerberos-Ticket 48.000 Bytes verwenden.

    Wenn Sie den Registrierungseintrag auf einen Wert festlegen, der MaxTokenSize größer als 48000 Bytes ist und der Pufferplatz 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 der Verwendung von Werten von MaxTokenSize 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-Administratoren Probleme haben, wenn die MaxTokenSize 100.000 Bytes oder größer sind.

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