This chapter covers Microsoft Entra Application Proxy, a key component of Microsoft Entra ID that provides secure remote access to on-premises web applications without requiring a VPN. For the MS-102 exam, this topic appears in Domain 2.3 (Implement and manage identity governance and access) and typically accounts for 5-8% of questions. You will be tested on deployment architecture, connector configuration, Kerberos constrained delegation, and integration with other Microsoft Entra features like Conditional Access. Mastery of this topic is essential for managing hybrid identity scenarios.
Jump to a section
Imagine a large company with a central mailroom (the Application Proxy service) that handles all external mail for employees working from home. The company has a single public street address (the proxy endpoint in Microsoft Entra), but employees have internal office numbers (internal application URLs) that outsiders cannot directly reach. When a remote employee wants to receive a package (access an app), they first send a request to the mailroom with their ID badge (Microsoft Entra ID token). The mailroom verifies the badge, then looks up a directory to find the employee's internal office number (the connector maps the external URL to the internal URL). The mailroom then dispatches an internal courier (the connector) to deliver the package to the correct office. The courier uses a secure, pre-established tunnel (outbound HTTPS connection) from inside the company, so no firewall ports need to be opened. The employee receives the package without ever revealing their office number to the outside world. If the package requires special handling (Kerberos constrained delegation), the courier can impersonate the employee to retrieve it from a locked cabinet (backend server). The mailroom also logs all deliveries for auditing. This setup allows secure remote access without changing internal network configurations.
What is Microsoft Entra Application Proxy?
Microsoft Entra Application Proxy (formerly Azure AD Application Proxy) is a feature of Microsoft Entra ID that enables users to access on-premises web applications from outside the corporate network through a secure reverse proxy service. It eliminates the need for VPN connections or inbound firewall rules by establishing outbound-only connections from the internal network to the cloud service.
Why It Exists
Traditional remote access solutions require opening inbound ports (e.g., 443, 8443) on the corporate firewall, which increases attack surface. VPNs require client software, configuration, and often degrade performance. Application Proxy provides a zero-trust approach: users authenticate via Microsoft Entra ID (with support for MFA and Conditional Access), and traffic is proxied through Microsoft's cloud infrastructure. The service is designed for HTTP/HTTPS applications, including those using Windows Integrated Authentication (WIA) via Kerberos constrained delegation (KCD).
How It Works Internally
The architecture consists of two main components: the Application Proxy service (cloud side) and Application Proxy connectors (on-premises). The flow is as follows:
User requests access: A remote user navigates to the external URL, e.g., https://sales.contoso.com. DNS resolves this to the Application Proxy service endpoint (e.g., *.msappproxy.net).
Authentication at the cloud: The Application Proxy service redirects the user to Microsoft Entra ID for authentication. The user must authenticate (e.g., via password, MFA, or passwordless). Upon success, Microsoft Entra ID issues a token that includes the user's identity and any claims (e.g., group memberships).
Token validation and routing: The Application Proxy service validates the token and then determines which connector group can handle the request. It selects an available connector from the group (round-robin or least-loaded).
Connector communication: The connector maintains a persistent outbound connection to the Application Proxy service over TCP 443. This connection is established during connector installation and uses TLS 1.2+. The connector polls the service for pending requests every few seconds (default: 10 seconds).
Request forwarding: The Application Proxy service sends the request (including the user's token and original headers) to the connector over the outbound channel. The connector then forwards the request to the internal application URL (e.g., http://sales-server:8080).
Pre-authentication vs. passthrough: In pre-authentication mode (default), the connector sends the user's token to the backend application. If the application uses Windows Integrated Authentication, the connector performs Kerberos constrained delegation (KCD) to obtain a Kerberos ticket for the user on the backend. In passthrough mode, authentication is handled by the backend application directly.
Response flow: The backend application sends its response back to the connector, which sends it back over the outbound channel to the Application Proxy service, which forwards it to the user's browser.
Key Components, Values, Defaults, and Timers
Connector versions: Connectors are updated automatically by the service. The minimum supported version is 1.5.1526.0. Connectors older than 90 days are blocked from accepting requests.
Connector groups: Connectors can be grouped to handle specific applications. A group can have multiple connectors for load balancing and fault tolerance. The default group is "Default."
Outbound ports: Only TCP 443 (HTTPS) is required for connector-to-cloud communication. No inbound ports are needed.
Connector heartbeats: Connectors send a heartbeat to the service every 60 seconds. If the service doesn't receive a heartbeat for 5 minutes, the connector is marked as offline.
Session timeout: The default session timeout for Application Proxy is 10 minutes of inactivity. This is configurable per application via the "Application Proxy" settings.
Header size limit: The maximum header size for requests forwarded by the connector is 256 KB. Larger headers may cause failures.
URL length: The maximum URL length is 32,768 characters.
Connector certificate: The connector uses a certificate issued by the Microsoft CA for TLS. This certificate is renewed automatically.
Configuration and Verification Commands
To install a connector:
Download the Microsoft Entra Private Network Connector from the Microsoft Entra admin center.
Run the installer on a Windows Server 2016+ machine (not a domain controller).
Sign in with a Global Administrator or Application Administrator account.
The connector registers with the tenant and appears in the admin center under "Enterprise applications > Application proxy > Connectors."
To configure an application:
In the Microsoft Entra admin center, go to "Enterprise applications > Application proxy."
Click "New application" and provide:
- Name - Internal URL (e.g., http://sales-server:8080) - External URL (automatically generated, e.g., https://sales-contoso.msappproxy.net) - Pre-authentication (Microsoft Entra ID or Passthrough) - Connector group - Additional settings: translate URLs in headers, use HTTP-Only cookies, etc.
Verification commands (PowerShell):
- Get-AzureADApplicationProxyApplication - Lists all Application Proxy apps.
- Get-AzureADApplicationProxyConnector - Lists all connectors.
- Get-AzureADApplicationProxyConnectorGroup - Lists connector groups.
How It Interacts with Related Technologies
Microsoft Entra ID: Provides authentication and authorization. Application Proxy relies on Microsoft Entra ID for pre-authentication and token issuance.
Conditional Access: Policies can be applied to Application Proxy apps for MFA, device compliance, location, etc. The Application Proxy service respects Conditional Access policies during pre-authentication.
Kerberos Constrained Delegation (KCD): For apps using Windows Integrated Authentication, the connector must be configured with KCD to delegate the user's identity to the backend service. This requires the connector machine to be domain-joined and have the proper service principal names (SPNs) set.
Microsoft Entra Private Access: Part of Microsoft Entra Internet Access (Global Secure Access), this newer service replaces Application Proxy for some scenarios but uses a similar connector architecture.
Azure AD Domain Services: If the backend application is in Azure IaaS and uses Azure AD DS, KCD can be configured via Azure AD DS.
Specific Values, Defaults, and Timers
Connector update interval: Connectors check for updates every 30 minutes.
Connector idle timeout: The outbound connection to the cloud can idle for up to 10 minutes before being recycled.
Maximum request size: 4 MB for the request body (including headers).
Maximum number of connectors per tenant: 500.
Maximum number of applications per tenant: 500.
Connector group limit: 100 connectors per group.
Supported authentication methods: Microsoft Entra ID pre-authentication, passthrough, and Windows Integrated Authentication (via KCD).
Application types: Web applications (HTTP/HTTPS) and web APIs. Not for native client apps or non-web protocols.
Trap Patterns and Common Mistakes
Wrong pre-authentication mode: Candidates often confuse pre-authentication with passthrough. Pre-authentication means the user must authenticate with Microsoft Entra ID before reaching the app; passthrough means the app handles authentication directly. The exam may ask which mode is required for Conditional Access – answer: pre-authentication.
Connector placement: Connectors must be on a Windows Server that can reach the backend application and the Microsoft Entra cloud. They cannot be installed on a domain controller or a client OS.
Kerberos delegation: For KCD to work, the connector machine must be trusted for delegation. The exam may test that the connector's computer account needs to be allowed to delegate to the backend service's SPN.
Port requirements: Only outbound 443 is needed. Inbound ports are not required. A common wrong answer is that inbound 443 is needed.
Session timeout: The default inactivity timeout is 10 minutes, not 30 minutes or 1 hour. This is configurable per app.
Step-by-Step Mechanism (Detailed)
User browses to external URL: The user types https://sales-contoso.msappproxy.net in their browser. DNS resolves to an IP address owned by Microsoft (e.g., 13.107.6.183).
TLS handshake with Application Proxy service: The browser establishes a TLS 1.2+ connection with the Application Proxy service. The service presents a certificate for *.msappproxy.net.
Redirection to Microsoft Entra ID: The service sends an HTTP 302 redirect to the Microsoft Entra ID login endpoint (https://login.microsoftonline.com/...). The browser follows the redirect.
Authentication: The user enters credentials. If MFA is required, they complete it. Microsoft Entra ID issues an access token and a session cookie.
Token sent to Application Proxy: The browser sends the token to the Application Proxy service (via cookie or header). The service validates the token signature, expiry, and audience.
Connector selection: The service checks the application's connector group. It selects a connector that is online (heartbeat within last 5 minutes). It sends the request details to that connector over the persistent outbound TCP 443 connection.
Connector forwards to backend: The connector receives the request. It reconstructs the HTTP request (method, headers, body) and sends it to the internal URL (e.g., http://sales-server:8080). For KCD, the connector first obtains a Kerberos ticket for the user from the domain controller, then sends the request with the Kerberos token in the Authorization header.
Backend processes and responds: The backend server processes the request and sends back an HTTP response.
Connector sends response to cloud: The connector sends the response back over the same outbound connection.
Cloud sends response to user: The Application Proxy service forwards the response to the user's browser.
Performance and Scalability Considerations
Each connector can handle approximately 200-400 concurrent requests, depending on hardware.
For high availability, deploy at least two connectors per connector group.
Connectors are stateless; any connector can handle any request for its group.
Latency is typically <100ms for the cloud hop, plus the internal network latency.
The service has built-in load balancing across connectors in a group.
Security Features
Pre-authentication: Users must authenticate with Microsoft Entra ID before accessing the app.
Conditional Access: Policies can enforce MFA, device compliance, and location.
Header injection: The service can inject custom headers (e.g., X-Forwarded-For) for backend logging.
HTTP-Only cookies: Can be enforced to prevent XSS attacks.
TLS termination: The cloud service terminates TLS, so traffic between connector and backend can be plain HTTP (but HTTPS is recommended).
Interaction with Microsoft Entra Internet Access (Global Secure Access)
Microsoft Entra Internet Access (formerly Global Secure Access) is a newer service that provides a secure web gateway. It can replace Application Proxy for some scenarios by using the same connector infrastructure but with a different routing mechanism (via Microsoft Entra Private Access). The exam may compare the two: Application Proxy is for publishing specific apps; Private Access is part of a broader SSE solution.
Install Application Proxy Connector
Download the connector installer from the Microsoft Entra admin center (Enterprise applications > Application proxy). Run it on a Windows Server 2016 or later that is domain-joined and has network access to both the backend application and the internet (outbound HTTPS). The installer registers the connector with the tenant by authenticating with a Global Admin or Application Admin account. After installation, the connector appears in the admin center under Connectors. It establishes an outbound TLS 1.2+ connection to the Application Proxy service at *.msappproxy.net. The connector sends heartbeats every 60 seconds. If no heartbeat for 5 minutes, the connector is marked offline.
Configure Connector Group
In the admin center, create connector groups under Enterprise applications > Application proxy > Connector groups. Assign connectors to groups. Connectors can belong to only one group at a time. Groups are used to associate apps with specific connectors (e.g., by region or capability). For high availability, assign at least two connectors per group. If no group is specified, the app uses the Default group. The connector group must have at least one online connector for the app to function.
Publish an Application
In the admin center, go to Enterprise applications > Application proxy > New application. Fill in: Name, Internal URL (the on-premises URL), External URL (auto-generated or custom domain), Pre-authentication (Microsoft Entra ID recommended), Connector group, and additional settings like Translate URLs in headers. For apps using Windows Integrated Authentication, configure Kerberos constrained delegation: set the internal application SPN and choose the delegation method (e.g., negotiated or Kerberos). The app is now published and visible in the enterprise applications list.
Configure Conditional Access Policy
Navigate to Microsoft Entra admin center > Protection > Conditional Access > New policy. Assign the policy to the Application Proxy app (select the enterprise application). Configure conditions (e.g., require MFA, device compliance, trusted location). The policy is evaluated during pre-authentication. If the user fails the policy, the Application Proxy service returns an access denied page. Conditional Access policies are applied to the cloud portion of the flow; the connector does not evaluate policies.
Test Access from External Network
From a browser outside the corporate network (e.g., using a mobile hotspot), navigate to the external URL (e.g., https://sales-contoso.msappproxy.net). You should be redirected to Microsoft Entra ID for login. After authentication, you are redirected back to the app. The app should load correctly. Verify that URLs within the app are translated if needed (the service can rewrite HTML links to point to the external URL). Check browser developer tools for any mixed content warnings (HTTP vs HTTPS). Confirm that the session remains active for the configured timeout period.
Enterprise Scenario 1: Remote Access to Internal CRM
A multinational company uses a legacy CRM system hosted on-premises in a data center. The CRM uses Windows Integrated Authentication and requires users to be domain-joined for seamless access. The company wants to enable remote employees and contractors to access the CRM without VPN. They deploy Application Proxy with two connectors in each regional data center (North America and Europe). They configure the CRM as an Application Proxy app with pre-authentication and Kerberos constrained delegation. The connector machines are domain-joined and have the proper SPNs set. Conditional Access policies require MFA for all external users and block access from non-corporate devices. The solution scales to 10,000 users with negligible latency overhead. Common misconfiguration: forgetting to set the SPN on the connector machine, causing KCD failures. They monitor connector health using the admin center and set up alerts for offline connectors.
Enterprise Scenario 2: Publishing a Vendor Portal
A company provides a web-based vendor portal hosted on an internal IIS server. The portal uses forms-based authentication and is not integrated with AD. The company wants to avoid inbound firewall changes. They deploy Application Proxy with passthrough pre-authentication, meaning the portal handles authentication itself. The connector is installed on a dedicated server in the DMZ. They configure the internal URL as http://vendorportal:80 and the external URL as https://vendorportal-contoso.msappproxy.net. They also enable header translation to pass the original client IP via X-Forwarded-For. The solution works without any changes to the vendor portal code. However, they notice that session timeouts are too short; they adjust the application's idle timeout to 30 minutes in the Application Proxy settings. They also enable HTTP-Only cookies to improve security.
Common Failure Modes
Connector offline: Often due to network changes (proxy, firewall) or certificate expiration. The connector must be able to reach *.msappproxy.net on TCP 443. If the connector uses an outbound proxy, it must be configured in the connector's config file.
KCD failures: The connector machine must be trusted for delegation. The service account for the backend must have the correct SPN. If the user is not synchronized to Microsoft Entra ID via Microsoft Entra Connect, KCD may fail because the UPN doesn't match.
URL translation issues: If the internal application uses absolute URLs (e.g., /images/logo.png), the proxy must translate them to the external URL. This is configured via "Translate URLs in headers" and "Translate URLs in application body." Failure to enable these causes broken links in the app.
Certificate errors: If the external URL uses a custom domain (e.g., sales.contoso.com), a custom TLS certificate must be uploaded. Without it, users see certificate warnings.
Performance Considerations
Each connector can handle ~200-400 concurrent requests. For 10,000 users, 5-10 connectors per region are sufficient.
Backend latency adds to the total response time. If the backend is slow, users experience delays.
The cloud service has a 4 MB request size limit. Large file uploads may fail; consider using a separate file transfer solution.
Connector updates occur automatically; reboots may be required after major updates.
What MS-102 Tests on Application Proxy
The MS-102 exam tests your ability to deploy, configure, and troubleshoot Application Proxy. Specific objectives under Domain 2.3 include:
Implement Application Proxy: plan connector placement, configure connector groups, publish applications.
Configure authentication: choose between pre-authentication and passthrough, set up Kerberos constrained delegation.
Manage access: integrate with Conditional Access, configure custom domains, set session timeouts.
Troubleshoot: identify connector issues, KCD failures, and URL translation problems.
Common Wrong Answers and Why Candidates Choose Them
"Application Proxy requires inbound port 443 to be open on the firewall." – This is the most common trap. Candidates assume a reverse proxy needs inbound access. Reality: Connectors only make outbound connections; no inbound firewall rule is needed.
"Install the connector on a domain controller for best performance." – Candidates think the connector needs direct access to AD for KCD. Reality: Domain controllers are not supported; the connector must be on a separate Windows Server.
"Passthrough authentication supports Conditional Access." – Candidates confuse passthrough with pre-authentication. Only pre-authentication allows Microsoft Entra ID to enforce Conditional Access.
"The external URL must match the internal URL." – Candidates think DNS must match. Reality: The external URL is typically a subdomain of msappproxy.net or a custom domain; it does not need to match the internal URL.
"Connectors need inbound port 3389 (RDP) for management." – While RDP might be used for management, it is not required for Application Proxy functionality.
Specific Numbers and Values That Appear on the Exam
Default session inactivity timeout: 10 minutes (configurable per app).
Maximum connectors per tenant: 500.
Maximum applications per tenant: 500.
Connector heartbeat interval: 60 seconds; offline after 5 minutes of no heartbeat.
Outbound port: TCP 443 only.
Minimum Windows Server version: 2016.
Pre-authentication modes: Microsoft Entra ID (default) and Passthrough.
Kerberos constrained delegation requires the connector machine to be domain-joined and trusted for delegation.
Edge Cases and Exceptions
Custom domains: If you use a custom domain (e.g., sales.contoso.com), you must upload a TLS certificate for that domain. The certificate must not be expired and must match the domain.
Connector update failures: If a connector fails to update for 90 days, it is blocked. You must reinstall or manually update.
Multiple forests: If the backend app is in a different AD forest, KCD requires trust between forests and proper SPN configuration.
Non-HTTP apps: Application Proxy only supports HTTP/HTTPS. For RDP, SSH, or other protocols, use Microsoft Entra Private Access or a VPN.
How to Eliminate Wrong Answers
If the question involves Conditional Access, the application must use pre-authentication.
If the question involves KCD, look for options that include domain-joined connector and SPN configuration.
If the question asks about firewall rules, only outbound 443 is correct.
If the question asks about connector placement, eliminate answers that mention domain controllers, client OS, or Azure VMs that cannot reach the backend.
If the question involves session timeout, the default is 10 minutes.
Application Proxy uses outbound-only connections (TCP 443) – no inbound firewall ports needed.
Connectors must be installed on Windows Server 2016+ that is NOT a domain controller.
The default session inactivity timeout is 10 minutes (configurable per application).
For Windows Integrated Authentication, configure Kerberos constrained delegation (KCD) with proper SPNs.
Conditional Access policies require pre-authentication mode (not passthrough).
Each tenant supports up to 500 connectors and 500 applications.
Connectors send heartbeats every 60 seconds; marked offline after 5 minutes of no heartbeat.
Custom domains require uploading a TLS certificate for that domain.
Application Proxy only supports HTTP/HTTPS applications – not RDP, SSH, or other protocols.
Connectors are updated automatically; versions older than 90 days are blocked.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Entra Application Proxy
Publishes specific on-premises web apps via a reverse proxy in the cloud.
Requires connectors installed on Windows Server 2016+ for on-premises connectivity.
Supports HTTP/HTTPS applications only; uses Kerberos constrained delegation for WIA.
Pre-authentication via Microsoft Entra ID or passthrough; integrates with Conditional Access.
Mature service (formerly Azure AD Application Proxy) with broad enterprise adoption.
Microsoft Entra Private Access (Global Secure Access)
Part of Microsoft Entra Internet Access (Global Secure Access); provides a secure web gateway for all internet traffic.
Uses the same connector infrastructure but can also route traffic via Microsoft Entra ID for zero-trust network access.
Supports TCP and UDP applications (e.g., SSH, RDP) via Private Access, not just HTTP/HTTPS.
Always uses Microsoft Entra ID pre-authentication; integrates deeply with Conditional Access and session policies.
Newer service (still in preview/general availability stages) with evolving feature set.
Mistake
Application Proxy requires inbound firewall rules on the corporate firewall.
Correct
No inbound ports are needed. Connectors establish outbound connections to the Application Proxy service over TCP 443. All traffic flows outbound from the internal network.
Mistake
You can install the connector on a domain controller for simplicity.
Correct
Microsoft explicitly disallows installing the connector on a domain controller. It must be installed on a Windows Server 2016 or later that is not a domain controller.
Mistake
Passthrough pre-authentication supports Conditional Access policies.
Correct
Conditional Access requires the user to authenticate with Microsoft Entra ID. Passthrough mode does not perform Microsoft Entra ID authentication, so Conditional Access cannot be applied. Only pre-authentication mode supports it.
Mistake
The external URL must be the same as the internal URL.
Correct
The external URL is typically a subdomain of msappproxy.net or a custom domain. It does not need to match the internal URL. The connector maps the external URL to the internal URL.
Mistake
Connectors require inbound port 3389 (RDP) for management.
Correct
RDP is not required for the connector to function. Management can be done via the admin center or PowerShell. RDP might be used for server maintenance but is not a requirement of Application Proxy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Only outbound TCP 443 (HTTPS) is required from the connector server to the Application Proxy service at *.msappproxy.net. No inbound ports are needed. The connector also needs to reach the backend application (e.g., port 80 or 443) internally. For DNS and domain controller communication, standard internal ports (UDP 53, TCP 389, etc.) are needed for KCD.
No. Application Proxy only supports HTTP/HTTPS web applications. For non-web protocols like RDP, SSH, or legacy TCP/UDP apps, you should use Microsoft Entra Private Access (part of Global Secure Access) or a VPN.
First, ensure the connector server is domain-joined. In the on-premises AD, configure the connector computer account to be trusted for delegation to the backend service's SPN (e.g., HTTP/sales-server.contoso.com). In the Application Proxy settings, specify the internal application SPN and select the delegation method (negotiate or Kerberos). The connector will then obtain a Kerberos ticket for the authenticated user and forward it to the backend.
The Application Proxy service marks the connector as offline after 5 minutes of no heartbeats. Applications assigned to that connector group will fail with a 504 Gateway Timeout or similar error. To avoid downtime, deploy at least two connectors per group and monitor their status using the admin center or Azure Monitor alerts.
Yes. You can configure a custom domain (e.g., sales.contoso.com) instead of the default *.msappproxy.net domain. You need to upload a TLS certificate for that domain and verify ownership by adding a TXT record to your DNS. Custom domains are useful for branding and for applications that require a specific domain for cookies or redirects.
Yes, if the app supports Windows Integrated Authentication (WIA) and you configure Kerberos constrained delegation. For other authentication methods (e.g., forms-based, SAML), you can use password-based SSO or integrate with Microsoft Entra ID via federation. Application Proxy itself does not handle SSO; it relies on Microsoft Entra ID and KCD.
First, check the connector status in the admin center. Ensure the connector is online and assigned to the correct group. Next, verify that the connector can reach the internal URL (test from the connector server). Check the Application Proxy logs on the connector (Event Viewer > Applications and Services Logs > Microsoft > AadApplicationProxy > Connector). Common issues: DNS resolution failure, firewall blocking outbound 443, or the backend server not responding.
You've just covered Microsoft Entra Application Proxy — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?