Configure Datawiza Access Proxy for Microsoft Entra single sign-on and multifactor authentication for Outlook Web Access
In this tutorial, learn how to configure Datawiza Access Proxy (DAP) to enable Microsoft Entra single sign-on (SSO) and Microsoft Entra multifactor authentication for Outlook Web Access (OWA). Help solve issues when modern identity providers (IdPs) integrate with legacy OWA, which supports Kerberos token authentication to identify users.
Often, legacy app and modern SSO integration are a challenge because there's no modern protocol support. Datawiza Access Proxy removes the protocol support gap, reduces integration overhead, and improves application security.
Integration benefits:
Improved Zero Trust security with SSO, MFA, and Conditional Access:
No-code integration with Microsoft Entra ID and web apps:
OWA
Oracle JD Edwards
Oracle E-Business Suite
Oracle Siebel
Oracle PeopleSoft
Your apps
See, Easy authentication and authorization in Microsoft Entra ID with no-code Datawiza
Use the Datawiza Cloud Management Console (DCMC) to manage access to cloud and on-premises apps:
- Go to login.datawizwa.com to sign in or sign up for an account
Architecture
DAP integration architecture includes the following components:
Microsoft Entra ID - identity and access management service that helps users sign in and access external and internal resources
OWA - the legacy, Exchange Server component to be protected by Microsoft Entra ID
Domain controller - a server that manages user authentication and access to network resources in a Windows-based network
Key distribution center (KDC) - distributes and manages secret keys and tickets in a Kerberos authentication system
DAP - a reverse-proxy that implements OpenID Connect (OIDC), OAuth, or Security Assertion Markup Language (SAML) for user sign in. DAP integrates with protected applications by using:
HTTP headers
Kerberos
JSON web token (JWT)
other protocols
DCMC - the DAP management console with UI and RESTful APIs to manage configurations and access control policies
The following diagram illustrates a user flow with DAP in a customer network.
The following diagram illustrates the user flow from user browser to OWA.
| Step | Description |
|---|---|
| 1. | User browser requests access to DAP-protected OWA. |
| 2. | The user browser is directed to Microsoft Entra ID. |
| 3. | The Microsoft Entra sign-in page appears. |
| 4. | The user enters credentials. |
| 5. | Upon authentication, the user browser is directed to DAP. |
| 6. | DAP and Microsoft Entra ID exchange tokens. |
| 7. | Microsoft Entra ID issues the username and relevant information to DAP. |
| 8. | DAP accesses the KDC with credentials. DAP requests a Kerberos ticket. |
| 9. | KDC returns a Kerberos ticket. |
| 10. | DAP redirects the user browser to OWA. |
| 11. | The OWA resource appears. |
Note
Subsequent user browser requests contain the Kerberos token, which enables access to OWA via DAP.
Prerequisites
You need the following components. Prior DAP experience isn't necessary.
An Azure account
- If you don't have one, get an Azure free account
A Microsoft Entra tenant linked to the Azure account
Docker and Docker Compose are required to run DAP
See, Get Docker
See, Install Docker Compose, Overview
User identities synchronized from an on-premises directory to Microsoft Entra ID, or created in Microsoft Entra ID and flowed back to your on-premises directory
An account with Microsoft Entra Application Administrator permissions
- See, Application Administrator and other roles on, Microsoft Entra built-in roles
An Exchange Server environment. Supported versions:
Microsoft IIS Integrated Windows Authentication (IWA) - IIS 7 or later
Microsoft OWA IWA - IIS 7 or later
A Windows Server instance configured with IIS and Microsoft Entra services running as a domain controller (DC) and implementing Kerberos (IWA) SSO
- It's unusual for large production environments to have an application server (IIS) that also functions as a DC.
Optional - an SSL Web certificate to publish services over HTTPS, or DAP self-signed certificates, for testing.
Enable Kerberos authentication for OWA
Sign in to the Exchange admin center.
In the Exchange admin center, left navigation, select servers.
Select the virtual directories tab.
From the select server dropdown, select a server.
Double-click owa (Default Web Site).
In the Virtual Directory, select the authentication tab.
On the authentication tab, select Use one or more standard authentication methods, and then select Integrated Windows authentication.
Select save
Open a command prompt.
Execute the iisreset command.
Create a DAP service account
DAP requires known Windows credentials that are used by the instance to configure the Kerberos service. The user is the DAP service account.
Sign in to the Windows Server instance.
Select Active Directory Users and Computers.
Select the DAP instance down-arrow. The example is datawizatest.com.
In the list, right-click Users.
From the menu, select New, then select User.
On New Object--User, enter a First name and Last name.
For User logon name, enter dap.
Select Next.
In Password, enter a password.
Enter it again in Confirm.
Check the boxes for User cannot change password and Password never expires.
Select Next.
Right-click the new user to see the configured properties.
Create a service principal name for the service account
Before you create the service principal name (SPN), you can list SPNs and confirm the http SPN is among them.
Use the following syntax on the Windows command line to list SPNs.
setspn -Q \*/\<**domain.com**Confirm the http SPN is among them.
Use the following syntax on the Windows command line to register the host SPN for the account.
setspn -A host/dap.datawizatest.com dap
Note
host/dap.datawizatest.com is the unique SPN, and dap is the service account you created.
Configure Windows Server IIS for Constrained Delegation
Sign in to a domain controller (DC).
Select Active Directory Users and Computers.
In your organization, locate and select the Users object.
Locate the service account you created.
Right-click the account.
From the list, select Properties.
Select the Delegation tab.
Select Trust this user for delegation to specified services only.
Select Use any authentication protocol.
Select Add.
On Add Services, select Users or Computers.
In Enter the object names to select, type in the machine name.
Select OK
On Add Services, in Available services, under Service Type, select http.
Select OK
Integrate OWA with Microsoft Entra ID
Use the following instructions to integrate OWA with Microsoft Entra ID.
Sign in to the Datawiza Cloud Management Console (DCMC).
The Welcome page appears.
Select the orange Getting started button.
Deployment Name
On Deployment Name, type a Name and a Description.
Select Next.
Add Application
On Add Application, for Platform, select Web.
For App name, enter the app name. We recommend a meaningful naming convention.
For Public Domain, enter the app's external-facing URL. For example,
https://external.example.com. Use localhost DNS for testing.For Listen Port, enter the port DAP listens on. If DAP isn't deployed behind a load balancer, you can use port indicated in Public Domain.
For Upstream Servers, enter the OWA implementations' URL and port combination.
Select Next.
Configure IdP
DCMC integration features help complete Microsoft Entra configuration. Instead, DCMC calls Microsoft Graph API to perform the tasks. The feature reduces time, effort, and errors.
On Configure IdP, enter a Name.
For Protocol, select OIDC.
For Identity Provider, select Microsoft Entra ID.
Enable Automatic Generator.
For Supported account types, select Account in this organizational directory only (Single tenant).
Select Create.
A page appears with deployment steps for DAP and the application.
See the deployment's Docker Compose file, which includes an image of the DAP, also PROVISIONING_KEY and PROVISIONING_SECRET. DAP uses the keys to pull the latest DCMC configuration and policies.
Configure Kerberos
On your application page, select Application Detail.
Select the Advanced tab.
On the Kerberos sub tab, enable Kerberos.
For Kerberos Realm, enter the location where the Kerberos database is stored, or the Active Directory domain.
For SPN, enter the OWA application's service principal name. It's not the same SPN you created.
For Delegated Login Identity, enter the applications external-facing URL. Use localhost DNS for testing.
For KDC, enter a domain controller IP. If DNS is configured, enter a fully qualified domain name (FQDN).
For Service Account, enter the service account you created.
For Auth Type, select Password.
Enter a service account Password.
Select Save.
SSL configuration
On your application page, select the Advanced tab.
Select the SSL subtab.
Select Edit.
Select the option to Enable SSL.
From Cert Type, select a certificate type. You can use the provided self-signed localhost certificate for testing.
Select Save.
Optional: Enable Microsoft Entra multifactor authentication
Tip
Steps in this article might vary slightly based on the portal you start from.
To provide more sign-in security, you can enforce Microsoft Entra multifactor authentication. The process starts in the Microsoft Entra admin center.
- Sign in to the Microsoft Entra admin center as a Application Administrator.
- Browse to Identity > Overview > Properties tab.
- Under Security defaults, select Manage security defaults.
- On the Security defaults pane, toggle the dropdown menu to select Enabled.
- Select Save.
Next steps
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for