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

Best Practices im Access Management in Microsoft Umgebungen

Dieses Whitepaper enthält eine detaillierte Anleitung zur korrekten Einstellung von Berechtigungsstrukturen mit technischen Detailinformationen.

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.