Kemp Load Master – SAML via OKTA with KCD to Microsoft Exchange OWA (Outlook Web Access)

Active Directory Kemp Technologies Microsoft Exchange Microsoft Windows Okta Security
Tristan SelfLeave a Comment on Kemp Load Master – SAML via OKTA with KCD to Microsoft Exchange OWA (Outlook Web Access)

The Kemp Load Master allows for the configuration of authentication offloading to itself (from the Microsoft Exchange server supporting Kerberos) to allow for the Kemp Load Master to act as a sP (Service Provider) against an IdP (Identity Provider) for example OKTA. The use of SAML via OKTA allows for any SAML (and Kerberos KCD compatible) application to have 2FA (Two Factor Authentication) bolted onto the front, even if it doesn’t natively support it.

This document assumes you have already configured some form of authentication offload on the Kemp Load Master, i.e. that you have the ability (although its not needed from the get go) to make the Kemp Load Master present the OWA (Outlook Web Access) logon page and then authenticate the user then pass the connection on to the Exchange Server back ends.

The documentation below is written to give you an idea of the main steps required to do enable SAML won the Kemp Load Master which uses OKTA as the sP, although the application is Microsoft Exchange OWA, in theory any Kerberos enabled application can be made to work this way, where you can use OKTA features to apply additional layers of security that might otherwise not be possible (if not supported natively by the application), e.g. 2FA (2 Factor Authentication).

Authentication Flow and Overview

