Howto: Exchange 2019 and Kemp Loadmaster with ESP

It's been a while since the last article on Kemp and Exchange, so here's an updated version. For this test, I used a Kemp Loadmaster VLM-5000 (which is available for free with people with MCP ID for HomeLab) and Exchange 2019. The Loadmaster firmware used is 7.2.48. The Loadmaster is operated in the classic 2-arm configuration, which means that the servers (including Exchange) are located in a different VLAN to the clients. In my test environment, Exchange is located in subnet 172.16.14.0/24 and the clients in network 192.168.100.0/24. The Loadmaster has one interface in each of the two networks and acts as an L7 load balancer.

Basic configuration Kemp Loadmaster for Exchange

There are three small settings that Kemp recommends for the use of Exchange. Firstly, "Subnet Originating Requests" should be activated under "System Configuration > Miscellaneous Options > Network Options". This setting makes sense in most configurations anyway. With this setting, the loadmaster routes the traffic via the respective interface in the subnet of the real server and not via the default gateway if the servers are located in different networks:

To avoid problems with the Exchange web services or Outlook for Mac, the settings "Additional L7 Header" and "100-Continue Handling" are important. Both settings can be found under "System Configuration > Miscellaneous Options > L7 Configuration":

That's it with the basic settings and you can start with the AD configuration.

Configuration SSO / Active Directory

In order for ESP to work later, the connection from the loadmaster to the Active Directory must be established. A new "Client Side Sigle Sign On Configuration" is added to the loadmaster for this purpose:

The domain controllers can be added to an LDAP endpoint under "Manage LDAP Configuration":

An LDAP enpoint must be created so that the Domian controllers can be added:

The domain controllers with port are specified as LDAP servers. Domain controllers use port 636 for the LDAPS protocol. In addition, a user must be specified who has read access to the Active Directory. A normal domain user account is sufficient here:

The new LDAP endpoint can now be selected in the SSO configuration. The logon format should be set to "Principalname":

The new Client Side SSO Configuration is now displayed in the overview:

The Exchange template can now be imported.

Exchange Template

Kemp offers templates for Exchange 2019 that make configuration easier. The template for Exchange 2019 can be downloaded here:

• https://kemptechnologies.com/files/assets/templates/exchange_2019_core_with_esp.tmpl

Once the template has been downloaded, it can be imported into Loadmaster:

After the import, three templates are displayed in the overview. The "Exchange 2019 HTTPS Reencrypted with ESP" template is used for this HowTo, as it generally does not require any adjustments to the Exchange configuration:

A little more data is required for the configuration; this is collected in the next section.

Required data

For the configuration of ESP in connection with Exchange 2019 in the following sections of the article, three URLs are important for the Exchange environment:

• Allowed Virtual Hosts
• Pre-Authorization Excluded Directories
  User Password Form

Both URLs must first be determined. So that you have all the necessary data to hand when it comes to the configuration, you can copy the URLs and host names together and into Notepad so that you have all the data for the configuration to hand.

The "Allowed Virtual Hosts" are the host names under which Exchange is to be published. The host names for "Allowed Virtual Hosts" are derived from the Exchange settings for the virtual directories. Here is an example, if the configured MAPI URL corresponds to "https://mail.frankysweb.de/mapi", the "Allowed Virtual Host" for the Virtual Service is "mail.frankysweb.de":

The "Allowed Virtual Hosts" are required for each protocol (do not forget Autodiscover). The value for "Pre-Authorization Excluded Directories" is made up of the GUID of the arbitration mailbox and the SMTP domain. The URL for "User Password Form" is made up of the external URL for the OWA directory and the string "auth/expiredpassword.aspx?url=/owa/auth.owa".

I have created a small script that automatically collects the data. The script provides the data required for the configuration in the next section. The output of the script then looks something like this:

A brief explanation: The SubVS is shown in green, the name of the respective setting for the SubVS is shown in yellow and the corresponding value for the setting of the SubVS is shown in white.

The script can be downloaded here:

Certificate

The Loadmaster requires an SSL certificate so that no certificate warnings appear later in the browser or Outlook. A certificate from an internal PKI or a certificate from a public CA can be used here. Free certificates from Let's Encrypt can also be imported here.

