Kerberos Ticketsize und Gruppen

Das Ticket, welches der Benutzer beim Zielsystem vorweist, enthält nun nicht nur den Benutzernamen, sondern auch alle Gruppenmitgliedschaften. Und die können bei größeren Umgebungen mit vielen Gruppen schon etwas umfangreicher sein. Windows reserviert aber feste Bereiche im Hauptspeicher (Default 16k) pro Token, um diese zu puffern. Das reicht in der Regel für ca.1020 Berechtigungsdaten. Die Benutzer-SID ist eine davon. Hinzu kommen Gruppenmitgliedschaften aber auch die SID-History. So kann diese Limit auch mal schnell erreicht werden. Wenn Sie also viele Gruppen haben, dann sollten Sie eine Erhöhung der Token-Größe auf allen Systemen vornehmen.

Beachten Sie dazu auch die Seite Token Limit/Token Bloat

16kB, 48kB, 64kB

Als Schutz gegen Überlast, Missbrauch und Angriffe werden Obergrenzen bei Datenstrukturen definiert. Ein Kerberos-Ticket darf dabei gewisse Größen nicht überschreiten.

  • 64 Kbytes
    Das ist die absolute Obergrenze für ein ein Kerberos Ticket laut RFC
  • 48kByte
    Seit Windows 2012 und höher ist dies der neue Default-Grenzwert für Kerberos Tickets. Sie können den Wert aber per Richtlinie auch auf 64kByte anheben.
  • 16 KByte
    Bis Windows 2008 hat Microsoft ein Limit von 16 kByte als Default vorgegeben, was manchmal dann doch zu knapp war

Die Ticketgröße betrifft dabei den KDC, welcher das Ticket ausstellt, den Client, der der Ticket speichert und an den Service weiterreicht und den Service, der das Ticket verarbeitet. 

Größe berechnen

Um zu wissen, ob die Ticketgröße ein Thema bei ihnen ist, brauchen wir etwas Mathematik um die Größe des Tokens nach einer einfachen Formel und die jeweilige Anzahl der Gruppen zu berechnen. Maßgeblich sind dabei nur Gruppen mit einer SID. Reine Verteilergruppen zählen nicht dazu aber eine SID-History müssen wir wieder addieren:

# Formel für Windows 2008 und früher
1200 für die Verwaltungsinformation
+ 40 * Anzahl der Mitgliedschaften in Domainlokalen Gruppen
+ 40 * Anzahl der Mitgliedschaften in universellen Gruppen anderer Domains 
+ 40 * Anzahl der SIDs in der SIDHistory
+  8 * Anzahl der Mitgliedschaften in globalen Security-Gruppen
+  8 * Anzahl der Mitgliedschaften in universellen Gruppen der eigenen Domain
=======================
Gesamtgröße des Tokens
# Formel für 2012 und neuer 
1200 für die Verwaltungsinformation
+  8 * Anzahl der Mitgliedschaften in Domainlokalen Gruppen
+ 40 * Anzahl der Mitgliedschaften in universellen Gruppen anderer Domains 
+ 40 * Anzahl der SIDs in der SIDHistory
+  8 * Anzahl der Mitgliedschaften in globalen Security-Gruppen
+  8 * Anzahl der Mitgliedschaften in universellen Gruppen der eigenen Domain
=======================
Gesamtgröße des Tokens

Ab Windows 2012 hat sich also die Größe der "Domain Local"-Group etwas reduziert. Das hilft bei Firmen, die Berechtigungen über zusätzliche lokale Gruppen vergeben. Zudem wurde die MaxTicketSize per Default auf 48.000 Bytes angehoben.

Machen wir mal ein paar Überschlagsrechnungen und nehmen dabei eine Mitgliedschaft in 1000 Gruppen mit SID als Basis. Die 1000 Gruppen haben eine besondere Bedeutung, wie Sie auf Token Limit/Token Bloat.

  • Single Domain 1000 Gruppen
    In dem Fall kostet jede Gruppe 8 Byte und damit 8kByte zzgl. 10kByte als Basis sind wir weit diesseits der 48kByte Grenze. Zu Zeiten von Windows 2008 und früher konnten wir aber schon die 16kByte-Grenze überschreiten. Seit der Anhebung auf 48 kByte gibt es hier aber kein Risiko mehr
  • MultiDomain mit 1000 Gruppen
    In einem Forest mit Ressourcen-Domains könnte ein Benutzer in 1000 Gruppen einer anderen Domain Mitglied sein. Dann sieht die Rechnung schon anders aus, denn 1000x40Byte + 10kByte = 50 kByte. Damit sind wir so grade über den 48kByte drüber, dass auch das Limit von 4800kByte nicht reicht.
    Aber auch der Fall ist dann schon sehr extrem.

Die neuen Default-Werte von Microsoft mit 48kByte für Kerberos-Tickets ist eigentlich ganz gut gewählt, wenn ihr Mitarbeiter in weniger als1000 Gruppen Mitglied sind und nicht alle aus fremden Domains kommen. Die 1000er Grenze hat weniger mit Kerberos zu tun, sondern betrifft den „Security Context“ bei der Anmeldung an Windows selbst.

Mitgliedschaften in reinen Verteilern sind nicht relevant, da hier keine SID vorhanden ist, die bei der Berechtigung berücksichtigt werden müsste. Beachten Sie dabei auch die beiden Seiten:

Windows Client und Server

Auf einem Windows System kann der für Kerberos Tickets reservierte Puffer über die Registrierung angepasst werden, z.B.: mit folgender REG-Datei.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\]
"MaxTokenSize"=dword:0000fffe

Erhöhen Sie den Buffer mit Bedacht, denn sehr große Tokens kosten Speicherplatz und nicht jede Anwendung kann sehr große Tokens verarbeiten.

