Recommend a Solution for Authorizing Access to On-Premises Resources — Lesson

Organizations rarely enjoy a greenfield cloud environment. Decades of on-premises investment — SharePoint, SAP, Oracle EBS, custom line-of-business web apps, Windows file shares — anchor identity to Active Directory. When users shift to remote work, mobile devices, and SaaS, the architect's question becomes: how do we let an Entra ID-authenticated user reach a Kerberos-only app sitting on a Windows Server in the Toronto datacentre, without giving everyone a VPN and opening the attack surface wide?

This lesson covers the four primary patterns AZ-305 expects you to recommend: Entra Application Proxy for HTTP/HTTPS apps, Kerberos Constrained Delegation (KCD) for Windows-integrated SSO, Microsoft Entra Domain Services for legacy LDAP/NTLM/Kerberos inside Azure, and hybrid Kerberos (Cloud Trust) for Entra-joined devices reaching on-premises Kerberos resources. Each pattern has a narrow "right answer" zone determined by protocol, client posture, and operational tolerance — and every AZ-305 scenario pins exactly one constraint that picks the winner.

Why This Matters

Every enterprise migrating to Azure hits this question within the first six months. Getting it wrong produces one of two outcomes: a leaky VPN-plus-firewall-hole approach that auditors flag in the next SOC 2 cycle, or a user experience so painful that the CIO gets forwarded complaints from the CFO. On the exam, this area reliably shows up as scenario questions where the correct answer hinges on a single constraint — "the app uses Integrated Windows Authentication", "users are on Microsoft Entra ID-joined Intune devices only", "the app is published at a wildcard domain". Learn the constraints, pick the right pattern, pass the section. In practice, the same decision tree saves your organization from a costly architecture rewrite two years later.

Prerequisites

• Basic Entra ID concepts (tenant, user, group, Conditional Access). Self-check: Can you explain the difference between Entra ID and on-prem Active Directory in one sentence?
• Understanding of Kerberos authentication — TGT, service tickets, SPNs. Self-check: What is a Service Principal Name (SPN), and why does Kerberos require one?
• Familiarity with hybrid identity (Entra Connect, Password Hash Sync, Pass-through Auth, federation). Self-check: Name three sync methods Entra Connect can use.
• Azure networking basics — VNets, subnets, outbound connectivity. Self-check: Why does an Application Proxy connector need only outbound port 443?
• The shared-responsibility model for identity in hybrid scenarios. Self-check: Who owns the Kerberos delegation configuration in a KCD flow — Microsoft or your AD team?

Learning Objectives

By the end of this lesson, you will be able to:

1. Evaluate the four canonical hybrid authorization patterns — App Proxy, KCD, Entra DS, Hybrid Kerberos — against a given set of requirements.
2. Design an Entra Application Proxy deployment including connector groups, custom domains, and pre-authentication mode.
3. Recommend when Kerberos Constrained Delegation is mandatory versus when header-based or SAML-based SSO suffices.
4. Differentiate Microsoft Entra Domain Services from traditional AD DS on IaaS VMs, and justify one choice over the other.
5. Analyse the security and cost trade-offs of hybrid authorization architectures through the Well-Architected Framework pillars of Reliability, Security, and Cost Optimization.
6. Recommend a phased migration path from VPN-based resource access to a modern, identity-gated architecture.

Building Blocks

Entra Application Proxy — Think of it as a bouncer at the front door of your building who also knows every member's face by heart. Formally, Application Proxy is a reverse-proxy service inside Entra ID that publishes internal HTTP/HTTPS applications to the internet via outbound-only connectors running on-prem. Why it matters: it replaces VPN for browser-based apps and lets you apply Conditional Access, MFA, and pre-authentication to apps that were never built with modern auth in mind.

Application Proxy Connector — The pager in the bouncer's pocket. Formally, it is a lightweight Windows service that sits on an on-prem server, opens an outbound TLS tunnel to Entra ID, and receives pre-authenticated requests to forward to internal apps. Why it matters: connectors are the only piece of this pattern you operate — they need capacity planning, patching, and sensible fault domains.

