Kerberos Token Aufblaehung MaxTokenSize: Gruppen sicher bereinigen

Was ist Kerberos-Token-Aufblähung?

Die Fehlersuche bei Kerberos-Token-Aufblähung und MaxTokenSize beginnt mit einer Unterscheidung: Die Anzahl der Personen in einer Gruppe ist etwas anderes als die Anzahl der Gruppen-SIDs, die für eine Person mitgeführt werden. Unkontrolliertes Gruppenwachstum kann die Verfügbarkeit der Authentifizierung beeinträchtigen, doch ein Befund zu einer großen Gruppe allein liefert noch keine Diagnose. Eine sinnvolle Untersuchung verbindet die betroffene Identität, den ausfallenden Dienst, den Autorisierungskontext und die Grenzen entlang des Authentifizierungspfads dieses Dienstes.

Eine Bereinigung unter Zeitdruck schafft ein zweites Problem. Wer Mitgliedschaften entfernt, bis eine Anwendung wieder funktioniert, verändert Zugriffe, ohne festzustellen, welche Berechtigungen oder Einschränkungen entfernt wurden. Manche Entfernungen reduzieren unnötige Privilegien; andere unterbrechen erforderliche Arbeitsabläufe. Eine Entfernung kann auch eine Kontrolle schwächen, wenn die Mitgliedschaft eine Einschränkung bewirkte. Das Sicherheitsergebnis hängt von der tatsächlichen Rolle der Gruppe ab, nicht davon, ob die Mitgliederliste kürzer geworden ist.

Dieser Leitfaden behandelt zirkuläre Verschachtelungen und veränderte integrierte Gruppen als Prüfsignale im Rahmen dieser Untersuchung. Er beschreibt weder einen beobachteten Ausfall noch einen gemessenen Sicherheitsvorfall. Ziel ist eine Behebung, die den betroffenen Arbeitsablauf wiederherstellt und dabei genehmigte Zugriffe und genehmigte Zugriffsverweigerungen erhält.

Funktionsweise: PAC, MaxTokenSize und getrennte Grenzen

Das Kerberos-TGT enthält Autorisierungsdaten in seinem Privilege Attribute Certificate (PAC): Benutzer-, Gruppen- und sIDHistory-SIDs. Claims und SID-Komprimierung beeinflussen ebenfalls den Platzbedarf. Entscheidend ist die daraus entstehende Bytezahl; die Anzahl direkter Mitglieder ist eine andere Messgröße. Microsoft KB327825 erklärt diesen Mechanismus.

KB837361 dokumentiert die Registrierungseinstellung MaxTokenSize:

Der Abschnitt zu bekannten Problemen in KB327825 nennt gesondert eine LSA-Zugriffstoken-Grenze von 1.010 Gruppen-SIDs, die Kerberos oder NTLM betrifft. Eine Erhöhung von MaxTokenSize hebt diese separate Grenze nicht auf. KB327825, bekannte Probleme.

KB938118 nennt 65.535 Bytes als maximal zulässigen Wert, rät aber von Werten über 48.000 ab, weil die HTTP-Base64-Kodierung Authentifizierungsdaten vergrößert. Behandeln Sie den zulässigen Höchstwert und eine geeignete Betriebseinstellung als getrennte Entscheidungen. Das Erhöhen eines Registrierungswerts kann nicht jede nachgelagerte Beschränkung beseitigen.

Zirkuläre Verschachtelung ist ein Graphproblem

Angenommen, Gruppe A enthält Gruppe B und Gruppe B enthält Gruppe A. Eine eigene Traversierung, die Knoten erneut besucht, ohne sie nachzuverfolgen, kann in einer Schleife bleiben oder wiederholte Besuche zählen. Das ist eine algorithmische Folge, keine Aussage über beobachtetes Verhalten von KDC oder PowerShell. Eine Rückkehr zur selben Gruppe erzeugt nicht bei jedem Besuch eine neue eindeutige SID.

