Exchange 2019: MFA with Kemp ESP and Okta

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.

If you also want to use MFA for other Exchange protocols such as ActiveSync and MAPIoverHTTPs, you need to implement this using "Hybrid Modern Authentication (HMA)" and AzureAD. One of the next articles will also deal with HMA with AzureAD and Okta.

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:

SAML 2.0" is selected as the sign-in method:

A name for the app and, if desired, a logo can now be uploaded under "General Settings":

The domain used for the Exchange web services is specified as the "Single sign on URL" and "Audience URI". In my case, it is "https://outlook.frankysweblab.de":

Finally, feedback can be given to Okta and the app setup can be completed:

The necessary settings for Kemp ESP can be displayed on the "Sign On" tab under "View Setup Instructions":

Here you can now download the Okta certificate and save the IDP metadata in an XML file under "Optional":

The XML document under "Optional" can be saved together with the certificate; it will be required later for Kemp ESP.

On the "Assignments" tab, you now need to assign the users or groups who will use the app and who will be allowed to log in to Exchange later:

Configuration Kemp ESP for Exchange

I have already described the configuration of Kemp in conjunction with Exchange 2019 in this article:

• Howto: Exchange 2019 and Kemp Loadmaster with ESP

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:

It has also become a little easier with certificates. Kemp offers direct support for Let's Encrypt in the current Loadmaster version. The manual import of certificates is therefore no longer necessary if Let's Encrypt is configured accordingly.

Kerberos Constrained Delegation

In order for authentication via SAML 2.0 and Okta to work later, the "Kerberos Constrained Delegation (KCD)" must first be configured.

For KCD to work, the existing service account used by Kemp to query the AD must be adapted. A "ServicePrincipalName (SPN)" must first be registered for KCD; this can be done with the "SetSPN" command:

setspn -A http/KEMPHOSTNAME SERVICEACCOUNT

In my test environment, the AD user "SA_Kemp" has been set up, the loadmaster has the name "lb100" (not important). I therefore use the command "setspn -A http/lb100 SA_Kemp":

The "Delegation" tab is now available in the "SA_Kemp" user settings. The following settings are now selected here:

After clicking on "Add", click on "Users or Computers" and search for the computer account of the Exchange Server:

From the list of services, "http" is now selected and added:

If there are several Exchange servers in the organization, this step must be repeated for all Exchange servers.

The setting "This account supports Kerberos AES 256 bit encryption" is now activated on the "Account" tab:

A "Server Side Sign On Configuration" is added in the Kemp GUI:

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

The authentication for the virtual directories "OWA" and "ECP" must now be adjusted on the Exchange servers:

Authentication is changed from "Form-based" to "Integrated Windows authentication":

The same applies to the "ECP" directory:

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 the ESP settings, "KCD" is now selected as "Server Authentication Mode" and the previously created profile is selected under "Server Side Configuration":

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

From now on, there are only a few steps to integrating Okta. First, the Okta certificate must be imported. The certificate downloaded from the app settings (section Configuration Okta App - View Setup Instructions) can be imported into Kemp as an "Intermediate Cert":

A new "Client Side Configuration" can now be created in the Kemp GUI:

In the settings, "SAML" and "MetaData File" are selected as the protocol under "IdP Provisioning":

After importing the XML file, the previously imported certificate is selected under "IdP Certificate" and the domain / URI is configured as "SP Entity ID":

The SubVS for OWA is now being adapted again:

In the settings, "SAML" is now selected as the "Client Authentication Mode" and the Okta configuration is assigned as the SSO domain. "KCD" must then be set again under "Server Authentication Mode":

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.