Wer bereits Kemp Loadbalancer mit Edge Security Pack (ESP) und Okta im Einsatz hat, findet vielleicht diesen Artikel interessant. Mittels Kemp ESP und Okta lässt sich eine Multi-Faktor Authentifizierung (MFA) für OWA umsetzen. Leider lässt sich auf diesem Weg aber nur die MFA für OWA umsetzen, andere Protokolle wie MAPIoverHTTPs für Outlook oder ActiveSync funktionieren auf diesem Weg nicht.
Wer MFA auch für weitere Exchange Protokolle wie ActiveSync und MAPIoverHTTPs einsetzen möchte, muss dies über die „Hybrid Modern Authentication (HMA)“ und AzureAD realisieren. In einem der nächsten Artikel wird auch HMA mit AzureAD und Okta behandelt.
In diesem Artikel geht es um die Umsetzung der MFA via SAML 2.0 für Exchange 2019 OWA mit Kemp ESP als Service Provider (SP) und Okta als Identity Provider (IdP).
Konfiguration Okta App
Um Okta mit Kemp ESP via SAML 2.0 zu verbinden, muss innerhalb von Okta eine SAML 2.0 App angelegt werden:
Als Sign-in Method wird „SAML 2.0“ ausgewählt:
Unter „General Settings“ kann nun ein Name für die App und wenn gewünscht auch ein Logo hochgeladen werden:
Als „Single sign on URL“ und „Audience URI“ wird die Domain angegeben, welche für die Exchange Webservices genutzt wird. In meinem Fall ist es „https://outlook.frankysweblab.de“:
Zum Schluss kann noch Feedback an Okta gegeben und die Einrichtung der App abgeschlossen werden:
Auf dem Reiter „Sign On“ lassen sich unter dem Punkt „View Setup Instructions“ die nötigen Einstellungen für Kemp ESP anzeigen:
Hier kann nun das Okta Zertifikat runtergeladen und unter dem Punkt „Optional“ die IDP Metadata in einer XML-Datei gespeichert werden:
Das XML Dokument unter „Optional“ kann mit dem Zertifikat zusammen gespeichert werden, es wird später für Kemp ESP benötigt.
Auf dem Reiter „Assignments“ müssen nun noch die Benutzer oder Gruppen zugewiesen werden, welche die App benutzen und sich damit auch später an Exchange anmelden dürfen:
Konfiguration Kemp ESP für Exchange
Die Konfiguration von Kemp in Verbindung mit Exchange 2019 habe ich bereits in diesem Artikel beschrieben:
Der Artikel eignet sich für die Grundkonfiguration ganz gut und dient daher als Vorlage für die weitere Konfiguration. In meiner Testumgebung habe ich daher den Artikel umgesetzt und so auch gleich den ersten Test durchgeführt. Nach der Umsetzung des Artikel kann sich bereits via Kemp ESP am Exchange Server angemeldet werden. Im nächsten Schritt wird dann die Konfiguration erweitert, damit die Authentifizierung via Okta und SAML 2.0 funktioniert.
Wenn der Artikel oben verlinkte umgesetzt wurde, können noch ein paar Anpassungen durchgeführt werden. Die folgenden SubVS werden durch das Kemp Template konfiguriert, aber nicht benötigt und können daher gelöscht werden:
Damit die Authentifizierung via SAML 2.0 später korrekt funktioniert, muss die Uhrzeit auf dem Kemp Loadmaster stimmen. Daher ist es empfehlenswert NTP auf dem Loadmaster zu konfigurieren:
Um Probleme mit Kerberos zu vermeiden sollte darauf geachtet werden, dass der Loadmaster einen Domain Controller als DNS-Server verwendet:
Auch bei den Zertifikaten ist es etwas einfacher geworden. Kemp bietet in der aktuellen Loadmaster Version eine direkte Unterstützung für Let’s Encrypt. Der manuelle Import der Zertifikate ist somit nicht mehr erforderlich, wenn Let’s Encrypt entsprechend konfiguriert wird.
Kerberos Constrained Delegation
Damit später die Authentifizierung via SAML 2.0 und Okta funktioniert, muss zunächst die „Kerberos Constrained Delegation (KCD)“ konfiguriert werden.
Damit KCD funktioniert muss der vorhandene Service Account, welcher von Kemp für die Abfrage des ADs benutzt wird, angepasst werden. Für KCD muss zunächst ein „ServicePrincipalName (SPN)“ registriert werden, dies kann mit dem Befehl „SetSPN“ erledigt werden:
setspn -A http/KEMPHOSTNAME SERVICEACCOUNT
In meiner Testumgebung wurde der AD-Benutzer „SA_Kemp“ eingerichtet, der Loadmaster hört auf den Namen „lb100“ (nicht weiter wichtig). Ich benutze daher den Befehl „setspn -A http/lb100 SA_Kemp“:
In den Einstellungen des Benutzers „SA_Kemp“ ist nun der Reiter „Delegation“ verfügbar. Hier werden nun die folgenden Einstellungen ausgewählt:
Nach dem Klick auf „Add“ wird auf „Users or Computers“ geklickt und das Computerkonto des Exchange Servers gesucht:
Aus der Liste der Services wird jetzt „http“ ausgewählt und hinzugefügt:
Wenn es mehrere Exchange Server in der Organisation gibt, muss dieser Schritt für alle Exchange Server wiederholt werden.
Auf dem Reiter „Account“ wird jetzt noch die Einstellung „This Account supports Kerberos AES 256 bit encryption“ aktiviert:
In der Kemp GUI wird eine „Server Side Sign On Configuration“ hinzugefügt:
In den Einstellungen der KCD werden nun die Einstellungen zur Domain und Benutzerkonto eingetragen:
- Kerberos Realm = AD Domain Name
- Kerberos Key Distribution Center = IPs oder DNS Namen der Domain Controller
- Kerberos Trusted User Name = Name des Service Accounts im AD
- Kerberos Trusted User Password = Passwort für den zuvor angegebenen Benutzer
Auf den Exchange Servern muss nun die Authentifizierung für die virtuellen Verzeichnisse „OWA“ und „ECP“ angepasst werden:
Die Authentifizierung wird von „Formularbasiert“ zu „Integrierte Windows-Authentifizierung“ geändert:
Gleiches gilt für das Verzeichnis „ECP“:
Nach dem Ändern der Exchange Einstellungen können nun die Dienste wie im Pop-Up angegeben neu gestartet werden oder alternativ der ganze Server neu gestartet werden.
Intern wird sich nun nicht mehr mit der bekannten Exchange Anmeldemaske an OWA angemeldet, sondern via Windows-Authentifizierung, die Angabe von Benutzername und Kennwort ist nicht mehr erforderlich.
In der Kemp GUI wird nun der SubVS für OWA angepasst:
In den ESP Einstellungen wird als „Server Authentication Mode“ jetzt „KCD“ ausgewählt und unter „Server Side Configuration“ das zuvor angelegte Profil ausgewählt:
Die Anmeldung an OWA kann jetzt einmal wieder getestet werden. Kemp sollte die Kemp Login Maske anzeigen und nach dem Eingeben der Anmeldedaten die OWA Webseite anzeigen. Wichtig ist, dass keine erneute Abfrage nach Anmeldeinformationen nach dem Anmelden am Kemp Formular auftritt. Falls doch eine weitere Aufforderung zur Anmeldung auftritt, funktioniert KCD nicht richtig. In diesem Fall sollten die Einstellungen noch einmal kontrolliert werden, unbedingt auch auf DNS und Zeit achten.
Kemp ESP und Okta
Ab jetzt sind es nur noch wenige Schritte zur Integration von Okta. Zuerst muss das Okta Zertifikat importiert werden. Das aus den App Einstellungen runtergeladene Zertifikat (Abschnitt Konfiguration Okta App – View Setup Instructions), kann als „Intermediate Cert“ in Kemp importiert werden:
Jetzt kann eine neue „Client Side Configuration“ im Kemp GUI angelegt werden:
In den Einstellungen wird als Protokol „SAML“ und „MetaData File“ unter dem Punkt „IdP Provisioning“ ausgewählt:
Nach dem Import der XML Datei wird noch das zuvor importierte Zertifikat unter dem Punkt „IdP Certificate“ ausgewählt und die Domain / URI als „SP Entity ID“ konfiguriert werden:
Jetzt wird wieder der SubVS für OWA angepasst:
In den Einstellungen wird jetzt „SAML“ als „Client Authentication Mode“ ausgewählt und die Okta Konfiguration als SSO Domain zugewiesen. Unter dem Punkt „Server Authentication Mode“ muss dann „KCD“ wieder erneut eingestellt werden:
Die Konfiguration für die OWA MFA ist nun abgeschlossen. Die anderen SubVS können als Client Authentication Mode NTLM und als Server Authentication Mode KCD verwenden.
SAML als Client Side Authentication für weitere Protokolle / SubVSs wie MAPI oder ActiveSync funktionieren nicht. Hier ein NTML/ KCD Beispiel für den MAPI SubVS:
Bei dem Aufruf der OWA Webseite wird nun zu Okta umgeleitet und die Authentifizierung durchgeführt. Nach erfolgreicher Authentifizierung erfolgt die Umleitung zu OWA und der Benutzer wird angemeldet.