Bewahren Sie bei der Untersuchung eines Zyklus die direkten Gruppenkanten auf. Eine stark zusammenhängende Komponente (SCC) identifiziert eine Menge von Gruppen, die einander erreichen können; die Topologie hilft dem Prüfer, die zu entfernende Beziehung auszuwählen. Ein Zyklusbefund belegt nicht, dass das PAC eines Benutzers MaxTokenSize überschreitet. Der Zyklus und übermäßige effektive Mitgliedschaften können gleichzeitig vorliegen, benötigen aber getrennte Nachweise.

Gefährliche Gruppenverschachtelung in Active Directory erklärt, wie verborgene Vererbung einen Pfad zu Tier 0 schafft und warum bei der Behebung die Gruppenkante identifiziert werden muss, die dieses Privileg gewährt. Wenden Sie diese Pfadprüfung beim Vereinfachen von Mitgliedschaften an, damit eine Verfügbarkeitsreparatur auch die vorgesehene Privilegiengrenze erhält.

Symptome je Dienst und das Szenario einer Notfalländerung

Microsoft dokumentiert HTTP 400 bei einem übergroßen Anforderungsheader, fehlgeschlagene Ressourcenzugriffe und Probleme beim Aktualisieren der Benutzergruppenrichtlinie. Das Beispiel mit Client, IIS und SQL zeigt, dass die beteiligten Rechner für die Diagnose relevant sind. KB327825, Symptome und Lösung.

Nutzen Sie die folgende Tabelle als Untersuchungsplan. Es sind zu prüfende Fragen, keine zusätzlichen Fehlersignaturen und keine Belege dafür, dass Kerberos zufällig ausfällt.

Wenn derselbe Benutzer bei einem Dienst erfolgreich ist und bei einem anderen scheitert, halten Sie beide Fälle fest. Vergleichen Sie ihre tatsächlichen Pfade, bevor Sie Gruppen ändern. Der erfolgreiche Fall ist ein nützlicher diagnostischer Nachweis, identifiziert jedoch nicht die Grenze, die im fehlgeschlagenen Fall gilt. Ersetzen Sie diesen Vergleich nicht durch eine pauschale Behauptung einer sporadischen Token-Aufblähung.

Wie das Entfernen einer Gruppe eine Einschränkung entfernen kann

Betrachten Sie ein bedingtes Beispiel auf einem Windows-10/11-Arbeitsplatzrechner, der von Microsofts Dokumentation zu „Deny access to this computer from the network“ abgedeckt wird. Eine dedizierte Sicherheitsgruppe trägt SeDenyNetworkLogonRight. Die Einstellung befindet sich unter Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Microsoft dokumentiert, dass dieses Deny Vorrang vor dem entsprechenden Allow für Netzwerkzugriff hat und dass Zuweisungsänderungen bei der nächsten Anmeldung gelten.

Angenommen, ein Administrator entfernt den Benutzer aus dieser Gruppe ausschließlich, um Mitgliedschaften zu reduzieren. War dies der einzige Pfad des Benutzers zu Deny und bleibt ein Allow bestehen, verliert der nächste Autorisierungskontext diese Einschränkung. Das ist eine bedingte Schlussfolgerung aus dem dokumentierten Richtlinienverhalten, kein Vorfallsbericht. Sie beweist nicht, dass nun jede Freigabe oder Datei zugänglich ist: Andere ACLs und Verweigerungen müssen weiterhin geprüft werden. Prüfen Sie die Anwendbarkeit, bevor Sie dieses Arbeitsplatzbeispiel auf andere Systeme übertragen.

Microsofts Dokumentation zu Sicherheitsgruppen erklärt, dass Gruppen sowohl Benutzerrechte als auch Ressourcenberechtigungen tragen können. Erfassen Sie beide Rollen, bevor Sie eine Kante oder ein Mitglied entfernen. Ein Gruppenname allein reicht nicht aus, um zu entscheiden, ob eine Entfernung Privilegien reduziert, erforderlichen Zugriff unterbricht oder eine Einschränkung entfernt.

