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:

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

In order to setup the Application Proxy for OWA you will need the following:

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).

  1. Go to the Azure Portal via
  2. 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 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?

Assigning the application to a user

13. When you log in on the My Apps page the application will be displayed:

The end result

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 $true
get-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!

Dit vind je misschien ook leuk...

22 reacties

  1. Helmy schreef:

    Thank you Patrick,
    regarding the internal SPN, what if i had multiple exchange servers, Ex01, Ex02 and my internal url for accessing owa is
    in this case i will enter http/ as an SPN or what?

  2. Helmy schreef:

    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.

    • Patrick van Bemmelen schreef:

      Hello Helmy,

      If you have created a shared SPN than pointing to that SPN (for instance http/ 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.

  3. Carsten schreef:

    Hello Patrick,

    Great article, thank you!
    Quick question, my internal OWA URL differs from my external OWA URL in the virtual directory. is the internal one 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.

    • Carsten schreef:

      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.

      • Patrick van Bemmelen schreef:

        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 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.

        • Carsten schreef:

          Thank you Patrick for your quick reply, it was late the other night and finally this morning I did a couple of more tests.

 is the internal URL for OWA
 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.

  4. Carsten schreef:

    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.

  5. Carsten schreef:

    You too, thanks!

  6. Willemsen schreef:

    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?

  7. Mahmoud Eldeep schreef:

    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.

    • Patrick van Bemmelen schreef:

      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.

  8. Jack Wilder schreef:

    Thank you for this wonderful post, I have some curious does this solution do well to hold up against the hafnium exploit?

    • Patrick van Bemmelen schreef:

      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.

  9. Rich schreef:

    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.

  1. 10 augustus 2020

    […] a blog about it. With some new ideas I’ve gotten from my previous blog about the App Proxy (Securing & using SSO for OWA & ECP with the Azure App Proxy) it was time to start writing this […]

Geef een reactie

%d bloggers liken dit: