What is Azure AD application proxy?

Microsoft Entra application proxy (previously Azure Active Directory, or Azure AD, Application Proxy) is a feature of Microsoft Entra ID that gives remote users secure access to on-premises web applications. No VPN, no DMZ infrastructure, no inbound firewall ports.

If you run a hybrid environment, you almost certainly have legacy on-premises apps that were never built for cloud access. Application proxy sits Entra ID in front of those internal web applications. Users authenticate through Entra ID (with MFA and Conditional Access enforced), and only after that does traffic reach the on-premises app through an outbound connector.

Before application proxy existed, publishing internal apps externally usually meant configuring a traditional reverse proxy or VPN. Both require inbound connections, complex network configurations, and a separate authentication stack. Application proxy skips all of that.

Authentication happens in the cloud, and traffic routes through connectors that make only outbound HTTPS connections.

Microsoft rebranded this feature from "Azure AD Application Proxy" to "Microsoft Entra application proxy" as part of the broader Entra ID renaming in July 2023. The functionality itself hasn't changed.

Application proxy isn't included in free Entra ID tiers. You need a Microsoft Entra ID P1 or P2 license. P1 comes with Microsoft 365 E3 and Enterprise Mobility + Security E3; P2 comes with Microsoft 365 E5 and Enterprise Mobility + Security E5.

How application proxy works

Application proxy has three components: the Entra ID cloud service, an on-premises application proxy connector, and the on-premises application itself. The connector is a lightweight agent you install on a Windows Server in your network. It maintains an outbound HTTPS connection to the Entra ID service and requires no inbound firewall ports.

Here's the traffic flow when a user accesses a published application:

1. The user navigates to the external URL published through Entra ID.
2. Entra ID enforces pre-authentication: MFA challenges, Conditional Access policy evaluation (device compliance, location restrictions, sign-in risk), and session controls.
3. If the user fails any check, the request is blocked before it reaches your network.
4. On successful authentication, Entra ID issues a token to the user's device.
5. The user's device presents the token to the application proxy cloud service.
6. The cloud service forwards the request to the on-premises connector over the existing outbound HTTPS connection.
7. The connector authenticates to the on-premises application using the configured SSO method and returns the response back through the same path.

All traffic between the user, Entra ID, and the connector is TLS-encrypted. Because connectors initiate only outbound connections, you don't need to open any inbound ports on your firewall.

You can group connectors for high availability and application segmentation. Each connector group should contain at least two connectors so that a single server failure doesn't take an application offline.

SSO methods supported

Application proxy supports several single sign-on methods depending on how your on-premises application handles authentication.

Protocol support

Application proxy supports HTTP and HTTPS web applications. It does not natively proxy non-HTTP protocols such as RDP, SSH, or SMB. If you need remote access to non-HTTP resources, Microsoft offers Entra Private Access as a zero-trust network access (ZTNA) alternative.

Figure 1. Application proxy architecture and traffic flow showing Entra ID, the cloud service, the outbound connector, and the on-premises application.

Application proxy vs. Entra Private Access

Microsoft introduced Entra Private Access as part of the Global Secure Access suite. It goes beyond HTTP/HTTPS web applications to provide zero-trust network access for any TCP/UDP protocol, including RDP, SSH, and SMB.

Application proxy is still fully supported and remains the standard choice for publishing on-premises web applications. Entra Private Access is the newer option for securing access to non-web resources without a VPN.

If your access requirements stop at web applications, application proxy covers it without additional client software. If you need to publish RDP jump hosts, SSH endpoints, or file shares, Entra Private Access is what you're looking at.

Use cases for application proxy

Remote workforce access. Your employees access internal web apps (SharePoint on-premises, intranet portals, line-of-business applications) from any location without a VPN client. Entra ID enforces MFA and device compliance before granting access, so the experience is a browser sign-in rather than a VPN connection.

Third-party vendor and partner access. External contractors access specific on-premises apps through Entra ID B2B collaboration. Application proxy restricts access to published apps only, meaning vendors never get broad network access. You control exactly which applications each external identity can reach.

BYOD environments. Personal devices access corporate web apps through a browser with no VPN client installation required. Conditional Access policies can require compliant browsers, block risky device states, or restrict access to approved locations.

Connector deployment and best practices

The connector is the on-premises component that makes application proxy work. It runs on a Windows Server (2016 or later recommended) with outbound HTTPS connectivity to the Entra ID service. No inbound ports required.

Connector groups let you assign connectors to groups that isolate traffic by application, geography, or sensitivity level. Each connector group should have at least two connectors for high availability. If your apps span multiple data centers, deploy a connector group per location.

Network proximity matters. Install connectors close to the application servers they front. A connector in the same data center as the target app reduces latency; a connector on a different continent adds round-trip time that users will notice.

Connectors auto-update by default. For controlled update rollouts in production environments, deploy multiple connector groups and update one group at a time to avoid downtime.

Don't install connectors on domain controllers. Don't install them on servers running other reverse proxy or web application firewall software either, because port and process conflicts cause unpredictable behavior.

Security risks targeting application proxy deployments

Application proxy introduces a secure access path, but misconfiguration or incomplete hardening can create openings that attackers will look for.

Misconfigured pre-authentication. When you publish an app, you choose between Entra ID pre-authentication and passthrough authentication. Passthrough skips Entra ID entirely and sends unauthenticated requests straight to the internal app. If an admin publishes an app with passthrough, anyone who discovers the external URL can reach the internal application directly, with no identity verification.

Every published app should use Entra ID pre-authentication unless there's a documented exception with compensating controls.

Compromised connector servers. The connector has outbound access to the Entra ID cloud service and inbound access to on-premises applications. If an attacker compromises the connector host, they can intercept traffic between the cloud and your apps, or pivot laterally into the internal network. Connector servers should be hardened, patched, and monitored with the same rigor you apply to domain controllers.

Token replay attacks. A stolen Entra ID token can be replayed to access published applications. Without Conditional Access policies that enforce token binding, compliant device requirements, or sign-in risk evaluation, a stolen token grants the same access as a legitimate session. Enforcing Conditional Access with device compliance and sign-in risk policies limits the window and scope of replay.

Exposed legacy applications. Many apps published through application proxy were designed for internal use only. They may lack input validation, session management, or transport encryption. Publishing them externally increases their attack surface.

Before publishing a legacy app, assess it for common web vulnerabilities and apply compensating controls (web application firewall rules, IP restrictions at the Conditional Access layer).

Kerberos delegation abuse. When KCD is the SSO method, the connector's service account holds delegation rights to request Kerberos tickets on behalf of users. If that service account is compromised, an attacker can request tickets for any user to any delegated service. Limit delegation rights to the smallest set of service principal names (SPNs) required, and monitor the connector's service account for anomalous ticket requests.

ADAudit Plus detects Kerberos-based attacks including Kerberoasting and Golden Ticket attacks through its Attack Surface Analyzer. It correlates Entra ID sign-in anomalies with on-premises AD logon events to surface suspicious application access patterns in real time.

Limitations of native monitoring for application proxy

Entra ID provides sign-in logs and audit logs, but native monitoring has gaps that make application proxy activity hard to investigate at scale.

Sign-in log retention. Entra ID retains sign-in logs for 30 days on P1 and P2 tenants. Application proxy sign-in events older than 30 days are gone unless you export them to Azure Monitor, a storage account, or a third-party tool. For compliance frameworks that require one to seven years of log retention, 30 days falls short.

No real-time alerting on proxy-specific failures. Entra ID doesn't offer native real-time alerts when application proxy sign-ins fail at an unusual rate or when a connector goes offline. You can configure diagnostic settings to stream logs to Log Analytics and build alert rules there, but there's no built-in alert profile for application proxy events. Someone has to check the sign-in logs or connector health blade manually, which in practice means problems go unnoticed until users report them.

No cross-correlation with on-premises AD events. Entra ID sign-in logs capture the cloud authentication event for an application proxy session. The corresponding on-premises Kerberos TGT request (Event ID 4768) or service ticket request (Event ID 4769) generated by the connector's KCD delegation appears only in the domain controller's security event log. Native tools don't tie these two events together, so you're left jumping between portals to reconstruct what actually happened.

No consolidated reporting across hybrid logons. Investigating a suspicious application proxy session means cross-referencing Entra ID sign-in logs in the Azure portal with on-premises security event logs in Event Viewer on the relevant domain controller. There's no native view that stitches these events into one timeline.

Limited anomaly detection. Entra ID Identity Protection flags some risky sign-ins (impossible travel, anonymous IP), but it doesn't baseline per-user application proxy access patterns. It can't tell you when a user accesses a specific published application for the first time, or when there's a spike in proxy sign-in failures from a single IP that stays below the global lockout threshold.

Monitoring application proxy activity with ADAudit Plus

What ADAudit Plus monitors for application proxy environments

Entra ID sign-in monitoring. The Cloud Directory tab captures all Entra ID sign-in events, including application proxy sign-ins. The Logon Activity report shows each sign-in with the event type, username, login time, IP address, device information, geo-location, MFA status, MFA method, Conditional Access result, and failure reason. The Logon Failures report isolates failed sign-ins with specific error codes, so you can filter for application proxy failures without scrolling through every cloud sign-in event.

Risk detection for cloud sign-ins. The Risk Detection reports surface risky sign-ins flagged by Entra ID Identity Protection: sign-ins from anonymized IP addresses, impossible travel scenarios, known malicious IPs, and password spray patterns. When a risky sign-in targets a published application, it appears in the same report alongside all other risky cloud sign-ins.

On-premises AD logon correlation. The Active Directory tab captures Kerberos authentication events (Event ID 4768 for TGT requests, Event ID 4769 for service ticket requests) generated when application proxy connectors use KCD for SSO. The Logon Activity report correlates these events with the user's Entra ID sign-in, giving you a single timeline of the hybrid authentication sequence from cloud pre-authentication through on-premises Kerberos delegation.

UBA anomaly detection. The Analytics tab applies machine learning to baseline each user's normal application access patterns. The Unusual Logon Activity Time report flags sign-ins at hours the user has never been active. The First Time Host Accessed by User report flags when a user connects to a host they've never accessed before.

The Unusual Volume of Logon Failure report catches sudden spikes in failed authentications. These reports surface deviations that could indicate compromised credentials being used through application proxy.

Real-time alerts. You can set up alert profiles that trigger email or SMS notifications on specific events: failed Entra ID sign-ins for published applications, account lockouts caused by repeated proxy authentication failures, or risky sign-in detections. You define the conditions, and the alert fires as the event occurs.

Attack Surface Analyzer. The Attack Surface Analyzer detects Kerberoasting, Golden Ticket attacks, pass-the-hash attacks, and other techniques that could target the Kerberos delegation chain used by application proxy connectors. It provides a forensic timeline showing what the threat actor did before and after detection.

Native monitoring vs. ADAudit Plus

FAQ