Drift bei privilegiertem Zugriff in Active Directory erklärt, wie temporäre Ausnahmen ohne Verantwortliche, Ablaufdatum und erneute Validierung Rechte über Gruppen und ACLs wiederherstellen können. Wenden Sie dieselbe Disziplin hinsichtlich des Sollzustands bei dringenden Reparaturen an, insbesondere wenn ein fehlgeschlagener Arbeitsablauf zu einer kompensierenden Zugriffsgewährung führt.

Erkennung: Mitgliedschaften, Pfade und Warnkontext erfassen

Schritt 1: Für jeden betroffenen Dienst einen Datensatz anlegen

Erfassen Sie den Benutzer, Client- und Serverversionen, Dienst/SPN, den wirksamen MaxTokenSize-Wert jedes Teilnehmers, die Gruppen-/SID-Population, sIDHistory, Claims oder Delegationskontext, den exakten Fehler und relevante Warnungen. Sichern Sie die Nachweise vor Änderungen. Unterscheiden Sie einen beobachteten Fehler von einer Schätzung, einem Befund zum Verzeichniszustand und einem erfolgreichen Wiederholungstest.

Ereignis-ID 31 kann unter Windows Server 2012 und später vor einer konfigurierten Schwelle für große Tickets warnen. Aktivieren Sie dies über Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets. Sie ist kein Beweis dafür, dass MaxTokenSize überschritten wurde; korrelieren Sie sie mit dem ausfallenden Dienst. KB327825, Lösung.

Erfassen Sie die tatsächliche Warnschwelle und ob diese Richtlinie aktiviert ist. Die Quellenpassage nennt keinen universellen numerischen Schwellenwert. Das Ausbleiben der Warnung ist kein Entlastungsnachweis für das Konto.

Schritt 2: Gruppen des Sicherheitsprinzipals inventarisieren

Der folgende Befehl stammt aus Beispiel 2 von Get-ADPrincipalGroupMembership und wird als dokumentierter Befehl wiedergegeben. Diese Befehle wurden für diesen Artikel nicht in einer AD-Umgebung ausgeführt; ersetzen Sie die Beispielidentität durch ein aufgelöstes Konto in Ihrem Zuständigkeitsbereich.

Get-ADPrincipalGroupMembership -Identity Administrator

Das Cmdlet benötigt einen globalen Katalog. Microsoft dokumentiert ResourceContextServer zum Suchen lokaler Gruppen in einer anderen Domäne. Prüfen Sie den Ressourcenkontext, statt anzunehmen, die eigene Domäne des Kontos bilde den gesamten Dienstablauf ab. Die zurückgegebenen Gruppenobjekte dienen der Inventarisierung; sie messen keine Ticketbytes.

Schritt 3: Direkte Kanten vor dem Abflachen der Ergebnisse erhalten

Diese Abfrage direkter Mitgliedschaften verwendet die dokumentierten Parameter von Get-ADGroupMember:

Get-ADGroupMember -Identity "Enterprise Admins"

Zum Vergleich enthält Microsofts Beispiel 4 Mitglieder, die über untergeordnete Gruppen erreicht werden:

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive

Microsoft beschreibt die rekursive Ausgabe als Endmitglieder der Hierarchie. Bewahren Sie direkte Beziehungen gesondert auf, um einen Pfad oder Zyklus zu erklären. Eine abgeflachte Ausgabe kann allein nicht erklären, welche Beziehung ein Recht vermittelt. Die Dokumentation nennt außerdem eine Einschränkung für Mitglieder in einer anderen Gesamtstruktur ohne Active Directory Web Service.

Für eine gezielte Sicht auf transitive SIDs dokumentiert Microsoft das berechnete tokenGroups (Token-Groups-Attribut), das durch eine LDAP-Abfrage mit BASE-Suchbereich am Sicherheitsprinzipal bei verfügbarem globalem Katalog abgerufen wird. Das ist für Domänencontroller aufwendig. Beginnen Sie bei betroffenen Konten statt mit breit angelegten wiederholten Abfragen. Die SID-Population liefert nützliche Nachweise, ist jedoch weiterhin kein PAC-Bytezähler.

Behebung: Gruppen vereinfachen und genehmigte Kontrollen erhalten (Remediation)

Schritt 1: Sollzustand und Rücknahme festlegen

