Exchange 2019: MFA mit Kemp ESP und Okta

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:

Okta App Integration

Als Sign-in Method wird „SAML 2.0“ ausgewählt:

Okta SAML 2.0

Unter „General Settings“ kann nun ein Name für die App und wenn gewünscht auch ein Logo hochgeladen werden:

Okta SAML Integreation

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“:

Okta SAML Settings

Zum Schluss kann noch Feedback an Okta gegeben und die Einrichtung der App abgeschlossen werden:

Okta Feedback

Auf dem Reiter „Sign On“ lassen sich unter dem Punkt „View Setup Instructions“ die nötigen Einstellungen für Kemp ESP anzeigen:

Okta Sign On Settings

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:

Okta Assignments

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:

Kemp SubVSs

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:

Kemp NTP

Um Probleme mit Kerberos zu vermeiden sollte darauf geachtet werden, dass der Loadmaster einen Domain Controller als DNS-Server verwendet:

Kemp DNS

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“:

AD SPN

In den Einstellungen des Benutzers „SA_Kemp“ ist nun der Reiter „Delegation“ verfügbar. Hier werden nun die folgenden Einstellungen ausgewählt:

Kerberos Delegation

Nach dem Klick auf „Add“ wird auf „Users or Computers“ geklickt und das Computerkonto des Exchange Servers gesucht:

Kerberos Delegation

Aus der Liste der Services wird jetzt „http“ ausgewählt und hinzugefügt:

Kerberos Delegation

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:

Kerberos Delegation

In der Kemp GUI wird eine „Server Side Sign On Configuration“ hinzugefügt:

Kemp Server Side Configuration

In den Einstellungen der KCD werden nun die Einstellungen zur Domain und Benutzerkonto eingetragen:

Kemp Server Side Configuration
  • 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:

Exchange virtuelle Verzeichnisse

Die Authentifizierung wird von „Formularbasiert“ zu „Integrierte Windows-Authentifizierung“ geändert:

OWA Kerberos

Gleiches gilt für das Verzeichnis „ECP“:

ECP Kerberos

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:

Kemp SubVSs

In den ESP Einstellungen wird als „Server Authentication Mode“ jetzt „KCD“ ausgewählt und unter „Server Side Configuration“ das zuvor angelegte Profil ausgewählt:

Kemp Kerberos Delegation

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:

Kemp Zertifikate

Jetzt kann eine neue „Client Side Configuration“ im Kemp GUI angelegt werden:

Kemp Client Side Configuration

In den Einstellungen wird als Protokol „SAML“ und „MetaData File“ unter dem Punkt „IdP Provisioning“ ausgewählt:

IdP Configuration

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:

IdP Configuration

Jetzt wird wieder der SubVS für OWA angepasst:

Kemp SubVSs

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:

SubVS SAML Authentication

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:

NTML 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.

6 Gedanken zu „Exchange 2019: MFA mit Kemp ESP und Okta“

    • Hallo,

      diese Frage würde mich interessieren. Hat schon jemand Erfahrungen mit KCD in Verbindung mit Extended Protection sammeln können?

      Viele Grüße
      Markus

      Antworten
  1. Hoi Frank

    Toller Artikel.
    Ist nun nicht das Problem, dass der Logoff in OWA nicht mehr sauber funktioniert ?
    (Sobald „Integrated Windows authentication“ verwendet wird)
    Oder wie löst Du das ?

    Danke und Gruss

    Antworten

Schreibe einen Kommentar