Enterprise Mobility and Security Blog


Howdy folks,

Today’s news is pretty big! Over the weekend we turned on the preview of our Azure AD Application Proxy, a new feature of Azure AD Premium.

As we worked on Azure AD Premium over the past year, we’ve had the opportunity to meet with hundreds of enterprise customers to share our vision and to gain a deep understanding of their identity and access management needs. Once customers understand how they can use Azure AD to manage access to cloud based SAAS apps, inevitably the next question is “Can I use this to manage access to my on-premises apps?”

This preview of Azure AD Application Proxy lets you do exactly that. It extends Azure AD’s SaaS app management capabilities to on-premises apps, giving you the ability to manage access to internal browser based applications (SharePoint Sites, Outlook Web Access and IIS based applications) using Azure AD. You can make these apps available in a secure manner to authenticated users through a cloud proxy hosted in Azure.

Shai Kariv is the Group Program Manager for our Active Directory engineering team in Herzliya, Israel. Shai and his trio partners are leading the development of our cloud app proxy and I’ve invited him to blog about some of the details of this preview.

I’m really excited about this new set of capabilities. They greatly expand the applicability of Azure AD Premium and aren’t available from anyone else in the cloud identity market.

As always, we’d love to receive any feedback or suggestions you have!

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of PM

Active Directory Team


Greetings from Herzliya!

I’m Shai Kariv, the Group Program Manager for the AD PM team in Microsoft’s Israeli Development Center. I’m blogging today to share some of the details about our new Cloud Application Proxy.

Our cloud application proxy is a reverse-proxy as a service that builds on the Web Application Proxy capability we built for Windows Server 2012 R2. We’ve done a ton of work to optimize it for the cloud, moving most of the heavy lifting the proxy does into Azure data centers. It supports browser based applications using http: and https: connections. The proxy service enables selective publishing of application endpoints and soon it will support pre-authentication of users and devices as well.

To try out the preview all you need to do is install a light weight software agent on-prem (AKA “connector”), typically at the backend application tier. The connector issues outgoing http requests to the Azure proxy service. The proxy service sends back responses which contain a payload of incoming requests from a user which are routed from connector to target application.

The benefit of this architecture is that there is no infrastructure for you to operate in the DMZ, and users can access your on-premises applications without gaining direct access to your network.

If you are interested in a deep dive, make sure to check out my presentation TechED North America.

As this is only the first preview of our cloud app proxy, it has a basic set of selective publishing capabilities. We will be working over the next few months to add richer functionality, including pre-authentication for users and registered devices, support for workplace-joined devices, multifactor authentication, and support for specifying the strength and type of authentication required. We will also add the ability for your employees to access your published applications in the Azure AD access panel at myapps.microsoft.com.

To check out the preview, just follow these steps (note your tenant admin must have an Azure AD Premium license in order to access these features):

First you will see a new configuration setting for turning the proxy on or off. Turn it on, save the configuration, and then download the connector to your network.

Next, you need to install the connector and on a Windows Server 2012 R2 server inside your corporate network and register it with your Azure AD tenant.

To do this, click on the download link which will walk you through a step by step experience. After the package is installed, you need to run a Windows PowerShell command window as a local administrator, to complete the registration. You may also be prompted to enter your tenant admin credentials (we will automate this part in the future). For scalability and advanced topology scenarios, you can install multiple connectors in your network, in various locations. For example, if you have multiple branch offices in different regions, or if you want to ensure redundancy in case of failure.

Now you can select web endpoints to publish for external access. Any web app over HTTP 1.1 protocol can work. For example: SharePoint, Exchange, Lync, CRM, IIS, ASP.NET, Windows Server 2012 R2 Work Folders, or other homegrown or 3rd party apps.

Click “Add Applications” to start the wizard. The first two options are for SaaS apps. The third option is the preview capability for publishing on-prem apps.

Choose a friendly name for the application you publish. It has to be unique across all published apps from your tenant.

Choose the public URL for the application you publish. To make it an easy start, the proxy service assigns a unique URL for you, and you don’t have to worry about managing DNS or anything else. The URL is a combination of the application name you gave in the previous step and your tenant name. The domain is msappproxy.net. In a future update to the preview, we will make this customizable so you can come up with your own URLs, for example something like https://sharepoint1.fabrikam.com. And of course users won’t have to know these URL’s anyway as we will add the ability to access the application as a tile on their myapps.microsoft.com app access panel.

(Note the default protocol for public URLs is secure: SSL over port 443 (https). You can change it to http over port 80 as showed in the screen shot below.)

Last, type the URL of the internal app, just like you would type it in a browser running inside the internal network. This could be https or https. It will be used for the communication between the proxy connector and the app.

The published application will appear alongside the other applications, with a new type ‘Proxy application’.

That’s it – you’re up and running.

Let me give you a quick tour of the underlying architecture that makes this work.

The published endpoints for your apps are hosted in the Azure cloud, so any type of device and browser can connect to them. There’s no need to install or operate a client agent or a VPN client. The proxy service terminates the client connection and performs a set of validation checks. If there’s a problem, the proxy fails the request, or for instance can challenge for step-up multi-factor authentication. Once that is completed, the proxy attempts to route a request to your network. To do this, it selects a pending request from one of your connectors, which is awaiting a reply. The customer request is packaged in the payload of this reply, and arrives at the connector. Once it arrives, the connector then accesses the app on behalf of the user, and the application’s response is routed back to the proxy service and from there to the client.

As the connector calls out to the proxy and no direct inbound access to your network is allowed, so user devices are never able to directly access your corporate network (unlike with a VPN connection). This greatly limits the surface area exposed while giving employees access to the apps they need. Additionally, this pattern shuffles traffic back and forth across your DMZ firewall[s] seamlessly with no new hardware or complex configuration required.

We would be delighted to get any feedback and suggestions you have! Just head on over to our application proxy blog where you can get the latest information on on-going enhancements plus tips & tricks for using this new cloud proxy.


Shai Kariv

Group Program Manager