Azure AD Application proxy and some previews

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.

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.

Component	Description
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.

Traffic flow

1. The user connects to the Azure AD Application Proxy service public endpoint maybe from My Apps portal
2. The Application Proxy connector connects to the Application Proxy service (outbound)
3. 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

Use scenarios

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.

And last but not least, You can now add HTTP redirection also, which help you on testing out in example ADFS.

Teams

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

PowerShell samples

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.

Property	Type	Description
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

Maintenance mode

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.

Troubleshooting

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

Closure

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!