Microsoft Exchange für Kerberos-Authentisierung konfigurieren

Obschon das Kerberos-Authentisierungsprotokoll seit Windows 2000 verfügbar und sogar bevorzugt ist, wird es in Exchange-Installationen eher zufällig verwendet. In diesem Artikel möchte ich für die Verwendung plädieren und neben der Konfiguration auch Vor- und Nachteile erläutern sowie einige Tipps für das Troubleshooting geben. Fangen wir an.

Warum

Für die Verwendung von Kerberos sprechen mehrere Gründe. Erstens wird der Authentisierungsverkehr massgeblich verringert im Vergleich zu NTLMv2. In Umgebungen mit Windows 2008 R2 oder noch älteren Betriebssystemen als Domain Controllern existiert zudem ein ziemlicher Flaschenhals, da nur zwei gleichzeitige Legacy-Authentisierungen durchgeführt werden können. Der Registrierungsschlüssel MaxConcurrentApi (DWORD) unter HKLMSYSTEMCurrentControlSetServicesNetlogonParameters steuert diese Anzahl. Neuere Betriebssysteme verwenden als Default 10. Aber Achtung: Der Wert darf nicht beliebig erhöht werden, da dies zu anderen Problemen führen kann.

Zweitens hat Kerberos im Gegensatz zu NTLMv2 keine Abhängigkeit von einem bestimmten Computer-Account, sondern nur vom sogenannten Service Principal Name (SPN). Das ist der Name des Services, den der Client aufrufen möchte und für den er deshalb eine Authentisierung anfordert. Das Protokoll ist somit eigentlich besser geeignet für Systeme mit einem Loadbalancer. Allerdings kann ein SPN nur für einen Computer-Account im Active Directory Forest registriert werden. Das widerspricht meiner Aussage, dass keine Abhängigkeit besteht. Aber wir werden sehen, dass sie mit einem Trick ausgehebelt werden kann.

Wie funktioniert Kerberos?

Der Client – also z.b. Outlook – kontaktiert das Key Distribution Center (KDC) auf einem Domain Controller und fordert ein sogenanntes Ticket-Granting Ticket (TGT) an. Dafür muss sich der Benutzer authentisieren. Im TGT befindet sich eine Liste von SID des Benutzers und aller Gruppen, in denen er sich befindet. Mit Hilfe dieses TGT kann nun der Zugriff auf einen Dienst angefordert werden. Der Client schickt das TGT und den gewünschten SPN an den Ticket-Granting Service (TGS), der dann ein Service-Ticket ausstellt. Dieses beinhaltet neben der kopierten Liste von SIDs aus dem TGT auch einen mit dem Key des Zielservers verschlüsselten Inhalt, der diesem die Validierung des Tickets erlaubt. Dies ist nur ein kurzer Abriss der Funktionsweise, sollte aber genügen, um die Konfiguration zu verstehen.

Konfiguration von Exchange

Wie erwähnt, ist Kerberos von SPNs abhängig, die den Service identifizieren. Ein Computer kann zumindest seinen eigenen FQDN im Active Directory als SPN registrieren. Aber wenn weitere Namen definiert werden, wie z.B. internal- und external URL in Exchange, müssen diese Namen manuell hinzugefügt werden. Da in Umgebungen mit Loadbalancer mehrere Server den gleichen SPN benötigen, aber die Registrierung nur auf einem Computerkonto erlaubt ist, wird ein neuer Account erstellt, der keinem physischen Server entspricht. Dieser Account wird Alternate Service Account oder kurz ASA genannt. Der Name des Accounts spielt dabei keine Rolle.

Als Nächstes werden die SPNs konfiguriert. Dies kann in der Befehlszeile mit SETSPN.EXE geschehen oder in ADSIEDIT:

Im letzten Schritt muss nun allen Exchange-Servern mitgeteilt werden, dass für Kerberos der ASA verwendet werden soll. Dies ist nur mittels eines Skripts möglich, das im Installationsverzeichnis der Exchange Server liegt und RollAlternateServiceAccountPassword.ps1 heisst.

Die Konfiguration wird zunächst nur auf einen Server angewendet:

Danach wird sie auf alle anderen Server kopiert:

Das war’s!

Wie kann überprüft werden, dass Kerberos verwendet wird?

Die Validierung von Kerberos kann am einfachsten mit der Befehlszeile auf einem Client erfolgen. Der Befehl KLIST zeigt alle Kerberos-Tickets an. Falls für die registrierten SPN jeweils ein Ticket vorhanden ist und Outlook im Connection-Status-Fenster Nego* anzeigt, war die Konfiguration erfolgreich.

Ein paar Hinweise

• Kerberos funktioniert nur im internen Netz und nur für Domänen-integrierte Clients.
• Bei Migration von Exchange 2010 auf 2016 braucht jede Version ein separate ASA. Bei Migration von Exchange 2013 auf 2016 hingegen können sich einen teilen. Aber aufgepasst: Nicht vergessen, das Script für alle Server laufen zu lassen. Wenn Outlook für Kerberos konfiguriert ist und die SPNs existieren, gibt es kein Fallback auf NTLM. Sollte die Verbindung auf einen nicht konfigurierten Server treffen, ist das Resultat eine immer wiederkehrende Passwortabfrage.
• Das Passwort sollte mittels Script von Zeit zu Zeit geändert werden.

Fazit

Die Konfiguration des moderneren Authentisierungsverfahrens Kerberos ist nicht so kompliziert, wie es manchmal den Anschein macht. Und es lohnt sich allemal.