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:

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 https://portal.azure.com
  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 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?

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

15 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 http://email.company.com
    in this case i will enter http/email.company.com 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/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.

  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.

    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.

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

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

          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.

  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!

  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

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

%d bloggers liken dit: