3.4 Authorization for On-Premises Resources

Why Hybrid Authorization Design Matters

Very few enterprises taking AZ-305 are cloud-only from day one. Most have an existing on-premises Active Directory Domain Services (AD DS) forest with years of accumulated groups, group policy, and application authorization logic. The exam's "authorizing access to on-premises resources" bullet tests whether you can design the synchronization and trust relationship that lets a single identity authenticate once and be authorized correctly both in the cloud and on-premises — without maintaining two separate, drifting sets of credentials.

Hybrid Identity: The Core Concept

Hybrid identity means a single user object is represented consistently in both on-premises AD DS and Microsoft Entra ID, synchronized so that a password change, a group membership change, or a disabled account propagates to both environments. This is the foundation that lets an on-premises AD DS group continue to drive file-share NTFS permissions while the same user also signs in to Azure-hosted apps through Entra ID with one identity and one credential.

Choosing a Synchronization Tool

Two Microsoft tools synchronize on-premises AD DS objects into Entra ID, and AZ-305 expects you to recommend the right one for the stated constraints:

For an exam scenario describing a straightforward single-forest company wanting cloud-first simplicity, Cloud Sync is the forward-looking recommendation. For a scenario describing a complex multi-forest environment or one that explicitly needs device writeback or Exchange hybrid features not yet in Cloud Sync, Entra Connect Sync remains the correct choice — and the two can run side by side temporarily during a migration.

Authentication Methods for Hybrid Identity

Once objects are synchronized, three methods determine how the password itself is validated:

• Password Hash Synchronization (PHS) — a hash of the password hash is synced to Entra ID; Entra ID validates sign-ins independently. Simplest, most resilient to on-premises outages.
• Pass-through Authentication (PTA) — Entra ID forwards the sign-in to a lightweight on-premises agent that validates against AD DS directly, so the password never leaves the premises. Requires on-premises AD DS to be available at sign-in time.
• Federation (AD FS) — a separate federation server issues tokens after validating against AD DS. Highest complexity and infrastructure burden; chosen only when a specific requirement (e.g., smart-card sign-in AD FS already supports) cannot be met by PHS or PTA.

Extending Authorization to the Cloud Without Deploying Domain Controllers

Some scenarios need a directory that behaves like on-premises AD DS (LDAP, Kerberos, NTLM) but hosted for cloud workloads, without an architect having to build and patch domain controllers. Two options:

1. Extend AD DS to Azure IaaS — deploy domain controllers as Azure virtual machines, joined to the existing forest. Full feature parity with on-premises AD DS, but the team owns patching, backup, and high availability of those VMs.
2. Microsoft Entra Domain Services — a fully managed domain, one-way synchronized from Entra ID, that provides LDAP/Kerberos/NTLM compatibility for legacy or lift-and-shift applications without deploying or patching any domain controllers. It supports a single flat OU structure and cannot write changes back to on-premises AD DS — the sync direction only flows Entra ID → Managed Domain.

Recognize the trade-off: option 1 gives full control at the cost of operational overhead; option 2 removes operational overhead at the cost of flexibility (no forest trusts to on-premises, one-way sync, simplified schema).

Exam Scenario

A company is lifting a legacy, on-premises line-of-business application to Azure VMs. The application authenticates users via Kerberos against AD DS and has no code path to call Entra ID directly, and the team wants to avoid deploying and patching new domain controllers. The correct recommendation is Microsoft Entra Domain Services: it exposes an LDAP/Kerberos/NTLM-compatible managed domain synchronized one-way from Entra ID, letting the legacy app authenticate exactly as it does today without any code change and without the team owning domain-controller infrastructure.

Common Traps

• Recommending Entra Domain Services when the scenario needs write-back to on-premises AD DS or a multi-domain forest trust — Managed Domain sync is one-way and supports a flat structure only.
• Choosing Federation (AD FS) by default for "extra security" — it is the highest-complexity option and should only be recommended when PHS or PTA cannot satisfy a specific stated requirement.
• Assuming Cloud Sync and Entra Connect Sync are mutually exclusive forever — they can coexist during a deliberate migration.
• Forgetting that Pass-through Authentication requires on-premises AD DS availability at sign-in time — an outage on-premises blocks sign-in, unlike PHS.