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.

Größe berechnen

Die Größe des Tokens lässt sich nach einer einfachen Formel und die jeweilige Anzahl der Gruppen berechnen, in der ein Benutzer Mitglied ist:

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 Securitygruppen
+  8 * Anzahl der Mitgliedschaften in Universellen Gruppen der eigenen Domain
=======================
Gesamtgröße des Tokens

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 ein Problem mit Token-Größen über 64kByte.
Sie sollten daher maximal "0xfffe" eintragen.

Die Einstellung können sie auch per Gruppenrichtlinie verteilen

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

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 for 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

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.

Weitere Links

Tags:Kerberos