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:

# 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 Securitygruppen
+  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 Securitygruppen
+  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.

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.

Weitere Links