Achtung: SQL und Sharepoint haben ein Problem mit Token-Größen über 64kByte. Sie sollten daher maximal "0xfffe" eintragen.

Die Einstellung können sie auch per Gruppenrichtlinie verteilen

  • 938118 How to use Group Policy to add the MaxTokenSize registry entry to multiple computers
  • 327825 New resolution für problems with Kerberos authentication when Users belong to many groups
  • 867581 You may receive an error message when you try to connect to an instance of SQL Server or SQL Server Desktop Engine by using Windows Authentication
  • 297869 SMS administrator issues after you modify the Kerberos MaxTokenSize registry value.
  • 920862 Error message when an Outlook Web Access User tries to access a mailbox in Exchange Server 2003: “HTTP 400 Bad Request (Request header too long)”
  • 269643 Internet Explorer Kerberos authentication does not work because of an insufficient buffer connecting to IIS
  • MaxTokenSize und seine Freunde
    http://blogs.technet.com/b/deds/archive/2010/06/01/maxtokensize-und-seine-freunde.aspx

IIS Webserver

Auch der IIS kann hier ein Problem darstellen, da das Token bei einer HTTP-Anfrage mit an den Webserver übertragen werden muss. Auch hier gibt es "Obergrenzen" für die Inhalte von Feldern und Anfragen

  • "MaxFieldLength" 16384 Bytes
    Die maximale Größe eines Felds in der HTTP-Anfrage
  • "MaxRequestBytes" 16384 Bytes
    Maximale Größe der Summe aller Felder.
  • MaxClientRequestBuffer
    IIS4: 2 MByte
    IIS5: 128k
    IIS5 mit Windows 2000 SP4: 16k

Werden diese Grenzen überschritten, dann protokolliert der IIS in den HTTPError-Logs (c:\Windows\System32\LogFiles\HTTPERR)

2009-05-20 22:32:07 10.1.1.1 4308 10.1.1.2 443 HTTP/1.1 POST /EWS/Exchange.asmx 400 - RequestLength -

Beim IIS3-5 ist dazu der Wert "HLKM\SYSTEM\CurrentControlSet\Services\w3svc\parameters\MaxClientRequestBuffer" anzupassen. Beim IIS6 sind es folgende zwei Werte der Registrierung, die ausschlaggebend sind: (Siehe auch KB820129 Http.sys registry settings für IIS)

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters]
"MaxFieldLength"=dword:0000fffe
"MaxRequestBytes"=dword:0007a120

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters\MaxClientRequestBuffer]
"MaxClientRequestBuffer"=dword:0000fffe

Hinweis:
Diese Einstellungen können auch ein Problem lösen, wenn Sie per Exchange PowerShell eine Verbindung per WinRM zu einem anderen Server aufbauen und dann z.B.: einen Fehler wie den folgenden bekommen:

 Enter-PSSession Enter-PSSession : Connecting to remote server failed with the following error message :
The WinRM client received an HTTP bad request status (400), but the remote service did not include 
any other information about the cause of the failure.
For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:1 + Enter-PSSession
CategoryInfo          : InvalidArgument: (:String) [Enter-PSSession], PSRemotingTransportException
     + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Hier noch ein paar Links dazu.

Apache

Auch Apache erlaubt die Authentifizierung per Kerberos und setzt hier ein Limit über die HTTP-Request Field Length, welche mit 8190 Bytes für größere Firmen ebenfalls zu klein ist. Hier hilft eine entsprechende Direktive in der Konfigurationsdatei, z.B.

LimitRequestFieldsize = 16384

Stellen Sie sicher, dass auch andere Systeme zwischen Client und Webserver (z.B. Proxy-Server, Firewalls etc.) nicht große Tickets als möglichen Angriff blockieren.

Samba

Auch ein Samba-Server, welcher das Active Directory nutzt, kann mit der Ticketgröße Probleme haben. In vielen Quellen steht zwar, dass die Buffergröße für eine SMB-Anfrage mit 65535 bzw. 65536 Bytes per Default ausreichend sein sollte, aber auch diversen installierten Samba-Servern war die Größe "nur" 16644 Bytes, wie man in einem NetMon-Mitschnitt sehr einfach sehen kann.

Interessanterweise betrifft so ein Limit nicht alle Versionen von Clients und Servern, wenn das ist nur die Maximalgröße für das SMB-Paket. Und ein Server und Client kann durchaus (siehe MaxRawSize) größere SMB-Pakete senden, wenn er diese denn entsprechend aufteilt. Der Server muss dann natürlich ein "More_Data" antworten. Und genau das sind so Feinheiten, die in Samba vielleicht (noch) nicht umgesetzt sind. Die Fragmentierung von Paketen ist weniger wahrscheinlich, wenn Sie den Wert über die "smb.conf" hoch genug wählen.

[global] 
    max xmit = 65535

Sollte dennoch ein Anwender, der z.B. in sehr viele Gruppen Mitglied ist, nicht arbeiten können, dann schauen Sie sich einfach mal per NETMON dessen Session-Aufbau und die Größe des Tickets an.

NetApp, Synology und Co

Nicht immer haben Sie einen Windows Server als SMB-Server. Es gibt NAS-Systeme von Netapp, Synology, QNAP etc. die ebenfalls "Domainmitglied" sein können. Auch wenn Sie im Hintergrund vielleicht auch nur "Samba" nutzen, bedeutet dies nicht, das Sie die Konfiguration einfach ändern können.

Windows 2012 hat zwar mittlerweile eine Standard-Ticketsize von 48000 Bytes, aber das bedeutet nicht, dass alle anderen Produkte sich schon darauf eingestellt haben.

Weitere Links