Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

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.

See how it connects
Alvin Varughese
Written byAlvin Varughese
Founder18 professional certifications