Aktivierung von Kerberos im Exchange Server 2016/2019

Vorbereitung

Beschreibung

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.

Prüfung der Voraussetzungen

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.

Datensicherung & Rollback

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.

Bereitstellung von TestSzenarien

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.

Umstellung auf Kerberos

Umstellung

Erstellen des ASA-Accounts

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


Für den Account wird ein moderner EncryptionType verwendet:

Konfiguration der Exchange Server

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


Aktivierung von Kerberos im Exchange Server 2016/2019

Aktivierung von Kerberos im Exchange Server 2016/2019

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


Aktivierung von Kerberos im Exchange Server 2016/2019

Aktivierung von Kerberos im Exchange Server 2016/2019

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

Aktivierung von Kerberos im Exchange Server 2016/2019

Konfiguration der SPN

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


Testlauf

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:

Aktivierung von Kerberos im Exchange Server 2016/2019

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

Aktivierung von Kerberos im Exchange Server 2016/2019

Dennoch startet Outlook nicht:

Aktivierung von Kerberos im Exchange Server 2016/2019

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:

Aktivierung von Kerberos im Exchange Server 2016/2019

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:

Aktivierung von Kerberos im Exchange Server 2016/2019

Aktivierung von Kerberos im Exchange Server 2016/2019

Auch im DomainController finde ich das passende Eventlog:

Aktivierung von Kerberos im Exchange Server 2016/2019

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:

Aktivierung von Kerberos im Exchange Server 2016/2019

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.

Zusammenfassung

Das sieht doch gar nicht schlecht aus. Warum aktiviert Microsoft diese Authentifizierung eigentlich nicht selber? Zudem sind keine weiteren Nacharbeiten erforderlich.

Und wie üblich gibt es hier das WS-HowTo mit dem PowerShell-Script zum Download.

Stay tuned!

Kommentar hinterlassen