Azure AD Application proxy is an essential tool for providing access to your on-premises applications. In the past you could use it as a reverse proxy to internal Web-based (accessible with browser) applications and you could define One URI per application proxy.
Well, this has now changed, later in this post we will see see how, first have to see what Application proxy is and how it works.
Table of Contents
What is AAD App proxy?
I’m so glad that you asked, ok you didn’t but telling anyway.
Application Proxy works with:
- Web applications that use Integrated Windows authentication for authentication
- Web applications that use form-based or header-based access
- Web APIs that you want to expose to rich applications on different devices
- Applications hosted behind a Remote Desktop Gateway
- Rich client apps that are integrated with the Microsoft Authentication Library (MSAL)
The Application Proxy connectors exclusively employ outbound connections to the cloud-based Application Proxy service on ports 80 and 443. There is no need to open firewall ports for incoming connections or components in the DMZ since there are no inbound connections. All connections are made in the outgoing direction and through a secure channel.
And with the following authentication types
- Authentication based on headers – When the application utilizes headers for authentication, this sign-on technique is employed.
- Authentication based on forms or a password – Users log in to the application using a username and password the first time they access it using this authentication mechanism. Azure AD gives the program the username and password after the initial sign-on. In this case, Azure AD handles authentication.
- Authentication using SAML – Applications using either the WS-Federation or SAML 2.0 protocols can employ single sign-on that is based on SAML. By leveraging the user’s Azure AD account, SAML single sign-on uses Azure AD to authenticate the user to the application.
And you also add your own Custom domain to, if you have SSL, you need a public certificate for it.
So how it does work?
Connectors can run on a machine that is not domain-joined. However, if you want single sign-on (SSO) to applications that use integrated Windows authentication (IWA), you need a domain-joined machine. In this case, the connector machines must be joined to a domain that can perform Kerberos Constrained Delegation on behalf of the users for the published applications.
The following components are involved in the setup.
|Endpoint||The endpoint is a URL or an end-user portal. Users can reach applications while outside of your network by accessing an external URL. Users within your network can access the application through a URL or an end-user portal. When users go to one of these endpoints, they authenticate in Azure AD and then are routed through the connector to the on-premises application.|
|Azure AD||Azure AD performs the authentication using the tenant directory stored in the cloud.|
|Application Proxy service||This Application Proxy service runs in the cloud as part of Azure AD. It passes the sign-on token from the user to the Application Proxy Connector. Application Proxy forwards any accessible headers on the request and sets the headers as per its protocol, to the client IP address. If the incoming request to the proxy already has that header, the client IP address is added to the end of the comma separated list that is the value of the header.|
|Application Proxy Connector||The connector is a lightweight agent that runs on a Windows Server inside your network. The connector manages communication between the Application Proxy service in the cloud and the on-premises application. The connector only uses outbound connections, so you don’t have to open any inbound ports or put anything in the DMZ. The connectors are stateless and pull information from the cloud as necessary. For more information about connectors, like how they load-balance and authenticate, see Understand Azure AD Application Proxy connectors.|
|Active Directory (AD)||Active Directory runs on-premises to perform authentication for domain accounts. When single sign-on is configured, the connector communicates with AD to perform any additional authentication required.|
|On-premises application||Finally, the user is able to access an on-premises application.|
- The user connects to the Azure AD Application Proxy service public endpoint maybe from My Apps portal
- The Application Proxy connector connects to the Application Proxy service (outbound)
- The Application Proxy connector connects to the target application
You only need the Identity sync for SSO and to let Azure AD perform an pre-authentication. If you don’t need them, you can just use Cloud-based users.
Did you know that many many other services use this lightweight style agent, to name a few. But all of the following need to be installed to a Domain joined server.
- Exchange Modern Hybrid https://learn.microsoft.com/en-us/exchange/hybrid-deployment/hybrid-agent
- Pass Through Authentication (PTA) https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta-quick-start
- Azure AD Connect Cloud Sync https://learn.microsoft.com/en-us/azure/active-directory/cloud-sync/how-to-prerequisites?tabs=public-cloud
There are several different ways to user Application proxy, I will name a few of them to show the scalability of the service.
Publish CRL or ADFS
Here’s an excellent article from Michael Niehaus on publishing Certificate Revocation Lists with Application proxy.
I will just make couple of additions. You can use Your own custom domain by adding the FQDN to custom domains. If You already have the suffix just add the prefix and don’t have to even verify it because the root domain is already verified.
Note that if you are publishing CRL, it needs to be HTTP not HTTPS.
New-AzureADApplicationProxyApplication -DisplayName "MyApplicationName" -ExternalUrl "http://YourPreferredFQDN/certenroll/" -InternalUrl "http://YourCAName/certenroll/" -ExternalAuthenticationType Passthru
And last but not least, You can now add HTTP redirection also, which help you on testing out in example ADFS.
And you can even connect it with Teams
Web Application Firewall (WAF)
And protect the Proxy with WAF
Defender for Cloud apps
And not to forget Defender for Cloud apps protection
There is also a good amount of PowerShell commands that you can use with AAD Application proxy. Listing your apps, users and groups or to configure them with scripts.
Complex scenarios (Preview)
Complex scenarios means an application with multiple different URLs and with the use of the cross-origin resource sharing (CORS) mechanism, restricted resources on a website can be requested from a domain other than the one that originally delivered the initial resource.
Basically it means that complex app scenarios will aid in effective authentication and avoiding CORS problems, such as those that utilize distinct domain suffixes or different ports or routes in the URL internally.
Only two application segments per complex distributed application are currently supported and only a wildcard application can have application segments specified.
If all application parts are eliminated, a complicated application will function as a wildcard application, allowing access to all valid URLs inside the defined domain.
Keep in mind that a simple app will always take preference over a wildcard application.
See more here on the problems that you can overcome with this feature
Add an application, at this point you can’t add segments to it.
See more on how to add an wildcard application.
You have to open the application once created to add the segments
And choose Add app segment
You will be displayed the settings page
And once you add them, you edit them from the same place
If you want to add CORS rule, see the definitions below.
|allowedHeaders||String Collection||The request headers that the origin domain may specify on the CORS request. The wildcard character * indicates that any header beginning with the specified prefix is allowed.|
|allowedMethods||String Collection||The HTTP request methods that the origin domain may use for a CORS request.|
|allowedOrigins||String Collection||The origin domains that are permitted to make a request against the service via CORS. The origin domain is the domain from which the request originates. The origin must be an exact case-sensitive match with the origin that the user agent sends to the service.|
|id||String||The unique identifier for the CORS configuration that is assigned to a CORS rule by Azure AD. Not nullable. Read-only. Supports $filter (eq).|
|maxAgeInSeconds||Integer||The maximum amount of time that a browser should cache the response to the preflight OPTIONS request.|
|resource||String||Resource within the application segment for which CORS permissions are granted. / grants permission for the whole app segment.|
If you want to use Wildcards externally, you have to point your URL to with a CNAME to <yourAADTenantId>.tenant.runtime.msappproxy.net
See the full Learn article here
User login normally to the application that is inside on-premises. In my example ADFS (just for testing, not in production)
If you need to do so maintenance tasks, you can flip the switch inside the application that use Application proxy and users will see a maintenance page.
And here is the out of service message that the users will get.
This is an excellent addition but you cannot edit the page as of now. Hopefully in the future there will me a possibility for it also as it’s also possible to edit other company pages.
Although also this feature is still in preview but were getting there.
Microsoft has excellent documentation on the steps for troubleshooting Application proxy. It has been here for a long time, so there is a lot of different scenarios for it
Like said, Application proxy has been with us for a long time and there would be many more tales to tell but I will leave it here for now.
Maybe something in the future on App proxy, let’s see.
Have a nice week!