If you would like to read the next part in this article series please go to Publishing and authenticating access to Exchange using AD FS and WAP (Part 2).
Introduction
In this multi-part series, we’re going to look at how to use Active Directory Federation Services (AD FS) to allow Single Sign On (SSO) and pre-authentication to Exchange Server, allowing better interoperability for users sharing a web browser session with on-premises Exchange and Office 365.
We’ll first demonstrate how to do this using techniques that work with multiple versions of Exchange, then demonstrate how to use native features for AD FS integration with later Exchange versions.
Options for AD FS authentication
Exchange Server supports a number of options for publishing web services to clients. In particular, they both support a variety of options when using Microsoft’s Active Directory Federation Services (AD FS) and Web Application Proxy (WAP).
AD FS works closely with Active Directory as an identity provider (IdP) and can verify credentials for many different service providers (SPs), both running on-premise, such as Exchange, or running in the cloud, like Office 365. The version of AD FS we’re working with in this article is ADFS 2012 R2, included with Windows Server 2012 R2.
WAP works with AD FS, and performs a number of roles. Firstly, it allows AD FS to be published to external clients, and when used helps define the perimeter boundary of the network. You’ll typically find it installed within the DMZ / perimeter network. Secondly it can act as a reverse proxy to existing web applications, providing access to web applications via a secure server that has the ability to perform pre authentication where required.
Three options for publishing Exchange in conjunction with AD FS and WAP are available:
- Use WAP to publish Exchange Server using pre-authentication, but with simply AD FS integration reliant on IIS and Kerberos delegation. This is suited to organizations that don’t want AD FS dependencies for internal clients logging into Outlook on the web (OWA) and the Exchange Admin Center (EAC), but want to enforce pre-auth for external clients.
- Use WAP to publish Exchange Server 2013 or 2016 using pre-authentication, using built-in Exchange functionality to use AD FS as the IdP for Exchange. Exchange can be published normally using a traditional load balancer, and all OWA and ECP authentication requests will be redirected to the AD FS server or WAP.
- Use WAP to simply publish Exchange Server HTTPS to the internet, without any pre-authentication, passing through the connection. This is appropriate for services like Exchange ActiveSync or MAPI HTTP.
Our example scenarios
We’ll examine both option one and option two. As part of option one and two, we’ll demonstrate how to implement option three, as it’s important for publishing services that don’t support pre-authentication.
Although publishing Exchange via WAP is strictly optional for option one, we’ll show you how to do this as part of the series. In your organization you might find you don’t need to do this if you are already publishing Exchange using a third-party load balancer or don’t publish it to external clients at all.
Setup of our AD FS and WAP environment
In our example organization, Lisa Jane Designs, we’ve configured Exchange with the external HTTPS namespace of mail.lisajanedesigns.co.uk and uses a wildcard SSL certificate, *.lisajanedesigns.co.uk. Our AD FS server will use the name sts.lisajanedesigns.co.uk and the wildcard SSL certificate will be used for the AD FS server and WAP server.
Pre-requisites
To use AD FS and Web Application Proxy, we’ll need the following components ready.
- One or more Windows Server 2012 R2 instance to use to run Active Directory Federated Services joined to the domain.
- If you’re publishing Exchange externally, then you will need one or more Windows Server 2012 R2 instance to use for Web Application Proxy. For our second scenario we must ensure they are joined to the domain.
- Valid third-party SSL certificates to support the AD FS instance name and Exchange HTTPS names published externally.
Configuring Certificates
Our first task on the Windows Server 2012 R2 servers that will host AD FS and WAP is to install the wildcard SSL certificate.
Using the certificates snap-in within the Microsoft Management Console (MMC), we’ll ensure the wildcard certificate is imported within the context of the Local Computer. This should show as shown below:
You’ll see in the example above, the certificate, and associated private key is correctly installed, and issued by a valid third-party certificate authority.
Installing AD FS
To support both scenarios we will need to set up and configure AD FS to use for pre-authentication and store the WAP configuration.
To install AD FS open the Add Roles and Features Wizard from Server Manager and within Server Roles, select Active Directory Federation Services as shown in the example below.
Choose Next to step through the installation process, and after installation successfully completes, choose Configure the federation service on this server, as shown in the example below:
With the installation of AD FS complete, next we need to define the configuration information for AD FS and then allow the AD FS Configuration Wizard to apply the correct configuration.
On the first page of the wizard, we are given the option for the type of configuration to perform. In previous versions of AD FS, we were given a number of options, including one to create a standalone farm. As a farm can consist of a single member, you’ll see in Windows Server 2012 R2 the standalone farm option has been removed. So even if we are just adding a single node, we’ll choose Create the first federation server in a federation server farm, as shown below.
On the second page of the wizard, we’ll have the opportunity to define the Federation Service Properties. We’ll select the SSL certificate we’ve pre-installed when preparing the server, and specify a Federation Service Name and Display Name, as shown below.
When choosing the Fully Qualified Domain Name (FQDN) for the Federation Service Name, remember that the name we choose can be abstract for the server name itself, and it is typical to choose a name such as FS (Federation Service) or STS (Security Token Service) in the same way Exchange is often named Mail rather than the Exchange Server name itself.
In our example above, we have chosen sts.lisajanedesigns.co.uk for our Federation service name and will specify the company name Lisa Jane Designs as the Display Name.
On the next page of the wizard we’ll continue by specifying a domain account with no special privileges for the AD FS service to run as. For most implementations we’ll choose to use the Windows Internal Database.
After installation completes, we will need to register the name of the AD FS service on the LAN.
Because the WAP server will need to resolve this on the internal LAN, we will configure a PinPoint DNS entry within our Active Directory DNS, as shown below to specify that sts.lisajanedesigns.co.uk resolves to the internal IP of the AD FS server.
If you aren’t familiar with PinPoint DNS zones, you can read more about them in my article Using PinPoint DNS Zones with Exchange 2010.
If the organization you implement the AD FS server within uses Split DNS instead, where there is both an internal DNS and external DNS servicing the same DNS zone, then you should add the record for your AD FS server within that internal DNS zone.
Installing the Web Application Proxy Role
After installing AD FS, we’ll need to install and configure the component that will sit within our perimeter network and publish Exchange to external clients. We will start by navigating to the Add Roles and Features Wizard within Server Manager, and selecting Remote Access:
Next, on the Server Role Services page, we will choose Web Application Proxy:
After the installation completes, we will choose Open the Web Application Proxy Wizard, as highlighted below:
Then, after the wizard launches, we will enter the internal name for the AD FS server we’ve just configured, along with administrative credentials, as shown below.
Our final step is to select the relevant SSL certificate to use for SSL connections to the Web Application Proxy.
In our example we will use the Wildcard certificate used earlier on our AD FS server:
After setup completes, our final step is to ensure that WAP is available to external clients by ensuring firewall exceptions are enabled, and that the DNS name used (in our case sts.lisajanedesigns.co.uk) is added to the external DNS zone with the external IP address that corresponds to WAP.
In the next part of this series we’ll examine how to perform simple publishing applicable to any supported version of Exchange.
If you would like to read the next part in this article series please go to Publishing and authenticating access to Exchange using AD FS and WAP (Part 2).
