MaxTokenSize Problem: Hintergrund des Fehlers

Die maximale TokengrรถรŸe legt fest, wie viele Eintrรคge bei der Kerberos-Authentifizierung รผbertragen werden kรถnnen. Ist ein Token zu groรŸ, werden Eintrรคge abgeschnitten und die entsprechenden Berechtigungen fehlen. Wie es zu dem Fehler kommt, erklรคrt das tenfold Glossar.

Ursache

Dieses Problem (auch โ€œToken Bloatโ€œ genannt) entstehet dann, wenn das Kerberos-Ticket des Clients (erzeugt bei der Kerberos-Authentifizierung im Rahmen der Anmeldung an Windows) zu groรŸ ist. Genauer gesagt kommt es zu dieser Problematik dann, wenn die maximale GrรถรŸe des PAC (Privilege Account Certificate; es handelt sich dabei um eine Erweiterung des โ€žAuthorization Dataโ€œ Feldes in Kerberos) รผberschritten wird.

Hier werden von Windows Informationen zu Security Identifiers (siehe auch: SID) und Gruppenmitgliedschaften des Benutzers hinterlegt. Jede Gruppe benรถtigt zur Speicherung entweder 8 Byte oder 40 Byte Speicher im PAC.

Achtung: Berรผcksichtigt werden muss, dass Gruppen, die verschachtelt sind, aufgelรถst werden. Ist also der Benutzer Mitglied in Gruppe A, und diese Gruppe ist Mitglied in B, so werden sowohl Informationen zu Gruppe A als auch B im PAC hinterlegt.

Auswirkungen

Die Auswirkung einer รœberschreitung fรผhrt dazu, dass nicht alle Gruppen in der PAC abgebildet werden kรถnnen und daher fehlen. Die Effekte kรถnnen sich an mehreren Orten bemerkbar machen:

  • Dateizugriffe funktionieren nicht, obwohl Berechtigungen vorhanden sind
  • Single Sign On an Web-Applikationen funktioniert nicht wie gewohnt
  • Gruppenrichtlinien fรผr den Benutzer werden nicht angewendet

Zusammensetzung und Berechnung

Die maximale Token Size ist abhรคngig vom genutzten Betriebssystem:

  • Windows 2000: 8.000 Byte
  • Windows Server 2003 und hรถher: 12.000 Byte
  • Windows Server 2012 und hรถher: 48.000 Byte

Die Token Size fรผr einen Benutzer ist abhรคngig von der Anzahl der Gruppenmitgliedschaften (und der jeweiligen Gruppentypen) des Benutzers und lรคsst sich grob wie folgt berechnen: Size = 1500 + (40 * a) + (8 * b)

  • 1500 Byte betrรคgt der geschรคtzte Overhead und hรคngt von Faktoren wie dem DNS-Namen der Domรคne ab.
  • a โ€“ entspricht der Anzahl der Eintrรคge in der SID History (fรผr Benutzer und Gruppen) als auch die Anzahl der aufgelรถsten Mitgliedschaften in universellen Gruppen, welche auรŸerhalb der Domรคne des Benutzers liegen.
  • b โ€“ entspricht der Anzahl der aufgelรถsten Mitgliedschaften in universellen Gruppen, welche innerhalb der Domรคne des Benutzers liegen, sowie aufgelรถste Mitgliedschaften in globalen und domรคnenlokalen Gruppen.

Achtung: Bei Windows Server 2008 R2 oder frรผher werden domรคnenlokale Gruppen mit 40 Byte statt mit 8 Byte berechnet.

Achtung: Bei Windows Server 2008 R2 oder frรผher werden domรคnenlokale Gruppen mit 40 Byte statt mit 8 Byte berechnet.

  • Wenn fรผr den Benutzer die Option โ€žTrusted for Delegationโ€œ aktiviert ist, muss fรผr alle Angaben auรŸer dem Overhead der doppelte Bedarf gerechnet werden.
  • Die benรถtigte GrรถรŸe kann in Windows Server 2012 und spรคter reduziert werden, wenn die Funktion โ€žKDC Resource SID Compressionโ€œ genutzt wird. Diese komprimiert die SIDs im PAC und erlaubt so die Speicherung von mehr Eintrรคgen.

Weitere Hindernisse

Grundsรคtzlich ist die ร„nderung der maximalen Token Size รผber die Registry mรถglich. Das ergibt jedoch bei einer Token Size von 48 KByte (das ist die aktuelle Default-Einstellung) keinen Sinn, denn dies erlaubt die Speicherung von mehr als 1.015 Gruppen (unter der Annahme, dass nicht lediglich domรคnenfremde, universelle Gruppen zum Einsatz kommen).

Der Grund dafรผr ist, dass ein Security Principal (also ein Computer, eine Gruppe oder ein Benutzer) Mitglied von maximal 1.015 Gruppen sein kann. Es handelt sich dabei um ein internes Limit von Windows Server, welches unabhรคngig von der Kerberos Token Size ist. Eine VergrรถรŸerung der Token Size, um mehr als 1.015 Gruppen unterzubringen, ist daher nicht zweckmรครŸig, da man anschlieรŸend am absoluten Gruppenlimit scheitert.

Whitepaper

Access Governance: Best Pratices fรผr Microsoft-Umgebungen

Ein umfassender Leitfaden zur Umsetzung bewรคhrter Best Practices fรผr die Zugriffsverwaltung in Microsoft-Umgebungen.

Verfasst von: Helmut Semmelmayer

Helmut Semmelmayer ist seit 2012 als VP Revenue Operations beim Software-Hersteller tenfold tรคtig. Er ist damit fรผr den Partnervertrieb und das Produktmarketing verantwortlich und schreibt in diesem Blog regelmรครŸig themenbezogene Beitrรคge aus dem Bereich Identity & Access Management.