This chapter covers Azure AD Application Proxy, a key identity governance feature that provides secure remote access to on-premises web applications without a VPN. For the AZ-104 exam, this topic appears in roughly 5-8% of questions, often in the context of hybrid identity and secure access scenarios. You will learn the internal mechanism, configuration steps, and common exam pitfalls to ensure you can deploy and troubleshoot this service confidently.
Jump to a section
Imagine your company has a mailroom with a single public address, but employees work in a secure building with no external doors. When a package arrives for an employee, the mailroom clerk opens it, reads the internal recipient, and repackages it with a new envelope addressed to the employee's desk number. The clerk also logs every package so they know which desk to forward replies. Employees never give out their desk number; they only tell senders to use the mailroom address. The mailroom also checks the sender's ID against an approved list before forwarding. If a sender is not pre-approved, the package is returned. The clerk handles many packages simultaneously, each requiring a lookup of the destination desk. This is exactly how Azure AD Application Proxy works: it sits in the cloud, receives external requests, authenticates them, and then creates a new connection to the internal application, translating the public URL to the internal server address. No direct inbound firewall ports are opened, and all traffic is proxied through the cloud service, just as the mailroom handles all packages without ever revealing the internal building layout.
What Is Azure AD Application Proxy and Why It Exists
Azure AD Application Proxy (App Proxy) is a feature of Azure Active Directory that enables secure remote access to on-premises web applications without requiring a VPN or inbound firewall rules. It acts as a reverse proxy service hosted in Azure that authenticates users via Azure AD and then proxies requests to internal applications. The primary use cases include:
Publishing legacy on-premises apps (e.g., SharePoint, IIS apps) for remote employees
Providing conditional access and MFA for those apps
Eliminating the need for site-to-site VPN or DirectAccess
How App Proxy Works Internally – The Mechanism
App Proxy consists of two main components: the cloud service (in Azure) and the App Proxy connector (installed on-premises). The connector is a lightweight Windows service that outbound-connects to the Azure service over HTTPS (port 443). This outbound-only model is critical: no inbound firewall ports are required on-premises.
Here is the step-by-step flow for a user request: 1. User browses to the external URL (e.g., https://app-proxy.contoso.com/). 2. DNS resolves this to the Azure App Proxy service endpoint. 3. Azure AD authenticates the user (if not already authenticated) and enforces conditional access policies. 4. Azure AD issues a security token for the session. 5. The App Proxy cloud service sends the request to an available connector via a persistent outbound connection. 6. The connector receives the request, rewrites the headers (e.g., Host header to internal server name), and forwards it to the internal application over HTTP or HTTPS. 7. The application responds, and the connector sends the response back through the same persistent connection to the cloud service. 8. The cloud service returns the response to the user.
Key Components, Values, Defaults, and Timers
Connector: A Windows service (Microsoft AAD Application Proxy Connector) that must run on Windows Server 2012 R2 or later. It requires outbound access to *.msappproxy.net and *.servicebus.windows.net on port 443. The connector can be load-balanced by installing multiple connectors in a connector group.
Connector Group: A logical grouping of connectors that can be assigned to specific applications. By default, there is a 'Default' group. Connectors in a group share the load. If a connector fails, traffic is redistributed to others.
Session Timeout: The default application session timeout is 4 hours. This can be configured per application from 1 to 24 hours.
Pre-authentication: Two modes – Azure Active Directory (default) or Passthrough. With Azure AD pre-auth, the user must authenticate to Azure AD before the request reaches the connector. With Passthrough, no Azure AD authentication is required (the app handles it).
SSL/TLS: The external endpoint uses an Azure-managed certificate (wildcard *.msappproxy.net) or a custom domain with your own certificate. The connector-to-app communication can be HTTP or HTTPS.
Header Translation: By default, the connector translates the Host header to the internal server URL. You can configure custom headers if needed.
Kerberos Constrained Delegation (KCD): For integrated Windows authentication (IWA) apps, the connector can perform KCD to authenticate the user as a Kerberos ticket. Requires the connector server to be domain-joined and configured for delegation.
Configuration and Verification Commands
To install the connector, download from the Azure portal (Azure AD > Application proxy > Download connector service) and run the installer on a Windows Server. It will register with your Azure AD tenant.
To publish an application via PowerShell:
New-AzureADApplicationProxyApplication `
-ObjectId $appObjectId `
-ExternalUrl "https://app-proxy.contoso.com/" `
-InternalUrl "http://internal-app:8080/" `
-ExternalAuthenticationType "AadPreAuthentication" `
-IsTranslateHostHeaderEnabled $trueTo verify connector status:
Get-AzureADApplicationProxyConnector | Format-List MachineName, Status, ConnectorGroupIdStatus can be 'active' or 'inactive'. Inactive connectors cannot serve requests.
Interaction with Related Technologies
Azure AD Conditional Access: App Proxy integrates directly. You can require MFA, compliant devices, or location-based policies for the published app.
Azure AD B2B: External users can access App Proxy apps if they are invited as guest users.
Azure AD Application Proxy vs. Azure Front Door: Front Door is a global load balancer and CDN for web apps, not a reverse proxy for on-premises apps. App Proxy specifically handles authentication and secure tunneling.
Azure AD Application Proxy vs. VPN: VPN gives full network access; App Proxy gives application-level access only. App Proxy is more secure for selective app exposure.
Important Exam Numbers and Defaults
Connector outbound ports: 443 (HTTPS) to *.msappproxy.net and *.servicebus.windows.net.
Connector must have access to the internal application URL (typically HTTP or HTTPS).
Default session timeout: 4 hours.
Number of connectors per tenant: up to 500.
Number of connector groups per tenant: up to 100.
Connectors per group: up to 100.
Applications per tenant: up to 500.
Pre-authentication modes: Azure AD (default) and Passthrough.
Custom domain requires a verified custom domain in Azure AD and uploading a certificate.
For KCD, the connector must be domain-joined and the service account must have delegation permissions.
Install App Proxy Connector
On a Windows Server (2012 R2 or later) that can reach the internal application, download the connector installer from Azure AD > Application proxy. Run the executable; it prompts for Azure AD global administrator credentials to register the connector with the tenant. The connector service (Microsoft AAD Application Proxy Connector) starts automatically and establishes an outbound connection to Azure. Verify in Azure portal that the connector status shows 'Active'.
Create Connector Group (Optional)
By default, all connectors are in the 'Default' group. For high availability or regional isolation, create a new connector group in Azure AD > Application proxy > Connector groups. Add connectors to the group. Assign the group to specific applications so only those connectors handle traffic for that app. If no group is assigned, the Default group is used.
Publish the Application
In Azure AD > Enterprise applications > New application > On-premises application. Provide: Name, Internal URL (e.g., http://internal-server:8080/app), External URL (e.g., https://app-proxy.contoso.com/app), Pre-authentication type (Azure AD or Passthrough). Configure additional settings like header translation, session timeout, and SSL termination. Assign users/groups to the application.
Configure Conditional Access (Optional)
Navigate to Azure AD > Conditional Access > New policy. Select the published application as the target. Configure conditions (e.g., require MFA, require hybrid Azure AD joined device). This enforces security policies before the request reaches the connector. The policy applies at the cloud level before proxying.
Test and Monitor
Access the external URL in a browser. You should be redirected to Azure AD login (if pre-auth is Azure AD). After authentication, the application should load. If issues occur, check connector event logs (Event Viewer > Applications and Services Logs > Microsoft > AadApplicationProxy > Connector). Also use the Azure portal's 'Application proxy' blade to view connector health and application activity.
Enterprise Scenario 1: Remote Access to Legacy HR Portal
A multinational company has an on-premises HR portal built on ASP.NET that uses Integrated Windows Authentication. Remote employees previously used VPN to access it, causing performance issues and security risks. The company deploys Azure AD Application Proxy with KCD. Two connectors are installed on domain-joined servers in different datacenters for redundancy. The app is published with Azure AD pre-authentication, requiring MFA via Conditional Access. The internal URL is http://hr-app:8080. The connector group is set to 'HR Connectors' containing both connectors. Users access https://hr.contoso.com, authenticate with Azure AD, and the connector performs KCD to impersonate the user and retrieve the Kerberos ticket for the HR app. Performance improves because the connector caches Kerberos tickets. Misconfiguration: if the connector is not domain-joined, KCD fails and users see a 401 error.
Enterprise Scenario 2: Partner Access to Supply Chain App
A manufacturing company needs to give external partners access to a supply chain management app without onboarding them to the corporate network. They use Azure AD B2B to invite partners as guest users. The app is published via App Proxy with Passthrough pre-authentication because the app itself handles authentication. The external URL is https://supplychain.contoso.com. Partners authenticate using their own identity providers (via B2B federation). The connector translates headers to the internal server. Scale: The app handles 10,000 daily requests; three connectors handle the load. Performance consideration: If the connectors are underpowered (e.g., 1 vCPU), latency increases. The company upgrades to 4 vCPU servers. Common issue: If the internal app uses host header validation, the connector must have header translation enabled; otherwise, the app rejects requests.
Scenario 3: Mobile Access to Internal CRM
A sales team uses iPads to access an internal CRM web app. The company wants to enforce device compliance before granting access. They publish the CRM via App Proxy with Azure AD pre-authentication and a Conditional Access policy requiring the device to be marked as compliant in Intune. The connector is installed on a single server in the main office. The external URL uses a custom domain (crm.contoso.com) with a certificate bound to the proxy. When a user accesses the URL from an unmanaged device, they are blocked by Conditional Access. If the connector goes down, all access fails—so the company adds a second connector in a different office for high availability.
Exam Focus for AZ-104
This topic falls under objective '1.1 Manage Azure Active Directory identities' but specifically in the context of 'Configure and manage Azure AD Application Proxy'. The exam tests your ability to:
Understand the difference between Azure AD pre-authentication and Passthrough.
Know the default session timeout (4 hours) and how to change it.
Identify correct connector requirements (Windows Server 2012 R2+, outbound port 443).
Recognize when KCD is needed (for IWA apps).
Understand that App Proxy does not require inbound firewall ports.
Common Wrong Answers and Why Candidates Choose Them
'App Proxy requires inbound port 443 on the firewall.' – Wrong. The connector initiates outbound connections only. Candidates confuse it with a traditional reverse proxy that listens inbound.
'App Proxy can be used for non-web applications (e.g., SSH).' – Wrong. App Proxy only supports HTTP/HTTPS web applications. For non-web, use Azure Bastion or VPN.
'Passthrough pre-authentication still requires Azure AD authentication.' – Wrong. Passthrough means no Azure AD authentication; the app handles it. Candidates think pre-auth always means Azure AD.
'You must install the connector on the same server as the application.' – Wrong. The connector can be on any server that can reach the app. It does not need to be on the app server.
Specific Numbers and Terms on the Exam
Connector outbound URLs: *.msappproxy.net, *.servicebus.windows.net
Default session timeout: 4 hours (240 minutes)
Connector OS: Windows Server 2012 R2 or later
Pre-authentication modes: Azure Active Directory (default), Passthrough
Header translation: Enabled by default; can be disabled if the app needs the original host header.
Custom domain: Requires a verified custom domain in Azure AD and a certificate.
Edge Cases and Exceptions
If the internal application uses host header validation (e.g., SharePoint), you may need to disable header translation.
For KCD, the connector must be domain-joined and the service account must have 'Trust this user for delegation to specified services only' with protocol transition.
If you use Passthrough pre-authentication, Conditional Access policies cannot be applied because Azure AD does not see the request.
The connector does not support HTTP/2; it uses HTTP/1.1.
How to Eliminate Wrong Answers Using Mechanism
If a question asks about 'securing on-premises apps without VPN', App Proxy is correct. If it mentions 'inbound firewall rules', App Proxy is incorrect because it uses outbound only. If the app is not HTTP/HTTPS, eliminate App Proxy. If the question mentions 'global load balancing', think Azure Front Door or Traffic Manager, not App Proxy.
App Proxy provides secure remote access to on-premises web apps without VPN.
The connector only uses outbound connections on port 443 to *.msappproxy.net and *.servicebus.windows.net.
Default session timeout is 4 hours; can be set per application from 1 to 24 hours.
Pre-authentication modes: Azure AD (default) or Passthrough.
For Integrated Windows Authentication, you need Kerberos Constrained Delegation (KCD).
Connector must run on Windows Server 2012 R2 or later and be domain-joined for KCD.
App Proxy requires Azure AD Premium P1 or P2 licenses.
Custom domain requires a verified custom domain in Azure AD and a certificate.
Header translation is enabled by default; disable if the app requires the original host header.
Connector groups enable load balancing and high availability.
These come up on the exam all the time. Here's how to tell them apart.
Azure AD Application Proxy
Proxies HTTP/HTTPS web apps only
No inbound firewall ports needed
Provides Azure AD pre-authentication and SSO
Requires Azure AD Premium P1/P2
Connector runs on Windows Server on-premises
Azure Bastion
Provides RDP/SSH access to VMs
Requires inbound port 443 to Bastion service
Does not provide SSO; uses Azure AD authentication for portal
Pricing per hour and per GB data transfer
No on-premises component; native Azure service
Azure AD Application Proxy
Application-level access only
No network-level access to internal resources
Easier to manage for selective app exposure
No client software required for users
Integrates with Conditional Access
VPN (Site-to-Site or Point-to-Site)
Full network access to all resources
Requires VPN client or gateway configuration
More complex to restrict access to specific apps
Can cause higher attack surface
Conditional Access can be applied but less granular
Mistake
App Proxy requires opening inbound firewall ports for the connector.
Correct
The connector only establishes outbound connections to Azure on port 443. No inbound ports are required on the on-premises firewall.
Mistake
App Proxy can publish any TCP or UDP application.
Correct
App Proxy only supports HTTP/HTTPS web applications. For non-web apps, use Azure Bastion or a VPN.
Mistake
Passthrough pre-authentication still authenticates the user with Azure AD.
Correct
Passthrough means no Azure AD authentication occurs; the request is passed directly to the internal app, which must handle authentication itself.
Mistake
The connector must be installed on the same server as the internal application.
Correct
The connector can be on any Windows Server that has network access to the internal application. It does not need to be co-located.
Mistake
You can use App Proxy without any Azure AD licensing.
Correct
App Proxy requires Azure AD Premium P1 or P2 licenses. Free Azure AD does not include this feature.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure AD pre-authentication requires the user to authenticate with Azure AD before the request is proxied to the on-premises app. This allows you to apply Conditional Access policies. Passthrough sends the request directly to the app without Azure AD authentication; the app handles its own authentication. Use Passthrough if the app already has its own auth and you don't want Azure AD to intercept.
No, App Proxy only supports HTTP/HTTPS web applications. For RDP or SSH access to VMs, use Azure Bastion. For other TCP/UDP applications, use a VPN or Azure Virtual Network integration.
No. The connector only establishes outbound connections to Azure on TCP port 443. No inbound ports are required on the on-premises firewall.
The connector server must be domain-joined. In Active Directory, configure delegation on the connector's computer account: 'Trust this computer for delegation to specified services only' with 'Use any authentication protocol'. Then specify the service principal name (SPN) of the internal application (e.g., HTTP/internal-server). The connector will then request Kerberos tickets on behalf of users.
If a connector is inactive, requests that would be routed to its connector group will fail. To ensure high availability, install multiple connectors in the same connector group. Azure automatically distributes requests among active connectors.
Yes. You need to add a custom domain to Azure AD (verify ownership) and upload a TLS/SSL certificate for that domain. Then set the external URL to use that domain. The certificate must not be expired and must match the domain.
Yes. Users can access published apps from any device with a browser, including mobile. Conditional Access can enforce device compliance. There is no native app required; it works via the browser.
You've just covered Azure AD Application Proxy — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?