Publishing and authenticating access to Exchange using AD FS and WAP (Part 2)

If you would like to be notified of when Steve Goodman releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

If you would like to read the first part in this article series please go to Publishing and authenticating access to Exchange using AD FS and WAP (Part 1).

Implementing Simple Pre-Authentication

Our first method of publishing Exchange Server relies on simple methods, using IIS Windows Integrated Authentication on the Exchange Server side to allow access to the server. This means that almost any interactive web-based login can benefit from this kind of pre-authentication, including Exchange. This differs a lot from the second technique we’ll use which relies on built-in integration with AD FS only available in later versions of Exchange.

Creating a Relying Party Trust

Our first step to get AD FS ready to allow Exchange Publishing via WAP. We need to add a Relaying Party Trust to enable this.

Open the AD FS Management Console navigate to AD FS>Trust Relationships, then choose Add Non-Claims-Aware Relying Party Trust, as shown below:

Because our configuration is simple, we’ll give it a simple name that can be re-used across other Windows Integrated Authentication reliance applications. In the example below, we’ve chosen Non-Claims Application as the name:

Next, we’ll specify an identifier for the relying party trust. This can be an arbitrary value, so in the example below we’ve used https://sts.lisajanedesigns.co.u/adfs/services/trust, as shown below.

After completing the Add Non-Claims Aware Relying Party Trust Wizard, press Finish to open the Edit Claim Rules window. Add the rule Permit Access to All Users, then press OK to complete the configuration of AD FS, as shown below:

Configuring Active Directory

With the configuration of the AD FS relying party trust complete, we will configure Active Directory so that it is ready for us to be able to pre-authenticate sessions to Outlook on the Web (OWA).

To implement this we’ll need to perform two steps.

First, we will need to add the Service Principal Names that will specify that WAP is allowed to request Kerberos tokens for HTTP-based requesters. Then we will need to specify that the WAP server is allowed to authenticate requests on behalf of users for our Exchange servers published.

To do this, open up ADSIEDIT.MSC on an Active Directory domain controller, and using the Default naming context, navigate Active Directory to find each respective WAP server. Right-click and choose Properties, as shown below:

An attribute editor window will open. Scroll down and find the servicePrincipalName attribute. This is a multi-value attribute, which means we can add multiple values to it in addition to those specified by default.

We will add two lines. The first line will specify the FQDN of the server. The second line will specify the NetBIOS name of the server. This will both be prefixed by HTTP/, for example HTTP/LDJ-WAP01 and LJD-WAP01.lisajanedesigns.local:

After pressing OK to save the changes, open Active Directory Users and Computers. We will find the WAP server in Active Directory, and choose Properties, as shown below:

In the properties window that opens, select the Delegation tab. In the Delegation tab select Trust this computer for delegation to specified services only, then select Use any authentication protocol, and finally add your Exchange Server(s) specifying the Service Type as http, as shown below:

Configuring Exchange

With our WAP server ready to publish Exchange services and the correct configuration created within our Active Directory, we will ensure Exchange is configured to allow pre-authenticated access using Windows Integrated Authentication for services.

In our example, we will perform pre-authentication against OWAand the Exchange Admin Center, and use Pass-thru authentication for other services.

Therefore, we’ll open the EAC (or the Exchange Management Console if you’re using Exchange 2010) and navigate to the Servers section and then under Virtual Directories, select the OWA virtual directory, then select Properties, as shown below:

On the OWA virtual directory, select the Authentication tab, then ensure Use one of more standard authentication methods is selected, with Integrated Windows authentication selected within, as shown below:

After choosing Save, we’ll repeat the same actions for the ECP virtual directory, which hosts the Exchange Admin Center. To apply the configuration, we’ll perform iisreset /noforce against each server reconfigured, using an elevated command prompt.

Publishing Exchange

To publish Exchange using WAP and ADFS using the simple method, we will open the Remote Access Management Console on the WAP server to publish each service.

In this example, we will be publishing services as shown below:

Within the Remote Access Management Console, navigate to Configuration > Web Application Proxy, then choose Publish, as shown below:

In the Publish New Application Wizard that launches, for each pre-authenticated virtual directory choose Active Directory Federation Services (AD FS) for the pre-authentication type:

As we navigate through the wizard, we’ll be presented with the Relaying Party screen on the wizard. This will show our Non-Claims Application relaying party trust we created earlier in this article. Select this, then press Next:

We will then be presented with the options relevant to publishing the application against the back-end Exchange Server itself. We’ll make sure we choose the details carefully here, because if we need to change settings using the GUI it will involve removing and re-creating the settings.

In our example below, we’ve entered a friendly description, Outlook Web App for our reference, then entered the External URL to publish OWA as, with a trailing slash (/).

Next we will choose the external certificate. In our example this will be the wildcard certificate, and also enter the back-end server URL.

Finally, we will enter the Service Principal Name (SPN) for the Exchange server we’re publishing. In our example this is HTTP/ followed by the FQDN of the Exchange server – i.e. HTTP/LJD-MBX01.lisajanedesigns.local:

After completing the publishing of each Exchange Virtual Directory that will require pre-authentication, we will then use the wizard to publish our Virtual Directories that will use pass-through authentication. As we launch the wizard, we’ll simply choose Pass-through to avoid pre-authentication, as shown below:

Next we will enter a friendly name to describe the service we’re publishing and enter the external and internal URLs (again with trailing slashes) and selected the appropriate wildcard SSL certificate:

After completing publishing of each virtual directory, we will examine the Published Web Applications section of the Remote Access Management Console. We will see the friendly name we have chosen, paired with the external URL we have used to publish the resource.

After completing the configuration of the simple pre-authentication via WAP we will test the solution. From an external IP address, or a client one that can resolve the DNS name and connect to our published Exchange resources to the WAP server, we will attempt to access Outlook on the web, as shown below:

After we have entered the credentials, we will be able to access Outlook on the web as normal. To ensure access on all published protocols works as expected, it’s worth testing using tools such as the Remote Connectivity Analyser. This will be helpful to ensure that services such as Exchange ActiveSync work as expected.

What’s next?

In part two of this series we have published Exchange Server using simple pre-authentication methods via AD FS and WAP. In the next part of this series we will Exchange 2013 SP1+ and Exchange 2016 only techniques to authenticate access to Exchange using native AD FS integration.

If you would like to be notified of when Steve Goodman releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

If you would like to read the first part in this article series please go to Publishing and authenticating access to Exchange using AD FS and WAP (Part 1).