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!
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.
Group Program Manager
Looks great! And looks like a smooth fit to my lab environment too. A few questions though:
1. The Application Proxy Connector - is this a proxy service so that you can for example have two servers running the application proxy connector service and as long as these servers can reach the services (SharePoint, OWA, IIS) with HTTPS, you do not need
to install anything on the servers running these services?
2. Name resolution happens at the application proxy connector?
3. What is the thoughts around customers with multiple datacenters?
Must be able to send HTTPS requests to the Application Proxy services in the cloud, and it must have an HTTPS connection to the applications that you intend to publish. If a firewall is placed in the path, make sure it’s open to allow HTTPS requests that originate
from the connector to the Application Proxy services.
4. Formulated strangely, or does this actually say that you do not need to open anything from the internet and in to the servers running the Application Proxy Connector service? (I first assumed this required the use of Azure VPN, but I can't see anything about
it in the documentation)
In reply to myself @Marius Solbakken Mellum:
1. Correct, nothing needed anywhere else than on the computer running the AAD App Proxy.
2. Yes, happens on the AAD App Proxy.
3. Still open question
4. Yep, no ports required.
Installed this on a test server in my lab and this works fine. Published an internal anonymous IIS site to the internet without opening a single port anywhere in my firewall. :) That opens an interesting question; how will you track that this service is not
being used as a backdoor into environments?
Hi Marius. I am a PM in the product group. Glad to hear you like the product.
Regarding 3, you can install more than one connector for your tenant. There is currently no support to assign applications to specific connectors, but this is definitely on our thoughts.
Expect more functionality to appear all the time.
Thanks for the feedback.
This looks great!
Any plans to also include "forward proxy" capabilities as a cloud service?
Can we also use this new proxy services for BYOD devices and Workplace Join features?
Also what about integration with Azure MFA?
Any inputs on how this will be priced?
Thanks for the questions..
Shloma: regarding the issue of forward-proxy as a service, I would like to have an offline discussion to learn the scenario and requirements you had in mind, please connect with me over email at firstname.lastname@example.org
Jesper: absolutely planning to integrate with BYOD/WPJ devices as well as Azure MFA, take a look at the recent TechEd session I gave for my details (link referenced in the post).
Ilant: pricing wise this feature is planned to be part of the AAD Premium license.
SaaS has been attractive, because it removes all complexity from installation, deployment, maintenance, is globally accessible, and affordable.
What are the requirements of the server on premises (I understand should be Win 2012 R2) however what else, should domain join? I have a problem when I am trying to register-appproxyconnector , I am getting failed to connect end point services . Any advise,
very keen about this product, well done guys
I installed it on a server that is not a member of the domain specifically to test this. Worked without problems. I had to switch IE Enhanced Security Mode off to register the proxy, but other than that it was straightforward.
I am getting an error when I am trying to register the proxy "could not connect to the registration services-check you network connectivity
Line :1 Char:1
Ariel, can you share more details on this error with us using this e-mail address: AadapFeedback @ microsoft.com ?
We would like to better understand this.
When I am trying to install the connector in my Private Network, is failing during registration, the error in the event viewer is :
Event Id:12025 There was not endpoint listening at:
My understanding was, that the connector is using 443 to connect Azure Application Proxy services ,why is trying to go via 9090
Any way to overcome this issue
Hi @Ariel and thanks for the feedback.
We require a number of outbound ports for the connector to work: 8080, 9090, 10100-10103, and 20200-20204. If you have issues with this requirements, please contact us directly to aadapfeedback @ microsoft.com .
We need the Microsoft IP address range to open in the Firewall (our Firewall doesn't support dynamic DNS resolution and also is not recommended)