Sichern Sie direkte Mitgliedschaften, Gruppenkanten und die transitive Population der betroffenen Konten. Erfassen Sie Gruppenverantwortliche, Ressourcennutzung, Benutzerrechte, genehmigte Einschränkungen, Puffereinstellungen und betroffene Anwendungen. Dokumentieren Sie die geplante Änderung und eine Rücknahme, bevor Sie Mitgliedschaften entfernen. Die vorherigen Befehle mit reinem Lesezugriff unterstützen diese Inventarisierung; sie autorisieren keine Löschung.

Prüfen Sie integrierte Gruppen gegen einen gepflegten organisatorischen Sollzustand. Microsoft dokumentiert legitime Funktionen für Gruppen wie Event Log Readers, auch wenn ihre Standardmitgliedschaft leer ist. Ein neues Mitglied kann beabsichtigt sein. Prüfen Sie ohne gepflegten Sollzustand die Begründung des Verantwortlichen, statt die Aufnahme selbst als bösartig zu behandeln.

Schritt 2: Unnötige Abhängigkeiten entfernen und fehlerhafte Zyklen aufbrechen

Identifizieren Sie die genaue Kante, die einen Zyklus oder eine veraltete Abhängigkeit erzeugt. Bestätigen Sie ihre Nutzung mit dem Verantwortlichen, entfernen Sie nur die genehmigte Beziehung und erhalten Sie erforderliche Berechtigungen und Verweigerungen. Abflachen bedeutet, die Gruppenarchitektur zu vereinfachen; es bedeutet nicht, jeden Benutzer direkt in jede Ressourcen-ACL einzutragen.

Trennen Sie Geschäftsrollen von Ressourcengruppen und geben Sie beiden Verantwortliche und Prüftermine. Prüfen Sie, ob der neue Entwurf tatsächlich unnötige effektive Mitgliedschaften reduziert. Eine Neuordnung von Gruppennamen oder Verschachtelungen ohne Verringerung der relevanten SID-Population belegt nicht, dass der Authentifizierungskontext kleiner geworden ist.

Schritt 3: MaxTokenSize als begrenzte Übergangslösung nutzen

Wenn die Untersuchung eine Puffergrenze nachweist, erwägen Sie eine kontrollierte Konfigurationsänderung neben der strukturellen Bereinigung. KB938118 dokumentiert die Richtlinie unter Computer Configuration\Policies\Administrative Templates\System\Kerberos mit dem Namen Set maximum Kerberos SSPI context token buffer size. Vorgesehen sind das Aktivieren der Richtlinie und die Eingabe von 48000. Wählen Sie für das Verfahren mit Registrierungseinstellungen REG_DWORD und eine dezimale Eingabe.

Vergleichen Sie diesen Wert zuerst mit der wirksamen Konfiguration. Das Setzen von 48.000 auf einem Rechner, der bereits 48.000 verwendet, erhöht die Kapazität nicht. Befolgen Sie nach Anwendung die dokumentierten Neustartanforderungen, halten Sie eine Rücknahme bereit und prüfen Sie HTTP-Beschränkungen. Behandeln Sie 65.535 nicht als Standardempfehlung und nehmen Sie nicht an, dass allein eine Änderung am Domänencontroller einen Pfad mit mehreren Teilnehmern repariert.

Schritt 4: Erforderliche Zugriffe und erforderliche Verweigerungen testen

Verbinden Sie Pilotkonten erneut und testen Sie jeden betroffenen Dienst nochmals. Prüfen Sie die genehmigten Geschäftsaktionen, die zu erhaltenden Einschränkungen und kompensierende Berechtigungen, die während des Ausfalls gewährt wurden. Vergleichen Sie Mitgliedschaften und direkte Kanten vor und nach der Änderung. Beobachten Sie den tatsächlichen Fehler und den Warnkontext erneut.

