Microsoft Exchange für Kerberos-Authentisierung konfigurieren
Exchange-Spezialist Markus Hengstler erläutert, weshalb du das Kerberos-Authentisierungsprotokoll einsetzen solltest und wie es konfiguriert wird.
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: Du darfst den Wert nicht beliebig erhöhen, 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 die Benutzerin oder der Benutzer authentisieren. Im TGT befindet sich eine Liste von SIDs der Benutzerinnen und Benutzer sowie aller Gruppen, in denen sie Mitglied sind. 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 konfigurierst du die SPNs. Das kannst du in der Befehlszeile mit SETSPN.EXE oder in ADSIEDIT:
Im letzten Schritt musst du nun allen Exchange-Servern mitteilen, dass für Kerberos der ASA verwendet werden soll. Das geht nur mittels eines Skripts, das im Installationsverzeichnis der Exchange Server liegt und RollAlternateServiceAccountPassword.ps1 heisst.
Die Konfiguration wird zunächst nur auf einen Server angewendet:
Danach kopierst du sie auf alle anderen Server:
Das war’s!
Wie kannst du überprüfen, dass Kerberos verwendet wird?
Die Validierung von Kerberos kannst du am einfachsten mit der Befehlszeile auf einem Client durchführen. Der Befehl KLIST zeigt alle Kerberos-Tickets an. Falls für die registrierten SPNs 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: Vergiss nicht, 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 solltest du mittels Script von Zeit zu Zeit ändern.
Fazit
Die Konfiguration des moderneren Authentisierungsverfahrens Kerberos ist nicht so kompliziert, wie es manchmal den Anschein macht. Und es lohnt sich allemal.
.