If you are already using Kemp Loadbalancer with Edge Security Pack (ESP) and Okta, you may find this article interesting. Multi-factor authentication (MFA) for OWA can be implemented using Kemp ESP and Okta. Unfortunately, only the MFA for OWA can be implemented in this way; other protocols such as MAPIoverHTTPs for Outlook or ActiveSync do not work in this way.
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.
This article is about the implementation of MFA via SAML 2.0 for Exchange 2019 OWA with Kemp ESP as Service Provider (SP) and Okta as Identity Provider (IdP).
Okta app configuration
To connect Okta to Kemp ESP via SAML 2.0, a SAML 2.0 app must be created within Okta:
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“:
Finally, feedback can be given to Okta and the app setup can be completed:
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:
Configuration Kemp ESP for Exchange
I have already described the configuration of Kemp in conjunction with Exchange 2019 in this article:
The article is quite suitable for the basic configuration and therefore serves as a template for further configuration. I therefore implemented the article in my test environment and carried out the first test straight away. Once the article has been implemented, you can already log on to the Exchange Server via Kemp ESP. The next step is to extend the configuration so that authentication via Okta and SAML 2.0 works.
If the article linked above has been implemented, a few adjustments can still be made. The following SubVS are configured by the Kemp template, but are not required and can therefore be deleted:
In order for authentication via SAML 2.0 to work correctly later, the time on the Kemp Loadmaster must be correct. It is therefore advisable to configure NTP on the loadmaster:
To avoid problems with Kerberos, make sure that the loadmaster uses a domain controller as DNS server:
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:
If there are several Exchange servers in the organization, this step must be repeated for all Exchange servers.
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:
The settings for the domain and user account are now entered in the KCD settings:
- Kerberos Realm = AD Domain Name
- Kerberos Key Distribution Center = IPs or DNS names of the domain controllers
- Kerberos Trusted User Name = name of the service account in the AD
- Kerberos Trusted User Password = Password for the previously specified user
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“:
After changing the Exchange settings, the services can now be restarted as indicated in the pop-up or alternatively the entire server can be restarted.
Internally, you no longer log in to OWA using the familiar Exchange login screen, but via Windows authentication; you no longer need to enter your user name and password.
The SubVS for OWA is now adapted in the Kemp GUI:
In den ESP Einstellungen wird als „Server Authentication Mode“ jetzt „KCD“ ausgewählt und unter „Server Side Configuration“ das zuvor angelegte Profil ausgewählt:
The login to OWA can now be tested again. Kemp should display the Kemp login screen and display the OWA website after entering the login data. It is important that no new request for login information occurs after logging in to the Kemp form. If you are asked to log in again, KCD is not working properly. In this case, the settings should be checked again and it is essential to check the DNS and time.
Kemp ESP and 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:
The SubVS for OWA is now being adapted again:
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:
The configuration for the OWA MFA is now complete. The other SubVS can use NTLM as the client authentication mode and KCD as the server authentication mode.
SAML as client side authentication for other protocols / SubVSs such as MAPI or ActiveSync does not work. Here is an NTML/ KCD example for the MAPI SubVS:
When the OWA website is called up, the user is now redirected to Okta and authentication is carried out. After successful authentication, the redirection to OWA takes place and the user is logged in.