Azure AD Application Proxy Overview
- Included in Azure AD Premium subscriptions
- Allow users to access internal web-based applications from outside the network without adding internal Web Application Proxy infrastructure
- Does require a Windows Server 2012 R2 server to run Azure AD Proxy Connector
- Configuration option that allows all DNS and certificates to be handled by Microsoft
- Uses Azure AD-generated URL for proxied application
- Option to use alternate URL to customize the URL, domain for the published app
- Subscriber must provide SSL certificate for alternate domain
- Domain name must be verified in Azure AD Premium tenant
- Users can access application via published application portal or directly via proxied URL
- Requires AD FS for single sign-on capability
- Published applications can also use Kerberos Constrained Delegation for pass-through authentication
- On-premises users must be synchronized into Azure AD Premium tenant, licensed for Azure AD Premium and assigned to the published applications they are allowed to access
Azure AD Application Proxy is a new feature of Azure AD Premium and Azure AD Basic. It allows publication of internal web-based application to provide Internet access to authorized users in the corporate domain. If the enterprise subscribes to Azure AD Premium or Azure AD Basic, or any Microsoft Azure subscription that includes Azure AD Premium or Azure AD Basic (such as EMS Suite), Azure AD Application Proxy can be used in place of internal Web Application Proxy Servers to provide authorized internal users access to internal, web-based applications from outside the security of the corporate network.
There are a few internal requirements to run Azure AD Application Proxy. As one requirement, one domain-joined Windows Server 2012 R2 server is required internally to install the Azure AD Application Proxy Connector. This server may be a domain controller or application server, with application server being the best practice. Multiple servers may be used if redundancy is desired. The connector software runs as a service on the server(s) and provides the connectivity between the internal application and the Azure AD Application Proxy portal, so the portal knows how to redirect access requests from the portal. Along with the Connector Server, there are several firewall ports that must be opened externally. A list of those ports can be found here.
The additional on-premises requirement to implement Azure AD Application Proxy Portal is AD FS 3.0, federated with the Azure AD Premium/Basic tenant. AD FS provides single sign-on capability, allowing users to access federated applications using their on-premises Active Directory credentials. AD FS is required for access for other services in the Azure AD Premium suite, as well.
In its simplest form, when an enterprise wants to publish an internally-published web application to Azure AD Application Proxy, someone logs into the Azure AD Premium tenant with an account that has global administrator permissions. That user goes to the Configuration tab of the tenant and enables the Azure AD Application Proxy service. Then, the user clicks over to the Applications tab and selects to publish a new application. After providing an internal URL for Azure AD Application Proxy to point to, as well as selecting the authentication type, the application is then published to the portal. If the administrator configures the application using the default properties, the Azure AD Application Proxy generates an external URL for the application, based on the name given to the application when the proxy was configured and the tenant’s domain in Azure AD Proxy, with the domain name msapproxy.net. For example, if I publish an application called website in my company’s Azure AD Application Proxy and my company’s verified internal domain is companyname.com, the Azure-generated URL for the application is something similar to https://website-companyname.msapproxy.net. All URLs will use SSL and port 443 for access. The advantage to using the default settings is that Microsoft will handle all DNS and certificate requirements for the published application. The drawback is that the URL is not likely something users will easily remember and it may cause issues for application developers when they code links to the application into emails and other deliverables.
However, it is possible to use what Microsoft refers to as an alternate domain to publish applications, so the company may use a friendly URL that users will remember and can be easily used by application developers in emails and other deliverables. The alternate on-premises domain must be one that is verified in the Azure AD Premium tenant. So, if we follow the example above, and assume the verified on-premises domain is companyname.com, a viable alternate domain URL for our published application could be https://website.companyname.com. This may be the URL users already use internally to access this application. Using this method does have some requirements, however. The company must provide an SSL certificate to the Azure AD Premium tenant for authentication purposes. This certificate can be a simple subject, wildcard or SAN certificate, as long as it can authenticate the companyname.com domain. Additionally, a CNAME record must be placed into the company’s external DNS zone, to resolve website.companyname.com to website-companyname.msapproxy.net. As inexpensive as certificates have become, this seems a small price to allow users to access application from outside the secure company network, using a URL they are already familiar with.
Azure AD Application Proxy provides one final capability. It can integrate with Integrated Windows Authentication (IWA) to provide pass-through authentication for internal applications configured to use Kerberos Constrained Delegation. This is useful when an enterprise wishes to publish multiple applications to the Azure AD Application Proxy and those applications utilize IWA when users are on the corporate network. While users are now able to access the applications externally, the user experience does not change.
If your enterprise has, or is about to acquire, an Azure AD Premium tenant (either as a stand-alone investment, or through investing in some other Azure service, such as the EMS Suite), New Signature has the knowledge and capability to assist with your implementation.