Enable Microsoft Entra ID (Azure AD) SSO and MFA to Microsoft Outlook Web App (OWA) via Datawiza
This tutorial shows how to enable Microsoft Entra ID (Azure AD) Single Sign-On (SSO) and Multi-Factor Authentication (MFA) for an Microsoft Outlook Web App (OWA) using Datawiza Access Proxy.
Benefits of integrating applications with Azure AD using DAP include:
- Proactive security with Zero Trust through Azure AD SSO, Azure AD Multi-Factor Authentication and Conditional Access.
- Easy authentication and authorization in Azure AD with no-code Datawiza. Use of web applications such as: Oracle JDE, Oracle E-Business Suite, Oracle Sibel, Oracle Peoplesoft, and home-grown apps.
- A single control plane, Datawiza Cloud Management Console, to manage access to applications in public clouds and on-premise.
This document focuses on solving the problem when modern identity providers integrate with the legacy Outlook Web App. Our approach to integration relies on the fact that Outlook Web App supports kerberos authentication, which requires a kerberos token to identify a user.
In many cases, legacy applications have great difficulty integrating modern SSO, mainly due to the absence of modern protocol support.
The Datawiza no-code proxy-based solution effectively reduces the cost of integration, fills the gap, and significantly improves application security.
The solution has the following components:
- Azure AD : The Microsoft cloud-based identity and access management service, which helps users sign in and access external and internal resources.
- Datawiza Access Proxy (DAP): A lightweight container-based reverse-proxy that implements OpenID Connect (OIDC), OAuth, or Security Assertion Markup Language (SAML) for user sign-in flow. It transparently passes identity to applications through HTTP headers.
- Datawiza Cloud Management Console (DCMC): A centralized console to manage DAP. DCMC has UI and RESTful APIs for administrators to configure Datawiza Access Proxy and access control policies.
- Exchange Server (OWA): the legacy application to be protected by Azure AD.
- Domain Controller: a server that manages user authentication and access to network resources in a Windows-based network.
- Key Distribution Center (KDC): KDC is used to securely distribute and manage secret keys and tickets in a Kerberos authentication system.
- The user requests access to a DAP-protected OWA.
- DAP redirects the user's browser to Azure AD
- Azure AD presents its login page to the user.
- The user submits their credentials to Azure AD
- Upon successful authentication, Azure AD redirects the user's browser to DAP.
- DAP communicates with Azure AD to exchange tokens
- Azure AD issues the user's username and relative information to DAP.
- DAP accesses the predefined KDC with credentials to request a Kerberos ticket.
- KDC returns a Kerberos ticket.
- DAP redirects the user's browser to Outlook Web App.
- Outlook Web App presents the requested protected OWA resource to the user.
Subsequent requests from the user's browser will contain the kerberos token, enabling access to OWA via DAP.
Prior Datawiza Access Proxy experience isn’t necessary, but you need:
- An Azure subscription. If you don't have one, you can get an Azure free account
- An Azure AD tenant linked to the Azure subscription.
- Install Docker and Docker Compose
- User identities synchronized from an on-premises directory to Azure AD, or created in Azure AD and flowed back to an on-premises directory.
- An account with Azure AD and the Application administrator role
- An existing Exchange Server environment. Supported versions:
- Microsoft IIS IWA: IIS 7 or later
- Microsoft OWA IWA: IIS 7 or later
- You have a Windows server configured with IIS application and Active Directory Services running as a Domain Controller (DC) and implementing Kerberos (IWA) SSO. This is an example architecture, as it would be unusual in large production environments to have an application server (IIS) also be a DC.
- (Optional) An SSL web certificate to publish services over HTTPS. You can also use default Datawiza self-signed certs for testing.
Enable Kerberos Authentication for Outlook Web Access
Open the Exchange Administrative Center
Login to the admin center, click on Servers and select the Virtual Directories tab
Select server and then double click on the OWA Virtual Directory and select the applications tab.
On the authentication tab, select Use one or more standard authentication methods , select Integrated Windows authentication , and click save.
Open a command prompt.
Create a Service Account
Datawiza Access Proxy requires a set of known Windows credentials, which will be used by the instance to configure the Kerberos service. We refer to this user as the Datawiza Access Proxy service account.
Return to or sign in to your Windows server.
Start the Active Directory Users and Computers application.
Select the appropriate instance for Datawiza Access Proxy, in this example
datawizatest.com, and then Users > New User.
Create a new user and click Next. For example:
Property Value First name dap Last name service User logon name dap
Specify an appropriate password.
Ensure that you check the boxes User cannot change password and Password never expires, then click Next.
In the final New Object - User dialog box, click Next.
Right click the new user and show properties and note the following properties:
Property Value Last name firstname.lastname@example.org Pre windows 2000 prefix DATAWIZATEST
Create a Service Principal Name (SPN) for the Service Account
- Before you can create the SPN, you can List all SPNs and check if the http SPN is among them.
setspn -Q */<domain.com>
- Register the host SPN for the account using the following syntax on the Windows command line:
setspn -A host/dap.<domain.com> dap
host/dap.<domain.com> represents the unique service principal name, and
dap corresponds to the service account you previously created. It is crucial to include this service principal name to enable the configuration of constrained delegation in the next step. Without it, you won't be able to proceed with the delegation setup.
Configure Windows Server IIS for Constrained Delegation
Login to one of your domain controllers and open up Active Directory Users and Computers.
Find the Users object within your organization, find the service account you just created and right click Properties on it.
Select the Delegation tab, select Trust this computer for delegation to specified services only , check Use any authentication protocol , and click on Add....
Select Users or Computers....
Type in the machine name and click OK.
Select http and click OK.
Click OK on the Add Services page.
Getting started with DAP
To integrate Microsoft OWA:
Sign in to Datawiza Cloud Management Console.
The Welcome page appears.
Select the orange Getting started button.
In the Name and Description fields, enter the relevant information.
On the Add Application dialog, use the following values:
Property Value Platform Web App Name Enter a unique application name. Public Domain For example:
https://owa.example.com. For testing, you can use localhost DNS. If you aren't deploying DAP behind a load balancer, use the Public Domain with the port.
Listen Port The port that DAP listens on. Upstream Servers The URL and port combination of the OWA Implementation is being protected. Mine is
On the Configure IdP dialog, enter the relevant information.
DCMC has one-click integration to help complete Azure AD configuration. DCMC calls the Microsoft Graph API to create an application registration on your behalf in your Azure AD tenant.
Note Down a Docker-Compose File
Once clicking on the Create button, the basic configuration on the management console is finished. You will see the final step of the guide, which presents you with a page showing the simple steps to deploy Datawiza Access Proxy with your application. Note down the docker-compose file of your deployment. The file includes the image of the Datawiza Access Proxy and a pair of PROVISIONING_KEY and PROVISIONING_SECRET, which are used by DAP to pull the latest configuration and policies from DCMC.
Go to the application detail you just created and click the Advanced tab. Find the Kerberos sub tab.
Configure the kerberos settings with the following values:
- Kerberos Realm: A realm where the Kerberos database is stored or the active directory domain. In this example, it is
- SPN: The Service Principal Name of your OWA application. Please note, it is not the same spn you created at the previous step. In this example, it is
- Delegated Login Identity: This enables you to define the delegated identity to be sent for authentication in your on premises Active Directory when there is a disparity between user login identities. I use
- KDC: IP of a Domain Controller (Or FQDN if DNS is configured & efficient). I use
- Service Account: The service account you created before. Mine is
- Auth Type: Choose password in this example. If you prefer to use keytab instead of password, you can choose keytab option rather than password here.
- Password: The password for the service account.
Select the Advanced tab.
Select Enable SSL.
From the Cert Type dropdown, select a type.
For testing purposes, we'll be providing a self-signed certificate.
You have the option to upload a certificate from a file.
(Optional) Enable MFA on Microsoft Entra ID (Formerly Azure AD)
To provide an extra level of security for sign-ins, sometimes you might want to enforce MFA for user sign-in. There are several ways to achieve this. The simplest and easiest way is to enable MFA on the Azure portal.
- Sign in to the Azure portal as a Global Administrator.
- Select Microsoft Entra ID > Manage > Properties.
- Under Properties , click the Manage security defaults.
- Under Enable Security defaults, select Yes and then Save.
Kerberos authenticate failed: Missing target hostname
The potential causes could include the unreachability of the KDC address by DAP, DAP's inability to resolve the hostname of KDC, or the presence of an
@ symbol in the service account password.
Kerberos authenticate failed: S4U2proxy failed! Error Name: KDC_ERR_S_PRINCIPAL_UNKNOWN Detail: "Server not found in Kerberos database"
The provided SPN is not correct.
According to this example of the screenshot, it should be
Kerberos authenticate failed: Preauth failed! Error Name: KDC_ERR_PREAUTH_FAILED Detail: "Pre-authentication information was invalid"
The provided password is not correct.
Missing @ sign of user
The authentication username should include the
@ symbol, signifying that it should be in the form of an email, like
email@example.com. In this context,
datawizatest.com serves as the Azure Realm or Domain.
In this article, you learned how to:
- Configure and Deploy the Datawiza Access Proxy
- Integrate the Datawiza Access Proxy with OWA
- Enable Azure AD SSO login and MFA for OWA