Die Konfiguration wird nach dieser aktuellen Anleitung durchgeführt: https://docs.microsoft.com/en-us/Exchange/architecture/client-access/kerberos-auth-for-load-balanced-client-access?view=exchserver-2019

Dabei wird ein AD-Computerobjekt erstellt, das mit einem Exchange-Script auf allen Exchange-Servern referenziert wird. Diesem Computerobjekt werden die erforderlichen SPN für die Exchange-Verbindung zugewiesen. Auf den CAS-Servern wird durch die Aushandlungsauthentifizierung Kerberos als bevorzugtes Authentifizierungsprotokoll verwendet.

Laut der Anleitung sind Exchange Server 2016/2019 hinter einem LoadBalancer unterstützt. Meine Testumgebung besteht aus 2 Exchange Server 2016, die über eine DAG eine hochverfügbare Infrastruktur bereitstellen. Der Clientzugriff wird über einen vorgelagerten LoadBalancer (OSI Layer 4) für interne und externe Clients bereitgestellt.

Für einen möglicherweise erforderlichen Rollback wird die letzte Datensicherung geprüft. Ein Rollback kann aber auch durch das Entfernen der SPN-Konfiguration eingeleitet werden.

Die letzten Sicherungen waren auf beiden Exchange Servern erfolgreich.

Interner Zugriff mit Outlook 2016

Die Simulation wird von einem Client mit Outlook 2016 durchgeführt. Dieser läuft als RDS-SessionHost mit Windows Server 2016. Outlook wird vor der Umstellung gestartet, um ggf. auftretende Nebeneffekte zu erkennen. Zusätzlich wird zum Zeitpunkt der Umstellung der Netzwerkdatenstrom mit WireShark analysiert.

externer Zugriff mit Outlook 2016

Der Testlauf wird von einem Windows 10 1803 mit Outlook 2016 durchgeführt. Das System ist mit einem öffentlichen Netzwerk verbunden und stellt die Verbindung zur Exchange-Infrastruktur mit MAPI-http her.

externer Zugriff mit Outlook 2010

Der Testlauf wird von einem Windows 7 mit Outlook 2010 durchgeführt. Das System befindet sich in einem fremden Netzwerk und stellt die Verbindung zur Exchange-Infrastruktur mit MAPI-http her.

externer Zugriff mit ActiveSync

Hierfür wird ein Mobiltelefon verwendet.

Erstellen des ASA-Accounts

Der zusätzliche Account wird als AD-Computeraccount eingerichtet:

New-ADComputer -Name EXCH2016ASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2016ASA

Für den Account wird ein moderner EncryptionType verwendet:

Set-ADComputer EXCH2016ASA -add @{"msDS-SupportedEncryptionTypes"="28"}

Konfiguration der Exchange Server

Die Einrichtung des ASA-Accounts wird auf dem ersten Exchange-Server mit einem Script vorgenommen:

Set-Location -Path $exscripts

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServers $env:COMPUTERNAME -GenerateNewPasswordFor 'WS\service-MX

Auf allen anderen Exchange Servern wird nun der neue Account mit dem neuen Passwort angefordert:

Set-Location -Path $exscripts

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServers $env:COMPUTERNAME -CopyFrom 'WS-MX1'

Abschließend kann die Verteilung über alle Server ausgelesen werden:

Konfiguration der SPN

Nun können die URLs als SPN an den ASA-Account angebunden werden:

# Prüfung

$URLs | ForEach-Object { setspn -F -Q "http/$_" }

# SPN registrieren

$URLs | ForEach-Object { setspn -S "http/$_" "$($env:userdomain)\$ASA_Name$('

Interner Zugriff mit Outlook 2016

Das laufende Outlook handelt keine neue Anmeldung aus und arbeitet einfach weiter. Daher starte ich Outlook neu. Dennoch gibt es kein Kerberos-Ticket. Untersuche Autodiscover:

Das Problem: es war noch eine Instanz von Outlook geöffnet. Nachdem alle geschlossen waren gab es beim Start ein Ticket:

Dennoch startet Outlook nicht:

Offenbar brauchen die Mailserver einen Augenblick zum Schwenken. Kurz darauf startet Outlook mit einem Kerberos-Ticket. Denn im Autodiscover wird nun „Aushandeln“ statt „NTLM“ gelistet:

Zur genaueren Prüfung starte ich WireShark, lösche das Ticket und starte Outlook neu. Man kann sehr schön den Request des Tickets sehen:

Auch im DomainController finde ich das passende Eventlog:

Leider wird nur „Aushandeln“ vom Client angezeigt. Dieses beinhaltet Kerberos und NTLM. Ein Fallback auf NTLM könnte also ebenfalls zu einer Verbindung zwischen Exchange und Outlook führen. Daher teste ich zusätzlich noch die Blockierung von NTLM für die Exchange-Server. Das interne Outlook kann sich ohne Probleme verbinden. Alle externen Clients verlieren die Verbindung und fragen nach Anmeldeinformationen. Das ist gut in den NTLM-Logs auf den DomainControllern erkennbar:

externer Zugriff mit Outlook 2016

Der Client kann von extern kein Kerberos verwenden und bleibt bei NTLM. Ein Neustart des Clients funktioniert problemlos.

externer Zugriff mit Outlook 2010

Der Client kann von extern kein Kerberos verwenden und bleibt bei NTLM. Ein Neustart des Clients funktioniert problemlos.

externer Zugriff mit ActiveSync

Auch das Mobiltelefon hat keine Probleme beim Verbindungsaufbau.