Ein behobener Größen- oder Zyklusbefund liefert nützliche Nachweise zum Zustand, ist aber kein vollständiger Dienstabnahmetest. Schließen Sie die Reparatur ab, wenn sowohl der betroffene Arbeitsablauf als auch das Zugriffsmodell dem dokumentierten Ziel entsprechen. Bewahren Sie Ausnahmen mit Verantwortlichen und Prüfterminen auf, damit spätere Änderungen gegen denselben Sollzustand geprüft werden können.

Wie EtcSec dies erkennt

EtcSecs etc-collector bietet sechs relevante Prüfungen des Verzeichniszustands. Ihre exakten Bedingungen sind unten aufgeführt. Die vier Größenprüfungen zählen direkte Mitglieder, nicht die Tokengröße. Keine der sechs Prüfungen zählt die transitiven Gruppen-SIDs eines Benutzers, misst PAC-Bytes, liest MaxTokenSize oder weist einen Authentifizierungsfehler nach.

Das Suffix CRITICAL entspricht dem tatsächlichen Schweregrad High, und HIGH entspricht dem tatsächlichen Schweregrad Medium. Diese Schwellen für direkte Mitglieder sind Collector-Richtlinien, keine Authentifizierungsgrenzen von Microsoft. Die Größenbedingungen enthalten keinen expliziten Filter für Sicherheitsgruppen gegenüber Verteilergruppen.

Ihre Populationen überschneiden sich: GROUP_EXCESSIVE_MEMBERS umfasst sowohl 101–500 als auch >500 Mitglieder; OVERSIZED_GROUP_HIGH ist eine Teilmenge von OVERSIZED_GROUP. Addieren Sie ihre Anzahlen nicht als unterschiedliche Gruppen und beschreiben Sie sie nicht als vier unabhängig nachgewiesene Risiken einer Token-Aufblähung. Die Anzeige nur der fünf größten Gruppen in den Details übermäßiger Mitglieder begrenzt nicht die Gesamtzahl der Befunde.

Die Prüfung zirkulärer Verschachtelung zählt beteiligte Gruppen, nicht Zyklen oder gescheiterte Benutzer. Ihr Graph enthält nur bekannte erfasste Gruppen und normalisiert Distinguished Names. Ein Zyklus durch eine nicht erfasste Domäne kann übersehen werden. Das Ergebnis zeigt zu prüfende Beziehungen, nicht die Ursache eines Kerberos-Fehlers.

Was der Sollzustand integrierter Gruppen tatsächlich bedeutet

BUILTIN_MODIFIED verwendet exakte englische sAMAccountName-Abfragen. Seine nicht leeren Listen akzeptieren Administrator, Domain Admins und Enterprise Admins für Administrators; Domain Users, Authenticated Users und INTERACTIVE für Users; sowie Guest und Domain Guests für Guests.

Seine neun leeren Listen umfassen Remote Desktop Users, Network Configuration Operators, Performance Monitor Users, Performance Log Users, Distributed COM Users, IIS_IUSRS, Cryptographic Operators, Event Log Readers und Certificate Service DCOM Access. Ein extrahierter CN in einer dieser Gruppen kann auslösen, selbst wenn die Aufnahme legitime Arbeit unterstützt.

Der Vergleich akzeptiert eine Gleichheit ohne Beachtung der Groß-/Kleinschreibung oder eine Teilzeichenfolgenübereinstimmung mit einem erwarteten Namen. Er überspringt Mitglieds-DNs ohne extrahierten CN und verifiziert weder die SID noch den Container der Gruppe. Lokalisierte Namen, Umbenennungen, gleichnamige Gruppen und CNs, die einen erwarteten Namen enthalten, begrenzen die Interpretation. Die Prüfung erkennt keine fehlenden erwarteten Mitglieder, untersucht keine ACL-Änderungen und vergleicht nicht die Änderungshistorie einer Organisation.

Nutzen Sie diesen Befund, um einen Verantwortlichen, eine Begründung und einen Vergleich mit dem lokalen Sollzustand anzufordern. Die richtige Reaktion ist eine geprüfte Mitgliedschaftsentscheidung, keine automatische Bereinigung. Verbinden Sie alle sechs Befunde mit den zuvor erhobenen Dienstnachweisen, um zu entscheiden, was geändert und wie dies validiert werden soll.