Exchange Migration: Probleme mit Autodiscover (HTTP 400) und Kerberos

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:

Exchange Migration: Probleme mit Autodiscover (HTTP 400) und Kerberos

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):

Exchange Migration: Probleme mit Autodiscover (HTTP 400) und Kerberos

Wenn Postfächer von den alten Exchange Servern zu Exchange 2016 verschoben werden stürzt Outlook nach einem Neustart ab:

Exchange Migration: Probleme mit Autodiscover (HTTP 400) und Kerberos

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.

5 Gedanken zu „Exchange Migration: Probleme mit Autodiscover (HTTP 400) und Kerberos“

  1. 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

    Antworten
  2. 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.

    Antworten
  3. 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.

    Antworten

Schreibe einen Kommentar