Bei der Migration von Exchange 2010 / 2013 zu Exchange 2016 kann es zu Problemen mit Autodiscover in Verbindung mit Kerberos kommen. Die Probleme äußern von permanenten Abfragen der Anmeldeinformationen in Outlook bis zum kompletten Absturz von Outlook wenn ein Postfach auf einen Exchange 2016 Server verschoben wurde.
Wann kann das Problem auftreten?
Das Problem kann auftreten wenn die Exchange Server für die Kerberos Authentifizierung konfiguriert wurden (RollAlternateserviceAccountCredential.ps1) und die AD-Konten der Benutzer Mitglied von vielen Gruppen sind. “Viele Gruppen” ist dabei relativ, schon um die 100 Gruppen sind problematisch.
Wie äußert sich das Problem?
Postfächer die noch nicht zu Exchange 2016 migriert wurden, fragen unter Umständen permanent nach den Anmeldeinformationen:
Der Autodiscover Test schlägt fehl und meldet den http-Statuscode 400, sowie einige andere Fehlercodes (Der Fehlercode 400 geht aus dem Screenshot nicht hervor, würde aber direkt nach dem Statuscode 401 angezeigt werden, leider habe ich keine Screenshots in denen es ersichtlich wird):
Wenn Postfächer von den alten Exchange Servern zu Exchange 2016 verschoben werden stürzt Outlook nach einem Neustart ab:
Das Abstürzen von Outlook konnte mit den Outlook Versionen 2010, 2013 und 2016 nachgestellt werden.
Ursache und Lösung
Da Exchange 2016 als Proxy für die älteren Exchange Versionen fungiert, wird auch das Kerberos Token im HTTP-Header weitergereicht. Hierbei kann es vorkommen, dass bei großen Kerberos Token und somit großen HTTP-Headern, die Exchange 2010 Server die HTTP-Anfrage ablehnen und den folgenden Fehler liefern:
- HTTP 400 – Bad Request (Request header too long)
Um das Problem zu beheben, kann könne die Limits entsprechend angepasst werden. Auf allen Exchange 2010 und Exchange 2013 Servern müssen dazu, die folgenden 4 Registry Schlüssel gesetzt werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters Name: MaxTokenSize Typ: REG_DWORD (32Bit) Wert: 65536 Basis: Dezimal HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters Name: MaxClientRequestBuffer Typ: REG_DWORD (32Bit) Wert: 32768 Basis: Dezimal HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters Name: MaxFieldLength Typ: REG_DWORD (32Bit) Wert: 65536 Basis: Dezimal HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters Name: MaxRequestBytes Typ: REG_DWORD (32Bit) Daten: 16777216 Wert: Dezimal
Auf allen Domain Controllern muss der folgende Registry Schlüssel gesetzt werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters Name: MaxTokenSize Typ: REG_DWORD (32Bit) Value data: 65536 Basis: Decimal
Die Exchange Server und Domain Controller müssen nach dem Setzen der Registry Schlüssel neu gestartet werden.
Nachtrag: Ab Windows Server 2012 / Windows 10 ist die MaxTokenSize per Default bei 48KB!
Wir hatten das Problem mit zu großer Kerberos TokenSize schon öfter (Windows Server 2008/R2 und Windows XP/7 haben als Standard nur 12KB!) und haben die Werte natürlich auch auf den 2010er Exchange Servern höher gedreht auf 48KB, sowie auf allen anderen Clients und Servern per GPO. Höher sollte man es laut Microsoft (entgegen Eurer Empfehlung auf 64KB) nicht setzen:
https://support.microsoft.com/en-us/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou
Genau da bin ich reingelaufen!
Ich hatte aber keine Kerberos-Authentifizierung bewusst aktiviert!
Die Einstellung ist generell unschädlich, von mehr Speicherverbrauch mal abgesehen.
Zumindest soweit ich das gelesen hatte.
Das Problem trat nur bei Exchange-2010-Konten auf (wegen des Proxy).
Die 2016er gingen alle.
Hallo Frank,
das ist ja wieder einmal ein Artikel der ans Eingemachte geht. Vielen Dank und hoffentlich brauche ich den nie.
Der Arme, der hier das Troubleshooting betreiben musste.
Hallo Frank,
Ist diese Korrektur allgemein empfehlenswert oder birgt Sie auch Risiken?
Vielen Dank,
Gruß Christoph.