Kerberos Constrained Delegation (KCD) — Handing a bodyguard a letter that says "you may impersonate me, but only at this one hotel". Formally, KCD is an Active Directory feature where one account (the connector's machine account) is permitted to request Kerberos service tickets on behalf of a user, but only to a specified list of target SPNs. Why it matters: it is how App Proxy performs SSO to Integrated Windows Authentication apps without ever seeing the user's password.

Microsoft Entra Domain Services (Entra DS) — A managed Active Directory clone that runs in a corner of your VNet. Formally, it is a PaaS service that provides domain-joinable, LDAP-speaking, Kerberos-issuing domain controllers sourced from your Entra ID tenant — with no AD DS VMs to operate. Why it matters: it is the bridge for legacy Azure workloads (IaaS SQL with Windows Auth, file servers, Linux apps binding via LDAP) that need a classic domain but should not be extended from on-prem.

Hybrid Kerberos (Cloud Trust) — The newest pattern. Microsoft Entra ID-joined Windows devices can acquire a Kerberos TGT for an on-prem realm by presenting a Kerberos trust artefact issued by Entra ID. Why it matters: it lets AAD-joined-only devices reach on-prem file shares and Kerberos apps without a second sign-in — a prerequisite for a frictionless Windows Hello for Business rollout in many deployments.

Pre-authentication — The App Proxy setting that decides who can see the backend at all. Passthrough means anyone on the internet can reach the app (App Proxy only forwards). Microsoft Entra ID (the default, always the recommended answer on the exam) means the user must authenticate to Entra ID first, and Conditional Access is applied before a single packet reaches the connector.

Protocol transition — A Kerberos feature that lets the connector convert a non-Kerberos token (an Entra ID token) into a Kerberos ticket for the backend. Required alongside KCD whenever the original authentication happens in Entra ID rather than on-prem.

Deep Dive

The exam tests four decision patterns. Let us walk each one, explain the wire-level mechanics, and flag where candidates typically go wrong.

Entra Application Proxy — the browser-first pattern

App Proxy is the answer whenever the app is browser-accessible (HTTP/HTTPS) and the business wants to retire VPN. The reference architecture: user's browser → Entra ID (authentication + Conditional Access) → App Proxy service → connector (inside your firewall) → internal app. No inbound firewall ports. Only outbound 443 from the connector to Microsoft.

Three SSO flavours ride on top of App Proxy. Pick one based on what the backend expects to see:

[!TIP] Use connector groups to pin an app to a specific set of connector VMs. For multi-region tenants, a connector group per region minimises latency and provides a fault domain: an outage in UK South does not take down US East.

Connector sizing matters. Microsoft publishes a calculator; the rule of thumb is two connectors per group for redundancy, then scale by concurrent sessions. A connector VM on Windows Server 2019 with 8 vCPU and 16 GB RAM comfortably handles $10{,}000$ concurrent sessions for typical line-of-business traffic.

Kerberos Constrained Delegation — SSO to IWA apps

When the internal app is IIS with Windows Authentication enabled — SharePoint on-prem, most Dynamics on-prem deployments, custom .NET apps — the connector must obtain a Kerberos service ticket as the signed-in user. Two requirements: the connector VM must be domain-joined to the forest hosting the app, and the connector's machine account must be configured to delegate to the app's SPN with protocol transition enabled (TrustedToAuthForDelegation).

[!WARNING] Classic "unconstrained delegation" is a security risk and auditors will flag it. AZ-305 always prefers constrained delegation with protocol transition. Any answer choice referencing unconstrained delegation is a distractor.

The Kerberos flow, from ticket perspective:

1. User signs into Entra ID.
2. App Proxy looks up the on-prem UPN from the Entra ID user (requires the onPremisesUserPrincipalName attribute, populated by Entra Connect).
3. Connector calls S4U2Self against a domain controller to obtain a service ticket to itself on behalf of the user.
4. Connector calls S4U2Proxy against the DC to obtain a service ticket to the app's SPN.
5. Connector presents the ticket to the app; the app sees an authenticated Kerberos user and performs authorization normally.

Microsoft Entra Domain Services — managed AD for lift-and-shift

Entra DS is the right answer when IaaS workloads in Azure need an AD-like environment but the customer does not want to operate domain controllers. Representative scenarios: a SQL Server Availability Group on Azure VMs needing Windows Auth; a RemoteApp farm of session hosts; a Linux app using LDAP bind against a domain; a lift-and-shifted file server that needs group-based NTFS ACLs.

Entra DS provides classic LDAP / LDAPS on port 636, Kerberos and NTLM, domain-join for VMs, limited Group Policy Objects (created inside the managed domain, not pushed from on-prem), and one-way password sync from Entra ID. It does not provide schema extensions, Domain Admin access (you are a member of the AAD DC Administrators group), trusts to on-prem AD beyond a one-way outbound forest trust, or more than one managed domain per tenant.

[!IMPORTANT] Entra DS requires passwords to be resynced after deployment. The managed domain cannot read password hashes until users change their password or an admin triggers a resync via the Entra portal. Plan for a 24 to 48 hour user-communication phase before any workload depends on Entra DS authentication.

Cost is flat per hour per SKU, not per user. The SKU dictates scale (objects, auth throughput) and features such as resource forests. For most mid-size workloads, Enterprise is the correct default because it unlocks the outbound forest trust to on-prem AD that production apps typically need.

Hybrid Kerberos (Cloud Trust) — modern devices meet legacy shares

When users are on Entra ID-joined-only Windows 11 devices — no line-of-sight to a DC, no on-prem domain join — they historically could not reach an on-prem Kerberos resource such as a file share or a Kerberos-only web app without a VPN, because they had no way to request a TGT.

Cloud Trust fixes this. A special AzureADKerberos computer object is created in on-prem AD to represent Entra ID as a trusted Kerberos ticket issuer. When the user signs in with Windows Hello for Business on an AAD-joined device, Entra ID issues a partial TGT (PRT plus Kerberos artefact). The client then exchanges this for a full TGT against the on-prem DC when it reaches a network with line-of-sight to the DC — ExpressRoute, VPN, or an Azure Files endpoint that speaks Kerberos directly.

Worked Examples

Example 1 — Easy: "Replace VPN for a SharePoint 2019 farm"

Problem. Contoso Ltd. has an on-prem SharePoint 2019 farm accessed via SSL VPN. $3{,}000$ users, Entra ID P1 licensed, Entra Connect syncing accounts. The CIO wants to retire the VPN for SharePoint access. What do you recommend?

Step-by-step solution.

1. The app is HTTP/HTTPS → Entra Application Proxy qualifies.
2. SharePoint uses Windows Authentication → KCD with Integrated Windows Auth SSO is required.
3. Pre-authentication mode = Microsoft Entra ID so Conditional Access applies — MFA for external access, compliant device required for sensitive sites.
4. Deploy two or more connectors per region for HA; place them in a dedicated SharePoint connector group.
5. Configure the connectors' machine accounts for KCD delegation to the SharePoint SPN (HTTP/sharepoint.contoso.local).
6. Publish at the custom external URL https://sharepoint.contoso.com with a certificate uploaded to App Proxy.

[!NOTE] Key insight: Entra Application Proxy is always the first answer for browser apps retiring VPN. If the app speaks HTTP/HTTPS and lives on-prem, start there.

Example 2 — Medium: "IaaS SQL with Windows Authentication"

Problem. A team is lifting and shifting a two-node Windows Server SQL 2019 Always On Availability Group to Azure VMs in West Europe. The application connects using Windows Authentication and a SQL-aliased service account. On-prem AD is in Frankfurt; no plans to place DCs in Azure; latency from West Europe to Frankfurt is about 12 ms. No VPN yet, but ExpressRoute is planned. Recommend an authorization pattern.

Step-by-step solution.

1. Windows Auth + SQL AG means the VMs must be domain-joined to something that can issue Kerberos tickets.
2. Option A: extend on-prem AD by placing a read/write DC in the Azure VNet. Viable but adds a server to operate and pays egress for replication.
3. Option B: Microsoft Entra Domain Services. The SQL VMs domain-join the managed domain. Windows Auth works inside the managed domain without on-prem dependency.
4. Option C: ship Kerberos traffic over ExpressRoute to Frankfurt DCs. Works, but the 12 ms round-trip hurts AG health probes and produces brittle failure modes.
5. Recommendation. Entra DS with the Enterprise SKU (so a one-way forest trust to the on-prem forest is possible if service accounts must remain on-prem-sourced). Domain-join the SQL VMs to the managed domain, create SQL service accounts, and enable Kerberos delegation for the SQL SPN.

[!NOTE] Key insight: Entra DS excels when the workload needs AD-style auth but should not depend on on-prem connectivity. Treat it as the Azure-side replica of a classic domain, not an extension.

Example 3 — Hard: "AAD-joined laptop needs an on-prem file share, no VPN"

Problem. Fabrikam has moved $5{,}000$ field engineers to Entra ID-joined-only Windows 11 laptops managed by Intune. They still access an on-prem share at \\fileserver01\engineering over VPN. The security team wants the VPN removed and asks: can these laptops reach the file share over the internet using only modern authentication?

Step-by-step solution.

1. A file share is SMB, not HTTP. App Proxy cannot publish it.
2. AAD-joined devices have no DC line-of-sight — they cannot request a Kerberos TGT unless an alternative issuer exists.
3. Enable Entra Kerberos (Hybrid Kerberos / Cloud Trust), which creates the AzureADKerberos object in on-prem AD so Entra ID can issue TGTs on behalf of AAD-joined clients.
4. Users still need IP reachability to the file server. The right answer is a protocol migration: move the share to Azure Files with identity-based authentication using Entra Kerberos, and remap the drive letter via Intune configuration profile.
5. Decommission \\fileserver01\engineering after the migration window; remove VPN access to SMB at the firewall.

[!NOTE] Key insight: App Proxy is HTTP-only. For non-HTTP protocols (SMB, RDP, SSH), the answer involves either a protocol shift (Azure Files, Azure Bastion) or a tunnelling product (Entra Private Access / Global Secure Access).

Visual Explanations

Decision tree — which pattern to recommend?

Caption: Hybrid authorization decision tree. Start from protocol, branch on pre-authentication needs and client posture. Most AZ-305 scenarios land on one of F, H, or J.

Data flow — App Proxy with KCD

Caption: Six-step App Proxy + KCD flow. Only legs 1 and 2 traverse the internet — legs 3 through 6 all run inside the corporate network.

TikZ — physical topology

Caption: Physical topology of an App Proxy + KCD deployment. All connector-initiated traffic flows outbound through the firewall — no inbound NAT rules required.

Pattern comparison

Pre-authentication mode matrix

Firewall requirements for App Proxy connector

Common Mistakes

❌ Myth: App Proxy can publish any on-prem protocol, including RDP and SMB.

✅ Reality: App Proxy publishes HTTP/HTTPS only. For RDP use Entra Private Access (part of Global Secure Access) or Azure Virtual Desktop; for SMB migrate to Azure Files with identity-based authentication.

Why it is tricky: Microsoft's docs describe an RDP-over-HTML5 scenario fronted by App Proxy, but that is an HTTP gateway in front of RDP — not native RDP over port 3389.

❌ Myth: Entra Domain Services can be joined to on-prem AD as a child domain.

✅ Reality: Entra DS is a separate, managed forest sourced from your Entra tenant. You can create a one-way outbound forest trust (Enterprise SKU) from the managed domain to on-prem, but it is never a child of your existing AD.

Why it is tricky: "Domain Services" sounds like it should extend your domain. It does not — it stands up a new one and syncs identities in.

❌ Myth: KCD requires the connector to be in the same AD domain as the app.

✅ Reality: The connector must be in a domain that can delegate to the app's SPN. Cross-domain and cross-forest KCD are possible with appropriate trusts.

Why it is tricky: Most deployments colocate connector and app in the same domain, so candidates assume it is required. It is preferred for simplicity, not mandatory.

❌ Myth: Hybrid Kerberos (Cloud Trust) requires a VPN for the final auth step.

✅ Reality: Cloud Trust issues the partial TGT over the internet. The client only needs DC line-of-sight when it actually uses the ticket against an on-prem resource — and if the resource itself lives at a cloud endpoint like Azure Files, no on-prem path is needed at all.

Why it is tricky: You get authentication over the internet but still need network reachability for the resource itself, so candidates conflate the two.

❌ Myth: You should set App Proxy pre-authentication to Passthrough when the backend app already does its own auth.

✅ Reality: Microsoft Entra ID pre-auth is strictly additive. The backend still runs its own auth, and you gain Conditional Access, MFA, and DDoS protection at the Entra edge.

Why it is tricky: "The app authenticates anyway" sounds like a reason to skip pre-auth. It is actually a reason to add pre-auth — defence in depth.

Practice Exercises

Exercise 1 🟢 Easy Contoso wants to publish an internal HR web app (IIS, Integrated Windows Auth) to remote workers. Which two Azure components, at minimum, are required?

▶💡 Hint

One is a cloud reverse proxy, one is a Windows service you install on-prem.

▶✅ Solution

Entra Application Proxy (the cloud service) plus the Application Proxy Connector (the on-prem Windows service). The connector needs KCD configured to delegate to the HR app's SPN, and pre-authentication should be set to Microsoft Entra ID so Conditional Access applies.

Exercise 2 🟡 Medium A team asks you to front a legacy web app with App Proxy. The app uses form-based authentication with a custom HTML login page. Can pre-authentication equal Microsoft Entra ID still apply? Explain what the user experience looks like.

▶💡 Hint

Pre-auth runs before the backend sees the request. What happens after?

▶✅ Solution

Yes. App Proxy's Microsoft Entra ID pre-auth gates the user at Entra ID before the backend is contacted. The backend will then still render its form login, so the user signs in twice unless you add a header-based SSO product such as PingAccess, or modernise the app to SAML/OIDC. The second factor is still worth keeping — you gain Conditional Access at the edge.

Exercise 3 🟡 Medium A customer plans to deploy Entra DS in UK South. They have $20{,}000$ users, $200{,}000$ group memberships, and a peak auth rate of 150 binds per second. Which SKU should you recommend and why?

▶💡 Hint

The SKU table ties object count and throughput to a tier, and the forest-trust capability is also SKU-gated.

▶✅ Solution

Enterprise. Standard caps around $100{,}000$ objects and lower auth throughput; Premium is for very large (above $500{,}000$ objects) or resource-forest scenarios. Enterprise also enables the one-way outbound forest trust, which the customer is likely to need for service accounts still rooted in on-prem AD.

Exercise 4 🔴 Hard A security architect rejects App Proxy because "connectors hold delegated admin credentials". Respond with a technical correction.

▶💡 Hint

What does the connector's machine account actually hold, and what is the scope of its permission?

▶✅ Solution

The connector holds no user passwords. For KCD it uses its own machine account, permitted to perform S4U2Self and S4U2Proxy against a constrained list of SPNs with protocol transition. It is not granted Domain Admin. The blast radius is bounded to the SPNs explicitly allowed — a significant reduction compared to a VPN user who has network access to every resource reachable at L3, and compared to unconstrained delegation which permits impersonation to any service in the forest.

Exercise 5 🔴 Hard Design a hybrid authorization approach for a customer with $10{,}000$ Entra ID-joined Windows 11 laptops (Intune-managed, no domain join), a SharePoint 2019 farm on-prem with Integrated Windows Auth, a Windows file share at \\finance01\reports (non-HTTP), and a requirement to remove VPN entirely within 6 months.

▶💡 Hint

You need different patterns for different resources. App Proxy handles one; a protocol migration combined with Hybrid Kerberos handles the other.

▶✅ Solution

1. SharePoint. Publish via Entra Application Proxy with KCD to the SharePoint SPN. Conditional Access requires MFA and a compliant Intune device.
2. File share. Migrate to Azure Files with identity-based authentication using Entra Kerberos. Enable Hybrid Kerberos / Cloud Trust on on-prem AD so AAD-joined laptops can acquire TGTs for Azure Files. Decommission \\finance01\reports after the data migration window.
3. VPN removal. Phased: SharePoint first (lowest risk, most visible user win), file-share migration second (requires a data-copy window and drive-letter remap via Intune). Final step: remove the firewall rule that permitted SMB over VPN.

Exercise 6 🟡 Medium True or false: "A single App Proxy connector group can publish apps from multiple on-prem AD forests." Justify your answer.

▶💡 Hint

Which identity does the connector use to request Kerberos tickets for KCD?

▶✅ Solution

False in practice. A connector can only delegate via KCD to SPNs in forests where its machine account exists, or where a two-way forest trust permits delegation. The standard pattern is one connector group per forest. You can front both with one App Proxy tenant service, but the underlying connector groups are separate.

Exercise 7 🟢 Easy Which outbound ports must be allowed from an App Proxy connector VM to Microsoft for the connector to register and function?

▶💡 Hint

Think modern web service, not legacy AD ports.

▶✅ Solution

TCP 443 outbound only, to a published list of Microsoft FQDNs including *.msappproxy.net, login.microsoftonline.com, and several Azure Service Bus endpoints. No inbound ports are required at the corporate firewall.

Exercise 8 🔴 Hard Your customer has Entra DS deployed and a new requirement arrives: allow Linux VMs to bind to LDAP and use the same identities. List the three configuration steps that matter most.

▶💡 Hint

LDAP, certificates, and network access.

▶✅ Solution

1. Enable Secure LDAP (LDAPS) on the managed domain and upload a certificate whose subject matches the managed domain FQDN.
2. Configure an NSG on the Entra DS subnet to permit TCP 636 inbound from the Linux VM subnet only — never from the internet, even though LDAPS supports a public endpoint.
3. Configure the Linux sssd or realmd to bind using a synced Entra ID service account; passwords must have been changed at least once so that the hash is present in Entra DS.

Summary & Concept Map

• Recognise the protocol first. HTTP/HTTPS points to Application Proxy; SMB/LDAP/Kerberos points to Entra DS or Hybrid Kerberos; non-HTTP without domain infrastructure means protocol migration (Azure Files, Azure Bastion).
• Always prefer Microsoft Entra ID pre-authentication so Conditional Access applies; passthrough is almost always a distractor on the exam.
• Kerberos Constrained Delegation is the SSO mechanism for IWA apps. Unconstrained delegation is wrong on AZ-305 and wrong in production.
• Microsoft Entra Domain Services gives you a managed AD without on-prem dependencies — a parallel forest sourced from Entra ID, not a child domain.
• Hybrid Kerberos (Cloud Trust) is the newest pattern: AAD-joined devices acquire on-prem TGTs via Entra ID, so modern devices can reach legacy resources without a second sign-in.
• Use Well-Architected trade-offs when justifying. App Proxy improves Security (no inbound NAT) and Operational Excellence (centralised CA); Entra DS reduces Ops at the cost of monthly SKU spend; Hybrid Kerberos delivers the best UX but requires Windows 11 and modern tenant posture.
• Every pattern answers a different constraint, and AZ-305 scenarios always pin a constraint that eliminates three of four answers. Train yourself to scan for the pinning clue.