4.2.2. Application Proxy for On-Premises Apps
💡 First Principle: Publishing an internal web app shouldn't mean punching inbound holes. Application Proxy inverts the connection: lightweight connectors inside your network dial out to the service, and external users reach an Entra-protected external URL whose traffic rides those pre-established outbound channels — pre-authentication before a single packet touches the app.
Configuration anatomy: install ≥2 connectors (HA) grouped into connector groups (segment by network/region — an app is served by one group); publish the app with internal URL (what the connector fetches) and external URL (what users hit); choose pre-authentication: Microsoft Entra ID (users authenticate first — CA, MFA, device checks all apply) vs passthrough (no pre-auth — only for special cases). For internal apps expecting Windows auth, configure Kerberos constrained delegation (KCD): the connector, trusted for delegation, exchanges the user's Entra identity for a Kerberos ticket to the app — cloud SSO in front, integrated Windows auth behind. Header-based and SAML on-prem apps are likewise supported.
Placement versus its neighbors (the 2.4.2 table from the other side): App Proxy = inbound publishing of individual web apps to users without agents (partners, unmanaged browsers); Private Access = outbound client-based ZTNA for your workforce to anything TCP/UDP. Both use the same connector family — the difference is who initiates and what protocols flow.
⚠️ Exam Trap: Passthrough pre-authentication skips Entra sign-in entirely — no CA, no MFA, no identity in front of the app. Any stem requiring MFA/CA on a published app mandates Entra ID pre-authentication; passthrough answers are wrong unless the requirement is explicitly "no authentication at the proxy."
Reflection Question: Your intranet app uses integrated Windows authentication. Walk the token chain for a remote user from browser to app — naming where OAuth ends, where Kerberos begins, and which component is trusted to bridge them.