Publishing OWA with Azure Application Proxy

Azure Application proxy is an exciting technology that’s available with Azure AD Premium. It allows you to publish internal web applications in a simple and secure manner.

Software Prerequisites

The proxy connector is an application that needs to be installed on a Windows Server 2012 R2 or Windows 8.1 + machine. The application itself is a ~4 MB download and even can be installed on the server that you are trying to publish (although I would not recommend this).

Network Requirements

The server that houses the proxy connector only requires outbound access. Specifically the following ports need to be open:

PORT NUMBER

DESCRIPTION

80

To enable outbound HTTP traffic for security validation.

443

To enable user authentication against Azure AD (required only for the Connector registration process)

10100 - 10120

To enable LOB HTTP responses sent back to the proxy

9352, 5671

To enable communication between the Connector toward the Azure service for incoming requests.

9350

Optional. To enable better performance for incoming requests.

8080

To enable the Connector bootstrap sequence and to enable Connector automatic update

9090

To enable Connector registration (required only for the Connector registration process)

9091

To enable Connector trust certificate automatic renewal



How it works

The proxy connector makes an outbound connection to the Azure proxy in the cloud thus allowing a bi-directional TCP/IP transmission. Before a user can access the internal web application, the user’s account is authenticated against Azure AD (pre-authentication). Afterwards, if Kerberos authentication is enabled for the applications, the users will experience a single-sign on experience. If not, the user needs to authenticate to the application.

Publishing OWA

To test out the proxy, I’ve decided to publish Exchange 2010 OWA which is hosted in my lab without any external presence. My goal is to allow for a single sign on experience. I will need to do the following to meet this requirement:

1) Enable Kerberos authentication for Outlook Web App.

2) I need to ensure SPN’s and Kerberos Constrained Delegation is properly setup.

Enable Kerberos Authentication for OWA

To do this, logon to the Exchange Management Shell (2010)—>Server Configuration—>Client Access

Go to the OWA virtual directory and edit the properties. Change the authentication method from forms-based authentication to “Integrated Windows Authentication”

Now we need to delegate the server that has the connector installed with the rights to request a Kerberos ticket on behalf of the Exchange server. To achieve this, go Active Directory Users and Computers, and double click on the computer that has the Azure connector installed.

Go to the delegation tab and add the services (HTTP) of the Exchange server that can be delegated.

Configure Azure AD Premium

Create a new application in Azure AD:

PreAuthentication Method: Set to Azure Active Directory.

Translate URL In Headers: Set to No since Exchange needs host headers to be preserved.

Internal Authentication Method: Set to Integrated Windows Authentication (Kerberos). If Kerberos is not possible, the user will have to login to the application.

Internal Application SPN: Provide the SPN for the Exchange server.

 

Now navigating to the Azure Application Proxy URL yields this:

https://owapage-jenutest.msappproxy.net/OWA/

Sign into the Azure Portal using your AD credentials (UPN and password).

Once successfully authenticated, you will be redirected to OWA page and logged in using Kerberos authentication.

Recommendation:

Azure Application Proxy is a great tool to publish internal web applications securely. In most environments, publishing an application wouldn’t involve making changes to the firewall since the proxy connector only needs outbound access.

Any application published via Azure Application Proxy can be added to the Application Portal which the users can access from a single page; if they are logged in they would go directly to the OWA page without the need to be authenticated twice. To take this further, multi-factor authentication can be easily leveraged to add another layer of security. To provide a higher level of availability the connector can be installed on multiple machines. In the case one server is down, the application proxy would continue to work.