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

by [Published on 13 Sept. 2016 / Last Updated on 13 Sept. 2016]

In the first part of this series, we looked at the options available for using Exchange Server with Active Directory Federation Services (AD FS) and Web Application Proxy (WAP) and set up the basic environment required. In part two of this series, we’ll perform simple integration steps to publish both current and earlier versions of Exchange.

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:

Image

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:

Image

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.

Image

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:

Image

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:

Image

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:

Image

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:

Image

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:

Image

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:

Image

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:

Image

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:

Service

Path

Authentication Type

Outlook Web App

/OWA/

AD FS

Exchange Control Panel

/ECP/

AD FS

Exchange Web Services

/EWS/

Pass thru

Auto Discover

/Autodiscover/

Pass thru

ActiveSync

/Microsoft-Server-ActiveSync

Pass thru

Offline Address Book

/OAB/

Pass thru

Outlook Anywhere

/rpc/

Pass thru

MAPI HTTP

/mapi/

Pass thru

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

Image

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:

Image

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:

Image

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:

Image

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:

Image

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:             

Image

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.

Image

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:

Image

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).

See Also


The Author — Steve Goodman

Steve Goodman avatar

Steve Goodman is an Exchange MVP and works as a Technical Architect for one of the UK's leading Microsoft Gold partners.