Exchange 2013: Authentifizierung auf Kerberos umstellen

In der Standardeinstellung werden Verbindungen von Outlook zu Exchange 2013 mit NTLM authentifiziert. In Umgebungen mit mehreren CAS-Servern und vielen Clients erzeugt NTLM allerdings unnötig Last auf den DCs, gerade weil Loadbalancer sich nicht mehr um Persistenz kümmern müssen. Hier sollte die Authentifizierung besser mit Kerberos erfolgen, damit nicht jeder CAS-Server die Verbindung neu authentifizieren muss. In diesem Howto wird die Authentifizierung auf Kerberos mit Fallback auf NTLM umgestellt. Meine Testumgebung enthält aktuell nur einen Exchange 2013 Server in der Standard Konfiguration.

Im ersten Screenshot sieht man das Verbindungen via NTLM authentifiziert werden und Outlook aktuell den FQDN (ex1.frankysweb.local) als Proxyserver nutzt:

Zunächst sollte also ein allgemeiner Zugriffspunkt für Outlook definiert werden. Dazu lege ich den Host-A Record „outlook.frankysweb.local“ an und gebe als IP-Adresse die IP meines Exchange Servers an. Wenn mehrere CAS-Sever zum Einsatz kommen, kann dieser Eintrag entweder mit mehrfach mit den jeweiligen IPs der Exchange CAS Server angelegt werden (DNS Round Robin), oder wenn ein Loadbalancer genutzt wird, die IP des Loadbalancers eingetragen werden

Sobald der DNS Eintrag erstellt wurde und von den Clients aufgelöst werden kann, können die Exchange Webservices auf den neuen Namen konfiguriert werden:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/owa“
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/ecp“
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/EWS/exchange.asmx“
Get-OabVirtualDirectory | Set-OabVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/OAB“
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/Microsoft-Server-ActiveSync“
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname outlook.frankysweb.local -InternalClientsRequireSsl:$true

Autodiscover verteilt die neuen Einstellungen nach einiger Zeit automatisch an die Clients (siehe weiter unten, Event 3025), sodass Outlook nun über „outlook.frankysweb.local“ auf Exchange zugreift. Dieser DNS-Name muss natürlich auch auf dem Zertifikat vorhanden sein, damit es nicht zu Warnungen kommt.

Um Keberos als Authentifizierungsmethode nutzen zu können, ist ein Computer Konto erforderlich. Daher erstelle ich ein neues Computer Konto im Active Directory mit dem Namen „CASASA“ in der OU „Microsoft Exchange Security Groups“. Mit welchem Namen oder in welcher OU das Konto erstellt wird, spielt keine Rolle, Hauptsache es wird nicht gelöscht oder verändert.

Damit das neue Computer Konto genutzt werden kann, braucht das Konto ein Passwort. Aktuell verfügt das Konto über kein Passwort, da kein Computer mit dem Namen CASASA dem Active Directory beigetreten ist. Um ein Passwort für das Computer Konto zu vergeben, wird der „DistinguishedName“ des Kontos benötigt:

Die folgenden Zeilen VBS-Code können dazu benutzt werden das Passwort zu vergeben, einfach den DN ersetzen und ein entsprechendes Passwort wählen. Der Text kann dann in eine .VBS Datei eingefügt werden.

Set objComputer = GetObject _
(„LDAP://CN=CASASA,OU=Microsoft Exchange Security Groups,DC=frankysweb,DC=local„)
objComputer.SetPassword „MeinPasswort„

Jetzt noch das VBS Script ausführen:

cscript .\computerpassword.vbs

Für das Computerkonto wird jetzt noch ein Service Principal Name (SPN) im Active Directory registriert. das passiert mit folgendem Befehl:

setspn -a HTTP/outlook.frankysweb.local FrankysWeb\CASASA$

Jetzt kann der Alternate Service Account (ASA bzw. unser neues Computerkonto) an die Client Access Server gebunden werden, dazu können folgende Befehle verwendet werden:

$creds = Get-Credential -Credential „FrankysWeb\CASASA$“
Set-ClientAccessServer EX1 -AlternateServiceAccountCredential $creds

Mit dem folgenden Befehl kann überprüft werden, ob das Konto erfolgreich an die Client Access Server gebunden wurde:

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialPassword | fl

Jetzt ist es an der Zeit die Authentifizierungsmethode umzustellen. Die Authentifizierung wird auf „Aushandeln (Negotiate)“ festgelegt, da wir nun über einen SPN und ein Alternate Service Account (ASA) verfügen, ist Exchange in der Lage Kerberos auszuhandeln. Falls die Kerberosaushandlung fehlschlagen sollte, wird NTLM als Fallback gewählt. Um die Authentifizierung umzustellen wird der folgende Befehl eingegeben:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,NTLM

Autodiscover wird die Outlook Profile automatisch umstellen, es dauert allerdings etwas bis Autodiscover die Änderungen mitbekommt. Spätestens nach 15 Minuten sollte sich im Event Log das Ereignis 3025 zu finden sein. Die Konfiguration wurde somit aktualisiert:

Es kann allerdings noch einmal bis zu 2 Stunden dauern bis die Outlook Profile umgestellt werden. Hier ist Geduld eine Tugend, oder man klickt im Outlook Profil auf „Reparieren“… (aber bitte erst nach dem Event 3025)

(Ich musste in meiner Testumgebung nach dem Klick auf „Reparieren“ Outlook wieder in den Online Modus schalten)

Nachdem das Konto also auf den aktuellen Stand ist, kann überprüft werden, ob die Authentifizierung auch tatsächlich mit Kerberos erfolgt, dazu werden am besten alle Keberos Tickets gelöscht, damit neu authentifiziert werden muss:

klist purge

Outlook zeigt jetzt als Authentifizierung „Nego“ an, das ist soweit in Ordnung:

Mit dem Befehl „klist“ können wir uns die Keberos Tickets anzeigen lassen

klist

Wenn alles geklappt hat, wird ein Ticket angezeigt, das auf den zuvor konfigurierten SPN zeigt:

Sollte das Ticket noch nicht angezeigt werden… Geduld ist eine Tugend