The below details how the Microsoft Exchange 2016 Outlook Web Access can be secured with Kerberos authentication and published via the Kemp Load Master which in turn can apply a SAML and OKTA based authentication layer in front to publish the application securely and convieniently to the Internet (allowing for additional 2FA support even if the web application does not provide this itself). The Kemp Load Master can achieve this by authenticating a Internet (or internal) based user via SAML first, then use KCD (Kerberos Constrained Delegation) to obtain a TGS (Ticket Granting Service) Ticket from the KDC (Domain Controller) which impersonates the Internet (or internal network user) when presenting it to the Kerberos enabled Microsoft Exchange OWA presentation.

  1. User makes the request to the owa.domain.com URL from their web browser, this is provided as a Virtual Service on the Kemp Load Master.
  2. Kemp Load Master (as the sP) redirects to OKTA (IdP) to perform the SAML authentication for this Virtual Service, utilising the ESP function of the Kemp Load Master.
  3. OKTA challenges the user for their access credentials (username and password) and performs other steps like 2FA (2 Factor Authentication).
  4. A validated user is redirected back to the sP with a valid SAML token which is signed with a certificate trusted by both the IdP and sP.
  5. The Kemp Load Master then using its configured KCD account, requests a ticket from the KDC (Domain Controller) on behalf of the user (bob) for the service: owa.domain.com (i.e. one of the Exchange server hosts and so on, essentially impersonating them.
  6. The KDC provides a TGS (Ticket Granting Service) Ticket impersonating the user “bob” back to the Kemp Load Master.
  7. The Load Master connects to the back end server (Real Server) owa.domain.com presenting its KCD impersonation Kerberos ticket. If the Kemp Load Master was to connect without a KCD Ticket the Real Server would present a logon box to the client.
  8. The Exchange Server checks the KCD Ticket which has been signed by the KDC, because the Exchange Server is joined to the domain (and OWA is configured for Kerberos Authentication) it trusts the KDC and therefore anything it appears to have signed, so lets the user in.
  9. The Microsoft Exchange OWA is then accessible to the user.

Create the KCD Impersonation Account

The Kemp document goes into detail in section 2.7, but essentially you need to create a “trusteduser” that will be what the Kemp Load Master uses to get the KCD Kerberos Ticket.

Create a user called “kcdkemp” in Active Directory using Active Directory Users and Computers, set to have a password and never expire.

Edit the user account and make the following changes to the attributes:

Attribute: servicePrincipalName

Value: http/kcdkemp

Click on the “Delegation” tab and configure a follows:

Click “Add” to add the SPN for the Real Server(s) for all the Microsoft Exchange servers exchange1.domain.com exchange2.domain.com and so on. This tells Active Directory to constrain the Kerberos delegation to only requests made with this particular SPN. It basically means that this kcdkemp couldn’t be used to access another website hosted on another web server for example. Bear in mind that the URL used doesn’t matter (in this case it is owa.domain.com), the Kemp Load Master is making the request on behalf of the end user client and that request is made to the Real Server hostname (e.g. exchange1.domain.com) not owa.domain.com.

The following should be added for all the back end real servers, the FQDN may be added automatically when you’ve just entered the hostname.

http/exchange1
http/exchange2
http/exchange3
http/exchange4

NOTE: If any new Exchange Servers are added to the cluster (or removed) in future these must be added or subtracted from these settings to avoid authentication issues.

But, you can add other SPNs for any of the other web sites that you would like to use with this KCD trusted user account as required.

Then tick the box for: “This account supports Kerberos AES 256 bit encryption” under the “General” tab.

Save by clicking “OK”.

Create Server Side Single Sign On (SSO) Domain (KCD)

On the Kemp Load Master, complete these steps

1. Expand Virtual Services > Manage SSO.

2. Enable the Use AES56 SHA1 KCD cipher check box.

When this check box is selected, the AES256 SHA1 KCD cipher is used (by default the RC4, DES, and DES3 ciphers are used).

3. Type in a name for the “Add New Server Side Configuration” (DOMAIN-KCD) and then click on “Add”.

4. Complete the details as shown below:

That completes the creation of the KCD settings. Bear in mind that the Kemp Load Master needs to have port 88 TCP/UDP open to the KDC(s) for it to be able to request the ticket, you do not need this port open however from the Kemp Load Master to the Real Server web server, the authentication information is made within the HTTP request header within 443/TCP.

You can also add multiple KDCs as IP addresses with spaces between for resilience.

Create Client Side Single Sign On (SSO) Domain (LDAP)

1. Expand Virtual Services > Manage SSO.

2. Type in a name for the “Add New Client Side Configuration” (DOMAIN.COM) and then click on “Add”.

3. Complete the configuration as below, including the Active Directory/LDAP Endpoint configuration.

Setting the two LDAP Server(s) for resilience.

The KCDKemp account has been used for the LDAP lookup also to ensure it is clear what each account is used for.

Create Client Side Single Sign On (SSO) Domain (SAML)

1. Expand Virtual Services > Manage SSO.

2. Type in a name for the “Add New Client Side Configuration” (OKTA-SAML) and then click on “Add”.

3. Complete the sP configuration as shown below, where the IdP Entity ID, IdP SSO URL and IdP Logoff URL will be provided by whomever is configuring the OKTA IdP side.

Completing the Okta section below will provide all the configuration setting you’ll need to complete the form below, the setting can be found on the Sign On tab once the application as been setup and by click on the View Setup instructions button.

See further down the page for the OKTA configuration to create an application that will generate you the relevant entities URLs etc. you’ll need to complete this section.

NOTE: You will need to have uploaded the IdP Certificate (i.e. Public Key of the OKTA IdP) as an intermediate certificate, so it can be selected from the list. Also using a sP Signing Certificate is acceptable, you will need to share this with whomever is configuring the OKTA IdP (its the Public Key of the Kemp sP).

  1. To do this click “Certificates & Security” then “Intermediate Certs”.
  2. Upload the certificate, then  it is available for selection as the “IdP Certificate” in the above configuration.

Additionally if you are planning more than one Kemp Load Master (cluster) to use the SAML OKTA IdP, then you need to use the same sP certificate on all of them as you only have the option to load in one at the OKTA end.

4. Save the settings and now the SSO domain is ready.

Firewall Rules (DMZ Only)

If the Kemp Load Masters operate through a Firewall you will need to ensure there is the applicable rules open from your Kemp Load Master to your internal Active Directory domain controllers and internal Exchange Servers.

Assuming that the rule that allows the Kemp Load Master to reach the internal Exchange Servers over HTTPS (and HTTP) is there, the only additional rule that is needed is the rule to allow the Kemp Load Master to connect with Kerberos (TCP/UDP Port 88) to the internal Domain Controllers (KDC) in order to obtain the KCD tickets.

Configure the Microsoft Exchange Server(s) for Kerberos Authentication (KCD)

Once the Kemp Load Master configuration has been changed, each Microsoft Exchange Server needs to be changed one by one to switch it from FBA (Form Based Authentication) to use Kerberos Authentication instead for the OWA and ECP Virtual Directories only, in this setup everything else is left as its default configuration.

Only the OWA (and ECP) is configured to use KCD, and the ActiveSync is configured to use authentication offload on the Kemp to give greater visibility of logon activity, from the outside (i.e. presented via the DMZ Kemp Load Master) the other protocols such as PowerShell, RPC over HTTPS, MAPI over HTTPS and EWS (and ECP) have all been disabled anyway.

By making the change (as shown below) to one server and verifying it works, you ensure you’ve not affected anything else and can ensure access is maintained. With KCD is does essentially fail safe, if the KCD exchange fails, the user is just presented a simple username/password box where they can fill in their details themselves to logon, so its not like you’re locked out of OWA or ECP if something was to go awry.

On the Exchange Admin Center (ECP) click on “Servers”, then “Virtual Directories” tab from the top.

Find the “owa (Default Web Site)” for one of the servers and click “Edit”, note both the OWA and ECP must be changed at the same time for each server.

Make the change as shown below to swap from FBA to Kerberos (Integrated Windows Authentication) and click “Save”.

Make a note of the service restart commands, you’ll need to run this in a moment.

Now repeat for the “ecp (Default Web Site)” too as shown below:

Now stop and restart the services on the Exchange server as instructed.

Note that you’ll need to manually restart the WAS service and listeners yourself on the Exchange Server for these settings to take effect.

At this point you’ll find that any connection to this server for OWA or ECP will now need Kerberos, KCD or for the user to manually enter their password into the plain credentials box.

Configure the Virtual Services on Kemp Load Master for Microsoft Exchange

The configuration is given below for the Kemp Load Master, unless you can see the setting you should leave the setting as its default, essentially only the OWA, ECP and ActiveSync services should be enabled for ESP, everything else should be set to be a normal passthrough configuration.

The configuration described below was based off the default Kemp Load Master template for Microsoft Exchange 2016 with SSL offload and ESP.

The internal Kemp Load Masters are configured to present all services for Microsoft Exchange.

However the DMZ Kemp Load Masters that present services to the Internet are restricted to only provide: ActiveSync, Autodiscover and OWA, all other services are configured as shown to be disabled.

On any Virtual Service or Sub-Virtual Service that is using ESP, you should ensure that the “Allowed Virtual Hosts” field is set to “owa.domain.com” to avoid rejected connections.

In this SAML configuration, the “Authentication Proxy” should have a configuration as shown, but is not actively used.

Part 1 – Outlook Web Access (OWA) and Exchange Control Panel (ECP) Virtual Services (2FA with SAML and KCD)

When configuring the OWA you first need to obtain the string below from the Exchange server by running this command.

/owa/f6825833-9f08-4de3-8f20-c1aa2d2d9232@domain.com* /owa/auth/expiredpassword.aspx*

Outlook Web Access (OWA)

Exchange Admin Center (ECP)

Part 2 – ActiveSync Virtual Service (off-loaded Basic Authentication)

The ActiveSync service does not use SAML, but is different from the rest of the services (configured with passthrough), this uses “Basic Authentication” to the SSO domain to allow for more in-depth insight into the connections and users connecting for security purposes.

Part 3 – Remaining (All Other) Microsoft Exchange Virtual Services (Server Passthrough)

The rest of the services, i.e. Autodiscover, EWS, MAPI, OAB, PowerShell and RPC should be configured as normal, just as a server passthrough, on the DMZ kemp some of these should be disabled as described above.

Configure OKTA for SAML via the Kemp Load Master with the Microsoft Exchange OWA owa.domain.com

I’ve not had a huge amount of experience with OKTA for configuring applications, the below was done with another member of the team, but essentially you create a SAML 2.0 service which will provide the relevant URL fields to complete the associated configuration in the Kemp Load Master.

Open the Okta admin console and click applications and then click create application integration and select SAML from options.

Enter the name of the application and click next. As this application will be SP initiated, it may be worth also checking the boxes next to. Do not display application icon to users and Do not display application icon in the Okta Mobile app

In our case lets put in something like Outlook Web Access (OWA).

On the next screen enter the SP Entity ID that you used in SSO KEMP configuration above (OKTA-SAML), in this case https://owa.domain.com this should be set in both the Single sign on URL and Audience URI (SP Entity ID) text boxes.

You will also need to upload the sP certificate. i.e. the certificate from the Kemp Load Master(s) as well to ensure you have a trust between OKTA (the IdP) and the Kemp (the sP).

Also select AD user principal name from the drop down next to Application username.

Leave all other setting as default and click next.

The final screen just asks what type of application you are creating, set the following options:

Then click finish and your new application has been created.

Before a user can access the site they will need to be assigned to the new OKTA application you have just created, click the assignments tab and assign the appropriate user or groups. You might want to start with a small subset of people just to test.

To help with the KEMP SSO Setup you can click the Sign On tab and click View Setup Instructions.

Now when you go to owa.domain.com this will be directed to the Kemp Load Master, the connection will then be captured by the SAML configuration and redirected to the IdP which in this case is OKTA, successfully logging into OKTA will redirect you back to the Kemp Load Master, this will then obtain a KCD ticket from the Domain Controller (Key Distribution Centre KDC) and then the Kemp Load Master will use this KCD ticket when accessing the Microsoft Exchange Server. All being well you should be logged straight in.

If you are seeing a Form based authentication page or small username/password box for Microsoft Exchange instead of being logged straight in, ensure you have made the correct changes to Exchange OWA security settings as described above, then review the Kemp Load Master logs (as described below) to assist in troubleshooting the issue.

SSO Cache

Also be aware on the Kemp Load Master of the SSO Cache this can hold onto incorrect or odd information, during testing we were making changes but nothing was happening, therefore forcing a flush of the “SSO Cache” between making major settings changes is recommended.

You can find this in: WUI -> Logging Options -> System Log Files -> Debug Options -> Flush SSO Cache

Troubleshooting Log Locations (and explainations)

You can check on Splunk, however the recommended place is in the “System Log” on the Kemp, you’ll need to view this to see the KCD authentication attempts.

Look in here for the “ssomgr” as the source filtering based on this can make it easier to find the connection attempts and trace the whole authentication.

It is recommended to periodically clear the SSO cache on the Kemp Load Master or clear it once you have made a change to ensure you can see the changes have been reflected as expected. To do this:

Logging Options > System Log Files > Debug Options 

Click on the Flush SSO Cache button and wait about 30 seconds for it to be cleared before performing your next check.

When you open the Wireshark PCAP file, filter using the word Kerberos. 

Pay attention to the following information:

AS-REQ: This is where the client is authenticated and a ticket-granting ticket (TGT) is retrieved. In this case, your client is the Kerberos Trusted User (kempkcd). 

TGS-REQ: Here, you present your TGT to Kerberos where it is verified against its database.

Resilience of the KCD and LDAP Authentication Flow

On the Kemp Load Master the KCD and LDAP configurations have two servers specified to ensure if the first is not available the second can be used for either KCD or LDAP authentication.

Additional Information

Image Attribution

Related Posts

Multi-Factor (MFA/2FA) Authentication for HPE Nimble Storage using Okta

Tristan Self

Exchange 2010 Restoration fails with: ROP Error: 0x80070057 Error: MapiExceptionInvalidParameter: Unable to modify table.

Tristan Self

Disabling the Interactive Logon Message

Tristan Self

Leave a Reply

Your email address will not be published. Required fields are marked *