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.
Access Governance: Best Pratices fรผr Microsoft-Umgebungen
Ein umfassender Leitfaden zur Umsetzung bewรคhrter Best Practices fรผr die Zugriffsverwaltung in Microsoft-Umgebungen.