Wer mehrere Exchange Server über einen Loadbalancer hochverfügbar gemacht hat, nutzt in der Standardeinstellung NTLM für die Authentifizierung von Outlook Benutzern. Mit ein paar Anpassungen lässt sich aber auch Kerberos zur Authentifizierung nutzen. Kerberos reduziert gegenüber NTLM die Anzahl der Anmeldungen gegenüber dem Active Directory, was zu einer besseren Geschwindigkeit führen kann. Außerdem gilt Kerberos gegenüber NTLM als sichereres Protokoll für die Authentifizierung.
Damit Kerberos genutzt werden kann, müssen zunächst die DNS-Namen für die SPNs ermittelt werden. Oft wird eine hochverfügbare Exchange Umgebung etwa wie folgt aussehen:
Ein Loadbalancer ist den Exchange Servern vorgeschaltet und verteilt die Last der Benutzer gleichmäßig auf die Exchange Server. Die DNS Einträge für die Verbindung zeigen dabei auf die IP-Adresse des Virtual Servers des Loadbalancers. In der Regel zeigen also die folgenden DNS Einträge auf den Loadbalancer:
- outlook.domain.tld
- autodiscover.domain.tld
Genau diese DNS-Einträge sind für den SPN relevant, welcher später registriert werden muss. In manchen Umgebungen mag es weitere DNS Namen geben, da möglicherweise OutlookAnywhere und MAPIoberHTTP unterschiedliche DNS Namen verwenden. Die DNS Einträge sollten zudem als HOST-A Eintrag und nicht als CNAME existieren. Normalerweise können hier auch die Hostnamen verwendet werden, welche auf dem Zertifikat eingetragen sind.
Kerberos konfigurieren
Damit die Kerberos Authentifizierung verwendet werden kann, muss zunächst ein Computerkonto erzeugt werden. Dazu kann der folgende Befehl verwendet werden:
New-ADComputer -Name EXCH2019ASA -AccountPassword (Read-Host 'Neues Passwort eingeben' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2019ASA -Path "OU=Server,DC=frankysweblab,DC=de"
Der Distinguished Name hinter „-Path“ gibt die OU an, in der das Computerkonto erstellt werden soll. Der Parameter kann auch weggelassen werden, dann wird das Konto in der Standard OU „Computer“ erstellt:
Der nächste Befehl fügt dem Konto die nötigen Verschlüsselungstypen hinzu. Der Wert 28 gibt an, dass RC4-HMAC, AES128-CTS-HMAC-SHA1-96 und AES256-CTS-HMAC-SHA1-96 unterstützt werden:
Set-ADComputer EXCH2019ASA -add @{"msDS-SupportedEncryptionTypes"="28"}
Jetzt können die SPNs für das Konto registriert werden. In meinem Fall ist es „outlook.frankysweblab.de“ und „autodiscover.frankysweblab.de“. Diese beiden SPNs werden für das neue Computer Konto registriert:
setspn -S http/outlook.frankysweblab.de frankysweblab\EXCH2019ASA$
setspn -S http/autodiscover.frankysweblab.de frankysweblab\EXCH2019ASA$
Damit das Computer Konto als Service Account für die Kerberos Authentifizierung genutzt werden kann, muss es noch auf den Exchange Servern konfiguriert werden. Auf dem ersten Exchange Server kann dazu ein Script aus dem Exchange Script Verzeichnis verwendet werden. Das Script erzeugt dann auch ein neues Passwort für das Konto:
cd $exscripts
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer EX19EX1.frankysweblab.de -GenerateNewPasswordFor frankysweblab\EXCH2019ASA$
Nachdem der erste Exchange Server konfiguriert wurde, können alle weiteren Exchange Server konfiguriert werden. Mit dem folgenden Befehl lassen sich die Einstellungen vom ersten Server kopieren (dies muss auf allen weiteren Exchange Servern ausgeführt werden):
cd $exscripts
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer EX19EX2.frankysweblab.de -CopyFrom EX19EX1.frankysweblab.de
Wenn das Konto auf allen Exchange Servern konfiguriert wurde, lassen sich die Einstellungen mit folgendem Befehl prüfen:
Get-ClientAccessService EX19EX1 -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration
Als letzter Schritt muss nun noch die Authentifizierung für OutlookAnywhere und MAPIoverHTTP auf „Negotiate“ umgestellt werden. Dazu können die folgenden beiden Befehle verwendet werden:
Get-OutlookAnywhere -Server EX19EX1 | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
Get-MapiVirtualDirectory -Server EX19EX1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate
Outlook sollte sich nun mittels Kerberos zu den Exchange Servern verbinden, leider wird dies aber nicht direkt in der Outlook Verbindungsübersicht angezeigt. In der Outlook Verbindungsübersicht sollte nun aber in der Splate „Authn“ der Wert „Nego“ angezeigt werden:
Wenn die Kerberos Authentifizierung geklappt hat, zeigt der Befehl „klist“ auf dem Client zwei Kerberos Tickets an:
Hallo und Danke für die Anleitung.
In dieser Anleitung
https://learn.microsoft.com/en-us/previous-versions/troubleshoot/exchange/exchangeserver/kerberos-authentication-for-mapi-client
wird neben autodiscover und mail noch:
exchangeMDB/outlook.corp.contoso.com
exchangeRFR/outlook.corp.contoso.com
exchangeAB/outlook.corp.contoso.com
vorgeschlagen. Ist das empfehlenswert?
Beste Grüße
Wir hatten Probleme Kerberos bei uns einzurichten, das konnte ich aber lösen. Es lag daran, da wir ein HAProxy (Loadbalancer) einmal für den externen Zugriff und ein HAProxy für den internen Zugriff haben. Der interne HAProxy konnte Kerberos, der Externe kann es nicht. Das lag daran, da der externe HAProxy den Mode „HTTP“ eingestellt war und nicht „TCP“. Das haben wir deswegen, um z.B. ECP von außen zu sperren. Ich konnte es so lösen, indem ich die externe URL für Outlook nicht als SPN eingetragen habe, sondern nur die interne Adresse. Beispiel für SPN: autodiscover.contoso.com und webmail.intern.contoso.com Damit kann Outlook extern ohne VPN nur Basic Authentifizierung (Benutzername und Passwort abfrage), für uns war das aber OK so.
Sobald ich die SPNs eintrage knallt es bei vielen Usern und Outlook fragt nach einem Passwort und/oder verliert die Verbindung. Einem User wurde sogar das Konto gesperrt wegen zu vieler Falscheingaben.
Ich habe daraufhin abgebrochen und die SPNs wieder gelöscht; danach hat sich alles wieder beruhigt.
Es fehlten also noch die Änderungen an den Exchange-Servern. Kann ich davon ausgehen, dass es daran lag?
Update:
Ja, es lag daran!
Die Anleitung hat leider einen kleinen Schönheitsfehler was die Reihenfolge angeht. Nach dem Anlegen des Accounts muss man als nächstes die Exchange-Server konfigurieren und erst DANACH die SPNs registrieren. Hier steht auch nochmal warum das so sein muss: https://tkolber.medium.com/https-medium-com-tkolber-configure-kerberos-authentication-with-exchange-2019-72293aa234c
@Volker: Bei mir sind jetzt alle Nutzer auf Kerberos „umgezogen“, jedoch ebenfalls nicht die HealthMailboxen. Gibt es hierfür noch was zu beachten oder ist das nur ein zeitliches Problem?
klappt nur leider nicht wie beschrieben … 1x Exchange 2019, 1x DC 2019
alles eingerichtet, alles ist Negotiate .. Outlook zeigt das an
aber im IIS Log ist schon nur NTLM zu sehen und am DC wird auch kein Ereignis für den User mit der ID 4768 protokolliert.
HealthMailboxen und auch Probes sind im IIS Log mit NTLM oder Kerberos zu sehen.
oder geht das wieder nur innerhalb der selben Domäne? von dieser Beschränkung konnte ich nirgends was lesen, macht ja auch wenig Sinn bei Outlook-Anywhere dann …
Hallo Frank,
Verständnisfrage: du hast den Beitrag im Kontext geschrieben dass Exchange hinter einem LB arbeitet, bist aber nicht darauf eingegangen ob auch an dem etwas angepasst werden muss oder Kerberos dann einfach über die HTTPS-Verbindungen „getunnelt“ wird.
Ich habe die Kerberos Authentifizierung auch schon vor längerem eingerichtet um bei meinen ThinClients OWA per SSO nutzen zu können. Allerdings hat es wohl nicht ganz funktioniert bzw.
Eventuell habt ihr ja eine Idee woran es liegt.
https://www.reddit.com/r/sysadmin/comments/yavilo/exchange_2019_dag_owa_kerberos_authentication_asa/?utm_source=share&utm_medium=ios_app&utm_name=iossmf
Die Anleitung sieht aber gut aus und ich sollte es genauso gemacht haben. :-)
Hallo Frank,
wie sieht es aus , wenn man nur einen enzigen Exchange hat ? ist das vorgehen genau so ?
Habe es gerade an einem Single Exchange 2019 durchgespielt und funktioniert exakt so, wie beschrieben.