Microsoft Exchange for Authentication via SAML
Hideez Enterprise Server – Integration of Hideez Server with Microsoft Exchange for Authentication via SAML
Last updated
Hideez Enterprise Server – Integration of Hideez Server with Microsoft Exchange for Authentication via SAML
Last updated
This guide provides step-by-step instructions for configuring ADFS (Active Directory Federation Services) as a Service Provider (SP) to enable authentication for OWA (Outlook Web App) and EAC (Exchange Admin Center). It outlines the process of using Hideez Server as an IdP for authentication in Microsoft Exchange via SAML.
Before proceeding, ensure the following components are already deployed and configured in your organization:
Active Directory (AD) is installed and configured.
Microsoft Exchange is operational and accessible.
A Certificate Authority (CA) is set up and configured.
Users can log in to Outlook Web App (OWA) via their browsers using Active Directory (AD) credentials.
All steps are performed by a user with Domain Admins and Enterprise Admins roles.
The ADFS server will be installed on a new, separate server within the Active Directory (AD) environment.
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:
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 Outlook on the web-relying party:
Outlook on the web
This is a trust for https://exch.lab.hideez.com/owa/
Leave the Configure Certificate window as unconfigured and click on Next:
Check the Enable support for the WS-Federation Passive protocol checkbox and Enter the URL of the Outlook on the web address (e.g https://exch.lab.hideez.com/owa/):
Add the URL of the Outlook on the web address for the Relying party trust identifier:
Select Permit everyone:
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:
Define a Relying Party Trust in AD FS for Outlook on the Web (OWA).
Create custom claim rules, such as the Pass-Through UPN Rule:
Claim Rule Name: Pass Through UPN
Incoming Claim Type: UPN
In the Edit Claim Issuance Policy for Outlook on the web window, click on Add Rule…:
Change the Pass Through or Filter an Incoming Claim and then click Next.
Enter the following configuration for the parameters:
Claim Rule Name: Pass Through UPN
Incoming Claim Type: UPN
Click Finish.
Click OK to close the window
You should see the new Outlook on the web Relying Party Trust created:
Please note that Steps 4, 5, and 6 are optional and are intended for publishing Outlook to the internet. If this has already been configured in your environment, you can proceed directly to step 7.
Use the AD FS Web Application Proxy to securely expose OWA for external access.
Repeat the steps for setting up a Relying Party Trust for the Exchange Admin Center (EAC).
Configure the Web Application Proxy for the Exchange Admin Center (EAC).
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:
Example:
This example uses the following values:
AD FS URL: https://adfs.lab.hideez.com/adfs/ls/
Outlook on the web URL: https://exch.lab.hideez.com/owa/
EAC URL: https://exch.lab.hideez.com/ecp/ecp/
AD FS token-signing certificate thumbprint: The ADFS Signing - exch.lab.hideez.com certificate that has the thumbprint value 7D533C61B531D056A0058BB0E2DDE4904E86FB7F.
For the Outlook on the web and EAC virtual directories, you need to configure AD FS authentication as the only available authentication method by disabling all other authentication methods.
You need to configure the EAC virtual directory before you configure the Outlook on the web virtual directory.
You'll likely want to configure AD FS authentication 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.
To use the Exchange Management Shell to configure an EAC or Outlook on the web virtual directory to only accept AD FS authentication, use the following syntax:
Restart Internet Information Services (IIS) on the Exchange server to apply the configuration changes.
Open IIS Manager on the Exchange server. An easy way to do this in Windows Server 2012 or later is to press Windows key + Q, type inetmgr, and select Internet Information Services (IIS) Manager in the results.
In IIS Manager, select the server.
In the Actions pane, click Restart.
Please refer to the official Microsoft documentation for instructions on how to restart IIS on an Exchange Server:
AD FS operates as an Identity Provider (IdP) by default but can be configured to function as a Service Provider (SP) when integrating with third-party IdPs like Hideez Server.
Open the AD FS Management Console.
Navigate to Claims Provider Trusts → Add Claims Provider Trust.
Upload the metadata XML file from the Hideez Server.
Assign a name to the Identity Provider (IdP), such as "Hideez IdP," then click Next, and finally, click Finish.
You will see newly created Claims Provider Trusts
Select the created Claims Provider Trust and click Edit Claim Rules → Add Rule.
Choose Pass Through or Filter an Incoming Claim and click Next.
Enter the following configuration:
Claim Rule Name: Pass Through UPN
Incoming Claim Type: UPN
Click Finish to save the rule.
Download metadata from AD FS:
Example of URL: https://adfs.lab.hideez.com/FederationMetadata/2007-06/FederationMetadata.xml
Find in the FederationMetadata.xml the following information:
entityID
AssertionConsumerService
Identify the required fields on the Hideez Server and save them:
Name: ADFS
Entity ID: http://<AssertionConsumerService>/adfs/services/trust
Assertion Consumer Service URL: https://<AssertionConsumerService>/adfs/ls/
Map the attributes: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
User Attribute: Email
Note: When configuring attributes in Hideez Server or Active Directory Federation Services (AD FS), the mapping values are constant. For your setup, they will remain the same as in the example provided.
Example of a Constant Value:
Mapping Attribute: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
User Attribute: Email
Example:
Name: ADFS
Issuer / SP Entity ID: http://adfs.lab.hideez.com/adfs/services/trust
Assertion Consumer Service: https://adfs.lab.hideez.com/adfs/ls/
Map the attributes: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
User Attribute: Email
Example Workflow:
The user navigates to OWA: https://exch.lab.hideez.com/owa/.
OWA redirects the user to AD FS for authentication.
AD FS forwards the request to the third-party IdP (e.g., Hideez Server).
The IdP validates the request and returns the SAML response to AD FS.
AD FS processes the claims and forwards them to OWA, completing the authentication
Additional Resources:
