<img height="1" width="1" src="https://www.facebook.com/tr?id=1529264867168163&amp;ev=PageView &amp;noscript=1">
blog_listing_hero_img.jpg

Using Azure Active Directory Application Proxy to Publish Internal Apps

One of the great features in Microsoft 365 is Azure Active Directory Application Proxy. AAD App Proxy allows you to publish internal web applications to the Internet and ensure users authenticate in a very secure way. Best of all, it can do this usually without requiring any firewall changes – all that is required is outbound Internet access from the computer running the AAD App Proxy agent.

One of the key reasons to use Azure App Proxy is that it uses Azure AD as the identity provider (IdP) for authentication to the published applications. That means that you can use Condition Access to control and regulate access to your internal apps, including enforcing MFA, even if the web app itself doesn’t support it. This brings the power and security of Microsoft’s cloud to your organization’s internal apps.

Here are a few AAD App Proxy examples:

- Allow select users to remotely access an internal on-premises web application without having to configure the firewall.
- Use split-level DNS and Conditional Access to allow remote access to an internal web app using MFA. Internal users can still access the internal app without MFA.
- Use Conditional Access to allow just the sales department to access an internal web app and require MFA.
- Users can sign-in once to the Microsoft 365 Apps Portal (https://myapps.microsoft.com) and then use single sign-on (SSO) to easily access the published applications (including AAD App Proxy applications) they have access to.

Breaking from Microsoft tradition, let’s start by talking about the licensing requirements. To use Azure Active Directory Application Proxy, the admin account who configures it and the end users who access the App Proxy must have an Azure AD Premium P1 or P2 license. Without one of these licenses assigned to your admin account, you will be unable to enable Application Proxy. Conditional Access and third-party application support for MFA also requires an Azure AD Premium P1 or P2 license, so other than a Microsoft 365 tenant, that’s all you’ll need from a licensing perspective.

The architecture for Azure App Proxy is as simple as it is brilliant. The admin creates an enterprise application in Azure AD, which acts as the endpoint that remote users will connect to. Users normally pre authenticate here against Azure AD and go through the Conditional Access flow which denies or allows access and enforces MFA. Once authenticated, the Azure Application Proxy Service queues the user request. An on-premises connector makes outbound connections to the Azure Application Proxy Service to service the internal web application requests. The key here is that all inbound client requests are serviced by an outbound connector – eliminating the need to configure the firewall.

Picture1-13 Figure 1: Azure Active Directory Application Architecture

Organizations with an on-premises Active Directory will need to sync users to Azure Active Directory using AAD Connect or Microsoft Identity Manager. Conditional Access and MFA rules are based on Azure AD users and groups.

Azure AD App Proxy uses an agent called the Application Proxy Connector that you download from the Enterprise Applications blade on the Azure portal. The agent must be installed on any domain-joined computer that has line-of-site to both the internal application server and a domain controller on-prem. This computer only needs to be allowed to access the Internet using TCP ports 80 (HTTP) and 443 (HTTPS). Only one Application Proxy Connector needs to be installed for AAD App Proxy to work, but you can install more than one connector for fault tolerance.

After the connector is installed you can publish your app, which is fairly straight forward. You’ll give the app a name which will show in both the Enterprise Apps blade and the My Apps portal. The Internal URL is the one that the connector will access. The external URL is generated from the internal URL and defaults to use the <tenant>.msappproxy.net domain. Usually you will change this domain to use one of your verified domains in AAD, such as contoso.com.

Picture1.2pngFigure 2: Configuring a new on-premises Enterprise Application

The default for the new app is to use Azure Active Directory for pre authentication. This allows users to authenticate via Azure AD and take advantage of Conditional Access and MFA. You may choose to select Passthrough which configures the app to authenticate directly with your on-premises domain. Doing this will bypass Conditional Access and MFA.

Next, you assign users and/or groups to the app and optionally set up single sign on to enable users to sign into the application using their Azure AD credentials. Lastly, you publish the app FQDN in DNS so users can access it. Read Plan an Azure AD Application Proxy deployment for complete details.

There are a number of ways you can deploy and publish enterprise apps to your users, and Azure AD App Proxy is just one of them. Other methods include VPN, RDP with a Remote Desktop Gateway, App virtualization, etc. It’s always good to know all the tools available to you and which one is appropriate for your situation.

I’ve successfully used Azure AD App Proxy to publish on-premises Outlook Web App for Exchange Modern Authentication customers, but that’s an advanced configuration. If you have questions or need assistance, reach out to me.






Monitor Your Hybrid - Office 365 Environment with ENow

ENow’s Office 365 Monitoring solution is like your own personal outage detector that pertains solely to you environment. ENow’s solution monitors all crucial components including your hybrid servers, the network, and Office 365 from a single pane of glass. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.

Learn more