Securing & using SSO for OWA & ECP with the Azure App Proxy
This blog is a follow-up on the blog I wrote earlier about forcing Outlook for Mobile and using App Protection Policies: https://www.patrickvanbemmelen.nl/how-to-force-outlook-for-mobile-and-use-app-protection-policies/
When you have a hybrid setup one of the possible ways to further secure your mail environment is by using the Azure Application Proxy included in Azure AD P1 or higher.
This will allow you to use all the controls Azure AD (Enterprise Apps) gives you like using Conditional Access, publishing OWA in the My Apps portal and using SSO.
The Azure Application Proxy is designed for web applications that are hosted on-premises and for which you don’t want to open ports on your corporate firewall.
The App Proxy tunnels the connection over a Application Proxy Server located in your on-premises environment.
For this particular situation this blog is covering, the data flow will look like this:
The breakdown
In this blog I will explain you how to setup the following:
- The Application Proxy server
- A new Enterprise Application, OWA!
- Constrained delegation in order to process SSO via Kerberos
- SSO for the OWA application
- Enabling Windows Based Authentication on Exchange
Prerequisites
In order to setup the Application Proxy for OWA you will need the following:
- One (or more) Azure AD P1 or P2 license(s) : https://docs.microsoft.com/nl-nl/azure/active-directory/manage-apps/application-proxy-faq#what-license-is-required-to-use-azure-ad-application-proxy
- A domain controller, an Exchange Server and a Azure Application Proxy server.
Yep, that’s all you need!
Installing the Azure Application Proxy
The first you need to do is install the Azure App Proxy onto the server you designated as the proxy server.
In this blog I only used one server but you do have the posibility to add more to make this setup HA (highly available).
- Go to the Azure Portal via https://portal.azure.com
- Search for app proxy
3. Download the connector service
4. Install the downloaded connector on your App Proxy server
5. When you have successfully installed the software the server will show up in the Application Proxy console
6. Click on Enable application proxy and approve the activation
Creating the Enterprise App OWA
7. Search for and go to Azure Active Directory
8. Select Enterprise Applications and then New Application
9. Select On-Premises application
10. Fill in the details of your application :
Name : The name of your application, this will also be advertised when you publish the application to My Apps (We will be covering this later).
Internal URL : Enter the internal URL for the app, I’ve entered the full OWA path because this will directly forward the proxy connections to OWA.
External URL : The URL the user is going to enter in order to reach OWA, you can either use a “tenant shaped” URL or one of your own domains. In below example I’ve used the tenant shaped one but you can also use your own URL. In order for that to work you will need a valid certificate for the URL you’re going to use. This could of course be a wildcard URL you own.
Pre Authentication : Where going to use Azure Active Directory in order to use all the benefits
Translate URLs In | Headers : Set this to No in order to let OWA process the authentication correctly.
11. You can then start to customize your application by going to the Properties tab and adding a logo, enabling it for users and deciding whether it’s required for a user to be assigned to the application.
12. As you can see in above screenshot the application gets it’s own URL starting with https://myapps.microsoft.com so your users can access it. If you want it to appear in My Apps then assign Users and/or Groups to the application so they will be able to access it from there.
And don’t forget to enable the option Visible to users?
13. When you log in on the My Apps page the application will be displayed:
Allowing constrained delegation for the App Proxy
The next step will be allowing the Application Proxy to request kerberos tickets in order to authenticate to the Exchange Server on behalf of the user.
14. Log on to your DC and open Active Directory Users and Computers
15. Find the Azure App Proxy server’s computer object and go to the Delegation tab
16. Select Trust this computer for delegation to specified services only and Use any authentication protocol
17. Select Add… and type in your Exchange Server’s name, then press OK
18. Then select the Service type “http” and press OK twice
19. You now have given your Azure App Proxy server permissions to request Kerberos tickets on behalf of the user and send them to the Exchange Server for HTTP requests.
Enabling Windows Authentication for Exchange
By default Exchange works with Forms-Based Authentication in order to display a user friendly page when you access OWA.
To let the Azure App Proxy pass trough the credentials using Kerberos we will need to enable Windows Authentication.
20. Open the Exchange Management Shell and enter the following 2 commands, the second one will be for the ECP. Because the ECP is part of OWA you will need to allign the 2.
get-owavirtualdirectory | set-owavirtualdirectory -windowsauthentication $trueget-ecpvirtualdirectory | set-ecpvirtualdirectory -windowsauthentication $true
21. To process the changes for Exchange you will need to recycle the IIS App Pools for OWA and ECP, to do this you will need to open the IIS Management console and select Application Pools, then Recycle.. and recycle both the OWA and ECP app pools
Adding SSO to the OWA Enterprise App
The last thing you will need to do is configure SSO to be automatically signed in when you access OWA through the App Proxy.
22. Go to the Single-Sign On page in your OWA app and select Windows Authentication
23. Fill in the SPN in the following format service/servername so in this case it’s http/servername and select User principal name
24. The Application Proxy will now know that it needs to request a Kerberos ticket for HTTP requests send to the Exchange Server.
The end result
As you can see in the Youtube video’s below SSO and conditional access work based on the App Proxy.
I hope you liked reading this blog!
Thank you Patrick,
regarding the internal SPN, what if i had multiple exchange servers, Ex01, Ex02 and my internal url for accessing owa is http://email.company.com
in this case i will enter http/email.company.com as an SPN or what?
Hello Helmy, the SPN is based on a single SPN model but you can create a SPN for load balanced Client Access servers by following this article:
https://docs.microsoft.com/en-us/exchange/architecture/client-access/kerberos-auth-for-load-balanced-client-access?view=exchserver-2019
The only thing that’s different from this article is that you will enter the SPN name of the load balanced SPN in Azure.
Hello Patrick,
i have followed your steps above and users are able to login, I have 3 Client Access Servers (Ex1, Ex2, Ex3) but I target (Ex1) in the AD Delegation and in the Internal SPN on Azure.
The users experiense is sometimes SSO works fine, sometimes not working and users have to re-enter the creds.
is configuring a balanced SPN for the Exchange servers will solve this issue or i have to get back to msft support to check from their side.
Hello Helmy,
If you have created a shared SPN than pointing to that SPN (for instance http/mail.company.com) will solve your problem.
The issue you are describing is caused by the SPN you set on Azure and will be resolved by creating the shared SPN.
Hello Patrick,
Great article, thank you!
Quick question, my internal OWA URL differs from my external OWA URL in the virtual directory.
owa.companyint.com is the internal one
owa.company.com is the external one
If I connect from the outside (using the App Proxy), then I do get redirected to our external OWA URL and see our current solutions login page to gain access to OWA.
I don’t really get why I do end up there instead of getting proxied to our FrontEnd directly.
I’ve tried to replace our external URL by the internal one, it’s working like a charm from within the company, but not from the outside…
Thank you.
I forgot to mention:
Exchange 2013 DAG
BasicAuthentication : True
WindowsAuthentication : True
DigestAuthentication : False
FormsAuthentication : False
LiveIdAuthentication : False
AdfsAuthentication : False
OAuthAuthentication : False
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
ExternalAuthenticationMethods : {Fba}
maybe it has to do with that the shared SPN is not setup correctly yet.
Hi Carsten,
Good thought but the SPN is actually only responsible for SSO so redirecting it to the external OWA site should not be the reason.
What I’m thinking about here is that Exchange is redirecting you to the external URL of OWA.
Do I understand correctly when I say that your OWA’s virtual directory external URL is set to owa.companyint.com? Or could you change that to the “internal” URL?
The principal of the App Proxy connector is to act like a computer inside the network trying to reach your OWA IIS site/directory, so when it gets a response that tells it to browse to the external URL it will tell your own browser to go there instead of authenticate to OWA.
Thank you Patrick for your quick reply, it was late the other night and finally this morning I did a couple of more tests.
owa.companyint.com is the internal URL for OWA
owa.company.com is the external URL for OWA
It’s a 4 node DAG and I can narrow the issue down a bit.
My mailbox is hosted on node 3.
If I put in the hostname of node 3 as the internal URL of the application proxy it works like a charm (have to enter basic auth becaue SSO is disabled for now).
E.g. if i put in the first node of the cluster into the application proxy internal URL I’ve to enter credentials twice.
At first for the first node, then getting redirected to the second and after authentication it opens up my external OWA URL.
I haven’t figured out what’s causing this yet, but we’ll get there.
I’ve confirmed this internally.
If my mailbox resided on node 3 and I connect to node 1 after authentication I do get redirected to the external URL set for the virtual directory.
With a test mailbox on node 1 and connecting to node 3 it’s the same. After authentication on node 3 I get redirected to the external URL.
But only if the node is in a different site
Could you maybe enter the DAG IP of your cluster followed by /owa as the internal URL for the App Proxy?
So for instance https://192.168.0.1/owa?
I’ve removed the external URL from all nodes on the virtual directory and now it works.
As soon as I have been redirected from one site to another I had the problem that I got redirected to that external URL.
Unfortunately users now only see the internal URL in Outlook to gain access to OWA.
SSO works perfectly after following: https://docs.microsoft.com/en-us/exchange/architecture/client-access/kerberos-auth-for-load-balanced-client-access?view=exchserver-2019… It took some time to replicate but then it does its job.
For ECP I’ve created a second app with the same settings.
Thank you for your help!
Very glad to hear that you got it resolved Carsten, it was a pleasure assisting you. Have a nice weekend!
You too, thanks!