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 HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ 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.

ms exchange kerberos

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

ms exchange kerberos

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:

ms exchange kerberos

Danach wird sie auf alle anderen Server kopiert:

ms exchange kerberos

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.

ms exchange kerberos

 

ms exchange kerberos

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.

Microsoft Exchange 2016

Für mehr Informationen zur Sicherheit in Exchange 2016 und der Konfiguration der in diesem Artikel erwähnten Features besuchen Sie einen der folgenden Kurse:

Für mehr Informationen zur Sicherheit in Exchange 2016 und der Konfiguration der in diesem Artikel erwähnten Features besuchen Sie einen der folgenden Kurse:

 

Markus Hengstler

Markus Hengstler arbeitet bei der UMB AG als Senior Systems Engineer in den Bereichen Exchange, Windows und Citrix. Dank seiner Erfahrungen in diesen Bereichen ist er zertifizierter «MCSE: Server Infrastructure». Ausserdem ist er einer von drei «MCSM: Messaging» in der Schweiz. Seit 2001 unterrichtet er als Microsoft Certified Trainer und seit 2010 als Citrix Certified Instructor bei Digicomp.

Diesen Artikel kommentieren

Wir sind sehr an einer offenen Diskussion interessiert, behalten uns aber vor, beleidigende Kommentare sowie solche, die offensichtlich zwecks Suchmaschinenoptimierung abgegeben werden, zu editieren oder zu löschen. Mehr dazu in unseren Kommentarregeln.