Learn how to install the Azure Application Proxy and publish an on-premises web app with conditional access.
- [Narrator] We just walked through aa cloud application, salesforce.com. Now, let's talk about how we can use Azure Active Directory to publish an on premises application that runs behind the firewall. And, if you're thinking, "Well, why would I want to do this," think about how we just talked about conditional access. What if you could bring all those capabilities and controls to your on premises applications as well, and on top of that, with the application proxy, which is what we're going to take a look at, you can do this, and remove the need for people to connect to VPNs.
This means that you can publish internal applications to devices like tablets, that can't do VPNs, or can't do VPNs easily, and you can remove the cost, and overhead, and expense that's involved with managing VPN clients potentially on your desktops and laptops that you issue to people. The component we're going to use to do this is called the Azure Application Proxy. What the Azure Application Proxy does is it makes outbound connections from your data center to a specific set of endpoints in Azure AD, and it leaves those connections open, so there's no holes in the firewall.
But, when a user wants to access an application that's published with the Azure Application Proxy, they'll be able to go to a URL that's hosted in Azure. It can be the same URL as they are used to using, you'll just change the DNS record. Azure will authenticate them with whatever sign in method you've chosen, it'll apply any conditional access policies you've defined, and only after all those checks succeed will it push them back through the tunnel, so that they can connect to that application. So, the first step to do this is we'll need to install at least one application proxy connector.
You can download that from the application proxy area, and click the download connector button. I've gone ahead and downloaded this in the background, so we'll switch over to that server, and we'll go ahead and install this. We'll go ahead and launch the installer, go through the usual steps for installing things, and then the next thing that'll happen, we'll be prompted to sign in with administrator credentials to Azure Active Directory. (typing) What this does is it authenticates the connector, and lets you create that outbound connection to Azure AD.
Once this is complete, there's this connection troubleshooter. You'd think from the name that you'd only need to run that if you have a problem, but the great thing about it is it'll verify that everything's working fine before we start setting it up. Okay, now that we have the connector installed, what we're going to do is we're going to publish a web application, a really simple one that's installed on an IIS server. That IIS server just has a single website here.
It also has a Newt application pool that we've reconfigured to use a specific service account. The reason we've reconfigured this use a service account is that the Azure Application Proxy uses something called Kerberos Constrained Delegation. What Kerberos Constrained Delegation let's the application proxy do is impersonate a user over the network. So, it can be someone else without that user signing directly into the application proxy. To set that up, we did a couple of specific things to make this work. The first thing we did is we registered what's called a service principal name on the service account for the IIS application pool.
You can see on the screen, the URL for this is going to be demosite.hplus-sport.com. We created a service principal name called HTTP slash demosite.hplus-sport.com. The second thing we did is we configured the Azure Application Proxy server to be able to do Kerberos Constrained Delegation to this specific service principal name, which is a fancy way of saying, we're going to let the application proxy impersonate users for this service. So, the next thing we need to do is configure this application in Azure Active Directory.
To do that, we'll come to enterprise applications, and we'll create a new application, except this time, instead of choosing from the gallery, we're going to pick an on premises application. We'll give this a name, this is what it's going to show up as in the access panel. We'll just call it Demo Site. And the internal URL is going to be how the Azure Application Proxy connects to the application. Next, with the external URL, this is how users are going to connect to this from outside the firewall.
Ordinarily, you'd probably actually want this to be demosite.hplus-sport.com, so that they don't have to change any of their bookmarks. What you'll do is you'll simply change that DNS record to point to a new URL in Azure AD. For the purpose of this demo, I'm going to stick with the default, but know that you have that choice of using any of your verify domains as the URL to an application proxy application. We're going to go with all the defaults for the rest. Connector groups are kind of useful. By default, there's one that's conveniently called default, that all connectors are put in.
If you have Azure Application Proxy connectors that are in different data centers, different parts of the world, you can create connector groups, so that requests get sent to the best set of application proxies, based on where the application's located. We'll go ahead and add this. There's a couple things that we'll need to do to finish this. First, we'll go to single sign-on, and we'll pick integrated Windows authentication. This is how we're going to tell the application proxy to do Kerberos Constrained Delegation to this application. The SPN, or the service principal name is what's assigned to the service count in IIS, and that happens to be this value.
(typing) By default, you can usually pick user principal name for this delegated login identity. Occasionally, if you're publishing third-party applications that run on premises, or that are older, you might need to choose a different value that's put in the Kerberos ticket. We'll save this, and then the last thing we'll do is we'll go ahead and give some users access to this, much like we did with Salesforce. We'll pick a couple of users, we'll assign them, and now, when these users go in the access panel, they'll be able to see this application.
If you wanted to, you could also change the icon for this application by uploading a new logo. Otherwise, it'll just have a default image, but something that your users are used to seeing. When I access this application, you can come in here and make that customization. Now, if we switch back to the access panel as an end-user, you'll notice that a new application has shown up, and that's that Demo Site that we created, which is the application proxy app. I'm going to go ahead and click on that, and what we're going to see is that the application actually thinks we're and on premises user, even tho we're being proxied through Azure Active Directory.
You'll see the URL here, that demosite.hplus-sport.msappproxy.net. We chose this URL, but as I mentioned, this could also be .hplus-sport.com. Notice that it's welcoming me with my traditional domain slash username. Even though I'm not on the network right now, and I'm coming from the outside, the application proxy has used Kerberos Constrained Delegation to impersonate me, and proxy my access back to the application that's located behind the firewall.
- Authentication options with Azure AD
- Configuring Azure AD Connect for sync and authentication
- Securing remote access with the Azure Application Proxy
- Managing apps and devices with Intune
- Building and deploying a basic Intune policy for iOS or Android
- Protecting data beyond the firewall with Azure Information Protection (AIP)
- Configuring AIP classification labels and protection
- Integrating Exchange and SharePoint with AIP
- Managing risk with Advanced Threat Analytics
- Connecting Office 365 to cloud app security