I’ve recently worked with a client who had no plans to move away from their on-premise Exchange Server 2019 due to regulations they had to abide to and was interested in leveraging their on-premise AD FS (Active Directory Federation Server) for clients to use claims-based authentication to connect to Outlook on the Web (OWA) and Exchange admin center (EAC). Those who have attempted to integrated 2FA solutions such as Duo, SecurEnvoy, or RSA know how cumbersome the process for configuring OWA or ECP can be and the additional amount of administrative overhead it adds to tasks such as patching the Exchange servers. Using AD FS effectively allows the client to require the 2FA provided by AD FS without affecting the Exchange servers. This post serves to demonstrate the process of configuring AD FS claims-based authentication with Outlook on the web and Exchange admin center.
Server Requirements
Configuring AD FS claims-based authentication for Outlook on the web and the EAC in Exchange Server involves the following additional servers:
- A Windows Server 2012 or later domain controller (Active Directory Domain Services server role).
- A Windows Server 2012 or later AD FS server (Active Directory Federation Services server role). Windows Server 2012 uses AD FS 2.1, and Windows Server 2012 R2 uses AD FS 3.0.
- You need to be a member of the Domain Admins, Enterprise Admins, or local Administrators security group to install AD FS, and to create the required relying party trusts and claim rules on the AD FS server.
- Optionally, a Windows Server 2012 R2 or later Web Application Proxy server (Remote Access server role, Web Application Proxy role service).
- Web Application Proxy is a reverse proxy server for web applications that are inside the corporate network. Web Application Proxy allows users on many devices to access published web applications from outside the corporate network.
- Although Web Application Proxy is typically recommended when AD FS is accessible to external clients, offline access in Outlook on the web isn't supported when using AD FS authentication through Web Application Proxy.
- You need to deploy and configure the AD FS server before you configure the Web Application Proxy server, and you can't install Web Application Proxy on the same server where AD FS is installed.
This post will not include instructions for deploying an AD FS farm as I have already written posts in the past and they can found here:
Deploying a redundant Active Directory Federation Services (ADFS) farm on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory.html
Deploying a redundant Active Directory Federation Services (ADFS) Web Application Proxy servers on Windows Server 2019
http://terenceluk.blogspot.com/2020/04/deploying-redundant-active-directory_21.html
Before I begin with the steps, note that the official Microsoft deployment documentation can be found here:
Use AD FS claims-based authentication with Outlook on the web
https://docs.microsoft.com/en-us/exchange/clients/outlook-on-the-web/ad-fs-claims-based-auth?view=exchserver-2019
Step #1 - Export ADFS Signing Certificate and Import to Exchange Servers
The AD FS server uses a token-signing certificate for encrypted communication and authentication between the AD FS server, Active Directory domain controllers, and Exchange servers. This self-signed certificate is automatically copied over to the Web Application Proxy server during the installation, but is required to be manually imported into the Trusted Root Certificate store on all of the Exchange servers in the organization.
To export the certificate, log onto the AD FS server, launch the AD FS Management Console, navigate to AD FS > Service > Certificate:
Select the certificate listed under Token-signing, right click and select on View Certificate…:
The general properties of the certificate will be displayed:
Proceed and navigate to the Details tab and click on the Copy to File… button:
Go through the Certificate Export Wizard to export the certificate:
Select DER encoded X.509 (.CER) format and proceed with the export:
Proceed to import the certificate into the Trusted Root Certificate store on all of the Exchange servers in the organization
Also note that this self-signed token-signing certificate is only valid for one year and while the AD FS server will automatically renew and replace its own self-signed certificates before they expire, you will need to re-export and import the certificate back onto the Exchange servers. If the certificate expiration period is deemed to be too short for the organization then the period can be extended by using the following PowerShell cmdlet on the AD FS server:
Set-AdfsProperties -CertificateDuration <Days> (the default value is 365)
Step #2 – Create a relying party trust and custom claim rules in AD FS for OWA (Outlook on the web)
With the AD FS prerequisites configured, proceed to create the relying party trust for OWA (Outlook on the web) on the AD FS server by launching the AD FS Management console:
Navigate to AD FS > Relying Party Trusts and click on Add Relying Party Trusts…:
Select Claims aware and click on Start:
Change the default Import data about the relying party published online or on a local network to Enter data about the relying party manually:
Enter the Display name and Notes for the Outlook on the web relying party:
Outlook on the web
This is a trust for https://mail.contoso.com/owa
Leave the Configure Certificate window as unconfigured and click on Next:
Check the Enable support for the WS-Federation Passive protocol checkbox:
Enter in the URL of the Outlook on the web address (e.g. https://mail.contoso.com/owa/):
Add the URL of the Outlook on the web address for the Relying party trust identifier:
The AD FS server in this environment already had Duo MFA configured so this example will select Permit everyone and require MFA:
On the Ready to Add Trust page, review the settings, and then click Next to save the relying party trust information:
Leave the Configure claims issuance policy for this application checked and click Close:
Step #3 – Create custom claim rules in AD FS for Outlook on the web
The following two claim rules will be created for the Outlook on the web relying party trust:
- Active Directory user SID
- Active Directory UPN
In the Edit Claim Issuance Policy for Outlook on the web window, click on Add Rule…:
Change the Claim rule template to Send Claims Using a Custom Rule and then click Next:
Enter the following configuration for the parameters and ten click Finish.
Claim rule name:
ActiveDirectoryUserSID
Custom rule:
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);
Click Add Rule… again to create a new rule:
Change the Claim rule template to Send Claims Using a Custom Rule and then click Next:
Enter the following configuration for the parameters and ten click Finish.
Claim rule name:
ActiveDirectoryUPN
Custom rule:
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);
Click OK to close the window after the following 2 rules are created:
You should see the new Outlook on the web Relying Party Trust created:
Step #4 – Configure AD FS Web Application Proxy Server to publish Outlook on the Web
If users are going to access OWA from the internet then it will be necessary to publish the newly created Outlook on the web relying party trust on the AD FS Web Application Proxy. Begin by launching the Remote Access Management Console on the AD FS WAP server and navigating to the Published Web Applications context then click on Publish:
Click Next:
Select Active Directory Federation Services (AD FS) and click Next:
Select Web and MSOFBA for the type of preauthentication to perform for this application and click Next:
The configured relying party trusts will be listed, select the Outlook on the web relying party trust that we created and click Next:
Fill in a name for the web application (e.g. Outlook on the web) then the URLs for OWA access, the certificate used for securing traffic and then click Next:
A display of the PowerShell cmdlet used to create the we application will be displayed. Proceed by clicking on Publish:
The wizard will display the results of publishing the application when completed:
The newly published Outlook on the web application should now be displayed:
Step #5 – Create a relying party trust and custom claim rules in AD FS for EAC (Exchange admin center)
The steps for creating a relying party trust and custom claim rules in AD FS for EAC is exactly the same as OWA and the only change is the URL (e.g. https://mail.contoso.com/ecp instead of https://mail.contoso.com/owa). Repeat the same steps as above for the EAC.
Step #6 – Configure AD FS Web Application Proxy Server to publish Exchange admin center
The steps to configure the AD FS Web Application Proxy Server to publish Exchange admin center is exactly the same as the Outlook on the web and the only change is the URL. Repeat the steps above for the EAC.
Step 6: Configure the Exchange organization to use AD FS authentication
There is no way to configure the Exchange organization to use AD FS authentication within the GUI so begin by launching the Exchange Management Shell from one of the Exchange servers.
The cmdlet to configure the Exchange organization to use AD FS for authentication is as follows:
Set-OrganizationConfig -AdfsIssuer https://<FederationServiceName>/adfs/ls/ -AdfsAudienceUris "<OotwURL>","<EACURL>" -AdfsSignCertificateThumbprint "<Thumbprint>"
Note that the following are the parameters for the cmdlet above:
- AD FS URL (e.g. https://adfs.contoso.com/adfs/ls/)
- Outlook on the web URL (https://mail.contoso.com/owa/)
- EAC URL (e.g. https://mail.contoso.com/ecp/)
- AD FS token-signing certificate thumbprint which is the ADFS Signing
The first 3 URLs should be self-explanatory, while the last parameter is the thumbprint value of the imported AD FS token signing certificate performed in Step #1. Run the following cmdlet on the Exchange server to find the thumbprint value of the imported AD FS token signing certificate:
Set-Location Cert:\LocalMachine\Root; Get-ChildItem | Sort-Object Subject
You can also confirm this thumbprint value on the AD FS server in an elevated Windows PowerShell window by running the command Import-Module ADFS, and then running the command Get-AdfsCertificate -CertificateType Token-Signing or just running Get-AdfsCertificate -CertificateType Token-Signing cmdlet the on the AD FS server:
It would be a good idea to execute the Set-OrganizationConfig before the Set-OrganizationConfig to verify that there hasn’t been any ADFS configuration configured for the organization as shown in the following screenshot:
Get-OrganizationConfig | FL *adfs*
Having verified the Exchange organization does not have any ADFS configuration, execute the cmdlet with the environment’s settings:
Set-OrganizationConfig -AdfsIssuer https://adfs.contoso.com/adfs/ls/ -AdfsAudienceUris "https://mail.contoso.com/owa/","https://mail.contoso.com/ecp/" -AdfsSignCertificateThumbprint " 75FC78640C9C7F1BDB2B0ADD7E7E2FB8A9159160"
Execute Get-OrganizationConfig | FL *adfs* to verify that the configuration has been applied:
Step #7 – Configure AD FS authentication on the Outlook on the web and EAC virtual directories
The last step required so that Outlook on the web and EAC redirects authentication to ADFS is to configure AD FS authentication as the only available authentication method and disabling all other authentication methods. The following are additional requirements and recommendations:
- The EAC virtual directory needs to be configured before the Outlook on the web virtual directory.
- AD FS authentication can be configured only on Internet-facing Exchange servers that clients use to connect to Outlook on the web and the EAC.
- By default, only Basic and Forms authentication are enabled for the Outlook on the web and EAC virtual directories.
The following is the cmdlet to configure the EAC or Outlook on the web virtual directory to only accept AD FS authentication:
Set-EcpVirtualDirectory -Identity <VirtualDirectoryIdentity> -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
**Note that the documentation indicates we should include the following switch:
-OAuthAuthentication $false
However, I’ve noticed that Exchange 2019 does not accept it:
[PS] C:\>Set-EcpVirtualDirectory -Identity "OSMIUM\ecp (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false
A parameter cannot be found that matches parameter name 'OAuthAuthentication'.
+ CategoryInfo : InvalidArgument: (:) [Set-EcpVirtualDirectory], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Set-EcpVirtualDirectory
+ PSComputerName : osmium.bma.local
[PS] C:\>
I’ve been able to successfully configure claims-based authentication without settings this parameter so it should be safe to omit.
It would be a good idea to review what the current configuration is for the two directories with the following Get-EcpVirtualDirectory and Get-OwaVirtualDirectory cmdlet prior to performing the changes:
Get-EcpVirtualDirectory -Identity "svr-mail-01\ecp (Default Web Site)" | FL AdfsAuthentication,BasicAuthentication,DigestAuthentication,FormsAuthentication,OAuthAuthentication,WindowsAuthentication
Get-OwaVirtualDirectory -Identity "svr-mail-01\owa (Default Web Site)" | FL AdfsAuthentication,BasicAuthentication,DigestAuthentication,FormsAuthentication,OAuthAuthentication,WindowsAuthentication
Get-EcpVirtualDirectory -Identity "svr-mail-01\ecp (Default Web Site)" | FL *auth*
Get-OwaVirtualDirectory -Identity "svr-mail-01\owa (Default Web Site)" | FL *auth*
Repeat the same for other Exchange servers if there are more than one in the environment.
Once the current settings have been reviewed, execute the cmdlet to configure the EAC:
Set-EcpVirtualDirectory -Identity "OSMIUM\ecp (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
Execute the cmdlet to configure the OWA:
Set-OwaVirtualDirectory -Identity "OSMIUM\owa (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false
Once the directories are set, use the get cmdlets to review the settings:
If there are more than 1 server in the environment, use the following cmdlet to set all the servers:
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false
Step #8 – Restart IIS on the Exchange servers
Complete the changes by restarting IIS on the Exchange servers by executing the following cmdlets:
net stop was /y
An output similar to the following will be displayed:
[PS] C:\>net stop was /y
The following services are dependent on the Windows Process Activation Service service.
Stopping the Windows Process Activation Service service will also stop these services.
World Wide Web Publishing Service
Net.Tcp Listener Adapter
Net.Pipe Listener Adapter
Net.Msmq Listener Adapter
The World Wide Web Publishing Service service is stopping.....................................
The World Wide Web Publishing Service service was stopped successfully.
The Net.Tcp Listener Adapter service is stopping.
The Net.Tcp Listener Adapter service was stopped successfully.
The Net.Pipe Listener Adapter service is stopping.
The Net.Pipe Listener Adapter service was stopped successfully.
The Net.Msmq Listener Adapter service is stopping.
The Net.Msmq Listener Adapter service was stopped successfully.
The Windows Process Activation Service service is stopping.
The Windows Process Activation Service service was stopped successfully.
[PS] C:\>
Lastly, execute the following for the World Wide Web Publishing Service:
net start w3svc
Authentication for both EAC and OWA should now be directed to the AD FS portal.