For this HowTo I use a certificate from Let's Encrypt. For the sake of simplicity, I have downloaded the Let's Encrypt certificate from the website SSLForFree related. For the certificate, it is important that all DNS names that have been configured on the Exchange servers are present on the certificate. The data from the script mentioned above can be used here, and all host names listed as "Allowed Virtual Hosts" under the first point "Exchange 2019 HTTPS Rencrypted with ESP - Authentication Proxy" must be present on the certificate. Of course, a wildcard certificate can also be used here.

An existing certificate can be added under "Certificates & Security" under "Import Certificate":

When importing, the certificate must be in PEM or PFX format:

Once the certificate has been imported, it is displayed in the overview:

All preparations for the configuration are now complete and the configuration can be started.

Loadmaster configuration for Exchange

As the template for Exchange 2019 has already been imported, a new virtual service can now be created using the template. In addition to an IP for the virtual service, the corresponding template must also be specified, in this case "Exchange 2019 HTTPS Reencrypted with ESP":

Once the new Virtual Service has been created, the settings appear directly. The first SubVS is now adjusted under the settings of the SubVSs ("SubVirtualServices"):

In the SubVS settings, the Exchange server(s) are now first added as a real server:

The IP addresses of the Exchange servers are now added as real servers. To add the Exchange servers directly to all SubVSs, the checkbox "Add to all SubVSs" can be activated:

After the Exchange servers have been added as real servers, the individual SubVSs should be displayed in the overview with a green checkmark and the previously imported certificate can now be assigned to the virtual service:

The certificate is displayed in the "Available Certificates" list and can be assigned to the Virtual Service:

You can now start configuring ESP. To configure ESP, the virtual service is adapted using "Modify":

Each individual SubVS must now receive the corresponding ESP configuration. The required values have been provided by the script, these settings are now required. Except for the SubVS "Exchange 2019 HTTPS Reencrypted with ESP - OWA", the configuration is the same for all SubVSs, so here is the configuration for all SubVSs (except OWA):

The previously created "SSO Domain" is now selected in the ESP settings of the SubVSs and the "Allowed Virtual Hosts" are configured:

The script provides the data for the Allowes Virtual Hosts, here as an example:

Some SubVSs have the value "Delegate to Server" configured as "Client Authentication Mode". This setting can be left as it is and only "Allowed Virtual Hosts" needs to be configured:

The "Allowed Virtual Hosts" and the "SSO Domain" are now configured for all SubVS with the exception of "Exchange 2019 HTTPS Reencrypted with ESP - OWA". To do this, each individual SubVS must be customized.

The SubVS "Exchange 2019 HTTPS Reencrypted with ESP - OWA" requires a little more configuration, so here are the settings provided by the script:

The data from the script is now entered in the ESP configuration of OWA:

Once all SubVSs have been adjusted, the tests can be started.

Tests

To test the configuration first, the HOSTS file can now be adapted on a client. In my test environment, I have redirected "mail.frankysweb.de" and "autodiscover.frankysweb.de":

Outlook and OWA in particular can now be tested. For the OWA test, it is advisable to use the incognito mode of the browser to bypass saved logins. The Kemp Loadmaster now offers a login mask for the OWA page (not exactly pretty):

The browser and Outlook should not issue any certificate warnings and normal working should be possible. If everything is working, the DNS and router can be adjusted.

Customization DNS and router / firewall

If the tests were successful, the adjustment to the HOSTS file can be undone. The DNS configuration is adjusted so that all clients now use the load balancer. The IP addresses for "mail.frankysweb.de" and "autodiscover.frankysweb.de" are now changed to the IP address of the loadmaster's virtual service:

As soon as the clients update the DNS cache, the load balancer is used to access Exchange. In addition to the change in the DNS, the NDAT entry on the router or firewall usually has to be changed; the IP is now also changed to the IP of the virtual service for the NAT entries for ports 443 and 80. This means that external clients also use the load balancer.

Customization (optional)

If you don't like the Kemp login form, you can replace it. Here is a template with which you can create your own login form:

• Custom Image Set

This allows the design to be adapted to the corporate identity. Alternatively, you can also download a prettier login form or an article on how to create one here:

• https://github.com/colinwilson/kemp-esp-custom-forms