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!
I want to publish OWA through Azure AD App Proxy and now one of the admins is asking me if a normal Outlook client can use the same URL to gain access to the internal email.
He is talking about that it is possible to configure outlook to use OWA but I am not sure if that would also work with/through the Azure AD application proxy. Do you know?
Hi Willemsen,
I think the admin is referring to the OWA URL being visible in the Info tab on Outlook.
It won’t be possible to route the MAPI traffic of Outlook over the Azure App Proxy but what you can do is add Hybrid Modern Authentication to your Exchange configuration.
What this does is rerouting any authentication traffic to Office 365 where you can leverage the benefits of having MFA and Conditional Access:
https://docs.microsoft.com/nl-nl/microsoft-365/enterprise/configure-exchange-server-for-hybrid-modern-authentication?view=o365-worldwide
The requirement is that you use at least Office 2013 or higher because these Office versions support modern authentication.
Also you need to set up your Exchange Server in a Hybrid deployment with Office 365.
If you then limit the OWA and ECP directories to only be available to your internal network this will limit the users in only using the Azure App Proxy for webmail.
You can use IP restrictions in IIS to limit the IP addresses:
https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/ipsecurity/
I hope this will help you to configure the necessary resources, if you have any questions then be sure to let me know!
Thanks for the great effort. I have 2 CAS servers and configured ASA as mentioned in the article. And published OWA is working like a charm with no problem. But the old external URl for OWA is still working as well. Users still can access OWA by using old URL. How can i block users to access external old OWA URL and can only user the published one.
Hello Mahmoud,
You can achieve this by setting the ExternalURI to $null with the following command:
Set-OwaVirtualDirectory -ExternalUrl $null
This will disable the usage of OWA through the external URL. Of course you could also block access by adding a rule to your firewall which blocks access.
Thank you for this wonderful post, I have some curious does this solution do well to hold up against the hafnium exploit?
Hi Jack, really good question you’ve got here 😉
If you would close the HTTPS port for Exchange than yes that would be the case, but that would make it impossible to access mail from a mobile client.
As a authentication solution the App Proxy is a perfect way to secure OWA access by leveraging MFA but the exploit drills into your Exchange Server when you leave the HTTPS port opened.
I would advice you to follow the guidelines set out by Microsoft and update your Exchange Server with the latest security patch.
Our servers have Azure App proxy in front of OWA and EWS, and we believe this prevented use of the hafnium exploit due to windows based authentication added to the EWS folder. The exploit requires sending a specially crafted SOAP request to the exchange web services path and since that path is protected by windows authentication may have blocked CVE-2021-26855 from functioning. Hopefully someone with more of an in-depth knowledge of EWS and the exploit can confirm. We moved to using Azure AD Proxy a while ago to leverage the azure 2FA and other security benefits and now thinking it may have saved us a lot of headaches considering there is now some evidence that the exploit was leaked from a Microsoft MAPP partner prior to the patches being available.