It’s over a year now since the last Outlook Web App article about integrating OWA with ADFS. In that post we explored the use of claims-based authentication with OWA in a Proof of Concept using WIF 3.5 and FedUtil. This was an unsupported setup in Microsoft eyes and, in the meantime, with the release of Windows Server 2012 R2, opportunities for supporting Exchange web applications such as OWA,  have arisen. The first, provided support via the use of a non-claims aware web application in AD FS R2 using Kerberos Constrained Delegation (KCD), utilizing the new Web Application Proxy (WAP) feature. The recent release of Exchange 2013 SP1 further expands OWA support, including native support for AD FS in the Exchange product, with claims-based authentication now possible for Outlook Web App (OWA) and the Exchange Admin Center (EAC).

To get started, I’ll refer you to a Technet article here that provides a step-by-step. I used this article as a starting point for setting up OWA/EAC with AD FS R2. These two application endpoints in Exchange (OWA and ECP) need to be represented as relying parties within AD FS.

Here’s an excerpt of the PowerShell rules required for creating the RPs:

Add-ADFSRelyingPartyTrust -Name “Outlook Web App” -Enabled $true -Notes “This is a trust for https://mail.mydomain.com/owa” -WSFedEndpoint https://mail.mydomain.com/owa -Identifier https://mail.mydomain.com/owa -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

Add-ADFSRelyingPartyTrust -Name “Exchange Admin Center (EAC)” -Enabled $true -Notes “This is a trust for https://mail.mydomain.com/ecp” -WSFedEndpoint https://mail.mydomain.com/ecp -Identifier https://mail.mydomain.com/ecp -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

The AD User and Group SIDs, together with UPN also need to be defined for each of the Exchange Relying Party applications in the form of custom claims rules: Windows Account Name (sAMAccountName)

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”), query = “;objectSID;{0}”, param = c.Value);

Group SID (enumarate group membership)

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”), query = “;tokenGroups(SID);{0}”, param = c.Value);

User Principal Name (UPN)

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”), query = “;userPrincipalName;{0}”, param = c.Value);

On the Exchange side, via PowerShell, we specify the Relying Party Identifiers via the AdfsAudienceUris parameter and must also provide the token signing certificate thumbprint from the AD FS server.

$uris = @(“https://mail.mydomain.com/owa”,”https://mail.mydomain.com/ecp”) Set-OrganizationConfig -AdfsIssuer “https://adfs.contoso.com/adfs/ls/” -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint “TOKEN SIGNING CERTIFICATE THUMBPRINT”

Don’t forget to import the token signing certificate into the Trusted Root Certificate Authorities container of your Exchange servers, otherwise you may fall foul of the following error logging on to your mailbox.

The source in pinpointing the problem here, lies in the query string of the error message https://external.mydomain.com/owa/auth/errorfe.aspx?msg=WrongAudienceUriOrBadSigningCert.

In this (my) case, the token signing certificate had not been added to the Exchange servers as a trusted cert. Equally, the wrong Audience URI can present a configuration problem. It commonly arises when a unnecessary trailing slash is added to the Relying Party Identifier when configuring in AD FS, e.g. https://mail.mydomain.com/owa/. s something to keep an eye on. The correct RP identifier would be https://mail.mydomain.com/owa.

I’ve not yet tested setting up Exchange 2013 SP1 under AD FS 2.0, but there’s nothing untoward going on here to suggest that using it as your identity provider is not possible. If you’re running under AD FS Windows Server 2012 R2 then the Web Application Proxy (WAP) adopts the proxy role for external access scenarios and also supports host name translation. For example, I make use of https://external.mydomain.com as an external URL and map this to the internal name of https://mail.mydomain.com. Be aware that matching of path-based names is not supported in the current release of the WAP, so mixing path names between externally and internally published resources is a no-no.

To illustrate this, let’s look at an example of an OK configuration:

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://mail.mydomain.com/owa/’ -ExternalCertificateThumbprint ‘DD94E2ABAA123C6B6009CB42F16CE892AF96A47C’ -ExternalUrl ‘https://external.mydomain.com/owa/’ -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Outlook Web App’

Whereas, this is a non-workable configuration.

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://mail.mydomain.com/owa/’ -ExternalCertificateThumbprint ‘DD94E2ABAA123C6B6009CB42F16CE892AF96A47C’ -ExternalUrl ‘https://external.mydomain.com/mail/’ -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Outlook Web App’

Note the use  in publishing of the same literal path  https://external.mydomain.com/owa/ in the first example, versus a rewritten one in the second https://external.mydomain.com/mail/.

If you’re contemplating the use of AD FS 2.0, then clearly host-name translation is not something that the AD FS 2.0 proxy brings to the table. Alternatively, a suitably equipped front-end load balancer may also fulfill that role.

On the subject of load balancers, this rather conveniently brings me back to new features in AD FS R2. Server Name Indication (SNI) was mentioned in the “First Looks” articles about AD FS R2 and it’s worth checking that your current load balancer/reverse proxy in front of AD FS supports SNI and is supported/enabled on the device concerned. This is becoming a pain point for many, as evidenced by various posts on the Technet forums. The move to kernel-mode (HTTP.SYS) in R2 mandates the use of SNI. Therefore, it’s worthwhile checking that:

• your friendly neighbourhood load balancer/device in front of AD FS supports SNI
• clients and user agents support SNI and you’re not inadvertently locking them out
• (08/04) SSL termination endpoints (e.g. load balancer / 3rd-party reverse proxies) in front of AD FS  may be affected by the recent heartbleed bug (http://heartbleed.com), exposing vulnerable OpenSSL libraries and certificates used on those devices. Microsoft infrastructure, employing Secure Channel (SChannel)  not affected, may inadvertently become so through SSL termination endpoints on the aforementioned devices in front of AD FS. More information can also be found here (http://www.kb.cert.org/vuls/id/720951)

Accessing the OWA URL, via https://external.mydomain.com/owa and the OWA Relying Party redirects the user to AD FS for logon. In a default AD FS R2 configuration, this equates to forms-based authentication for external users.

Users accessing OWA internally, access https://mail.mydomain.com via the farm using Integrated Windows Authentication (IWA). As usual when connecting to the farm, the URL for the federation service needs to be added to the Local Intranet Zone within IE and any corresponding configuration changes made to support Kerberos for other browsers.

At this point, optional use of a clams provider (connecting to the local AD) or an MFA provider in R2 could also come into play to provide stronger authentication, should it be required. Having successfully authenticated via AD FS, we gain access to the user mailbox.

The Exchange Control Panel (ECP) was also configured as a relying party within AD FS and within the Exchange configuration. Accessing the Exchange Admin Center remotely, with the Exchange Organization Administrator mylo, we can see the gamut of administrative console options available under federated logon.

This is one of those scenarios where it might be a good idea to apply stronger authentication (MFA)  to privileged user accounts when accessing the Exchange Admin Center. We can do this by applying policy-based access on the AD FS R2 server.

In the next post, I’ll be taking a look at strong authentication access scenarios using ActiveSync and Lync (primarily with mobile clients), before completing Part 3 of the First Looks series of AD FS R2.