Design Authentication and Authorization Solutions — Lesson

This integrated module covers the five learning objectives that form the authentication and authorization pillar of AZ-305 Unit 1. You will learn how to design authentication flows with Microsoft Entra ID, plan hybrid identity synchronisation, assign permissions through RBAC and ABAC, extend access to on-premises applications, and protect secrets with Azure Key Vault. Each sub-section maps to one LO; cross-cutting worked examples show how the pieces connect in real architectural decisions.

Reference: Ch. 1, §1.2, p. 14–28 of the AZ-305 exam book.

Why This Matters

Every Azure architecture begins with a question: who is allowed to do what? A misconfigured Conditional Access policy can lock out an entire workforce; an over-permissioned service principal can expose production databases to a compromised pipeline. The AZ-305 exam tests your ability to make these decisions under realistic constraints — budget, compliance, user experience, and legacy infrastructure. Mastering authentication and authorization design is not just an exam objective; it is the single most consequential skill set for any Azure solutions architect, because security failures in this layer cascade into every other layer of the stack.

Prerequisites

• Microsoft Entra ID tenant basics — Can you explain what a tenant, directory, and subscription are and how they relate?
• Networking fundamentals (HTTP/S, TLS, DNS) — Can you describe how a browser negotiates a TLS handshake?
• Basic Active Directory concepts (forests, domains, OUs) — Can you sketch the trust relationship between two AD forests?
• Azure portal navigation — Can you locate the Entra ID blade, subscription IAM pane, and Key Vault resource in the portal?
• JSON and ARM template literacy — Can you read a short ARM snippet and identify the resource type?

Learning Objectives

1. Evaluate authentication mechanisms (MFA, passwordless, Conditional Access, B2B/B2C) and recommend the right combination for a given scenario.
2. Design a hybrid identity architecture using Microsoft Entra Connect with the appropriate synchronisation method (PHS, PTA, or federation).
3. Recommend an RBAC/ABAC strategy for Azure resources that satisfies least-privilege and separation-of-duties requirements.
4. Design secure remote access to on-premises applications using Entra ID Application Proxy.
5. Architect a secrets, keys, and certificates management solution using Azure Key Vault with appropriate access policies and networking controls.
6. Analyse cross-cutting scenarios where authentication, authorisation, and secret management decisions interact.

Building Blocks

Microsoft Entra ID (formerly Azure AD) — Analogy: Think of Entra ID as the reception desk of a building — it checks your badge (authentication), looks up which floors you can access (authorisation), and logs your entry (audit). Formal definition: A cloud-based identity and access management service that provides single sign-on, multifactor authentication, and conditional access for users, groups, and service principals. Why it matters: Every Azure resource and most SaaS integrations depend on Entra ID tokens for access decisions.

Conditional Access — Analogy: Like an airport security checkpoint with adaptive rules — frequent flyers with trusted devices go through the fast lane, while first-time travellers get extra screening. Formal definition: A policy engine in Entra ID that evaluates signals (user, device, location, risk level) and enforces access controls (grant, block, require MFA, require compliant device). Why it matters: Conditional Access is the primary enforcement point for Zero Trust in Azure.

Password Hash Synchronisation (PHS) — Analogy: Photocopying a key — the original stays on-premises, but a copy sits in the cloud so either door can recognise you. Formal definition: A sync method where a hash of the on-premises AD password hash is replicated to Entra ID every two minutes. Why it matters: Simplest hybrid identity method; enables cloud-based leaked-credential detection.

Pass-Through Authentication (PTA) — Analogy: A doorbell that rings the on-premises security desk every time someone asks to enter the cloud building. Formal definition: Entra ID forwards the authentication request to an on-premises agent that validates the password against AD in real time. Why it matters: Passwords never leave the on-premises boundary, satisfying certain compliance mandates.

Role-Based Access Control (RBAC) — Analogy: A hotel key card programmed for specific floors — your role determines which resources you can reach. Formal definition: An authorisation system built on role assignments (security principal + role definition + scope) that governs data-plane and control-plane actions on Azure resources. Why it matters: RBAC is the default and recommended authorisation model for Azure; misuse leads to privilege escalation.

Azure Key Vault — Analogy: A bank safety-deposit box — you rent a box (vault), store valuables (secrets, keys, certificates), and only authorised signatories can open it. Formal definition: A managed HSM-backed service for storing and accessing secrets, encryption keys, and X.509 certificates with access governed by RBAC or vault access policies. Why it matters: Eliminates hard-coded credentials; centralises key lifecycle management.

Deep Dive

LO4 — Design an Authentication Solution

The authentication design decision tree starts with who is authenticating: internal workforce, external partners (B2B), or consumers (B2C).

Workforce authentication centres on Entra ID with MFA. The exam tests three MFA methods: Microsoft Authenticator push, FIDO2 security keys, and Windows Hello for Business. Passwordless is the recommended direction — the AZ-305 book emphasises that passwordless authentication reduces phishing surface.

[!TIP] Use named locations in Conditional Access to exempt trusted corporate egress IPs from MFA prompts — this balances security with user experience.

B2B collaboration invites external partners into your tenant as guest users. The guest user authenticates against their home tenant (or a one-time passcode if they have no Entra ID). The key design decision is cross-tenant access settings: you control which external tenants may collaborate and whether their MFA claims are trusted.

B2C creates a separate tenant (*.onmicrosoft.com with the B2C extension) and supports custom user flows (sign-up, sign-in, profile edit) with social identity providers (Google, Facebook, Apple). The exam expects you to choose B2C when the scenario involves consumer-facing apps with self-service registration.

See the LO4-level lesson for a deeper treatment of Conditional Access policy design patterns.

LO5 — Design an Identity Management Solution

Hybrid identity connects on-premises Active Directory to Entra ID through Microsoft Entra Connect (formerly Azure AD Connect). The three synchronisation methods are compared below.

[!WARNING] PTA requires at least 3 authentication agents for production availability. A single-agent deployment is a single point of failure.

Decision rule: Choose PHS unless a regulatory requirement forbids any password derivative in the cloud. Choose PTA if the requirement is real-time on-premises password validation without deploying AD FS. Choose federation only when you need advanced claim rules or a third-party IdP.

Entra Connect also syncs group memberships, device objects (hybrid join), and writeback attributes (password writeback, group writeback). The exam may test which features require Entra ID P1 vs P2 licensing.

See the LO5-level lesson for Entra Connect deployment topologies and staging-server patterns.

LO6 — Design Authorisation for Azure Resources

Azure RBAC uses three elements: security principal (user, group, service principal, managed identity), role definition (set of allowed actions), and scope (management group → subscription → resource group → resource).

Custom roles are defined in JSON when built-in roles are too broad or too narrow.

Attribute-Based Access Control (ABAC) extends RBAC by adding conditions to role assignments — for example, "allow Storage Blob Data Reader only on blobs tagged project=phoenix". ABAC conditions use the @Resource and @Principal attributes.

[!IMPORTANT] ABAC conditions are currently supported on Storage Blob Data * roles only. Don't assume ABAC works on arbitrary resource types — the exam may offer ABAC as a distractor for non-storage scenarios.

See the LO6-level lesson for a complete guide to designing custom roles and ABAC conditions.

LO7 — Design Authorisation for On-Premises Resources

When users are in the cloud but applications are on-premises, Entra ID Application Proxy bridges the gap. A lightweight connector agent installed on an on-premises server creates an outbound HTTPS tunnel to the Application Proxy service — no inbound firewall ports required.

The connector agent authenticates to the cloud service with a certificate; user traffic is:

1. User hits the external URL (e.g., https://expenses.contoso.msappproxy.net).
2. Entra ID authenticates the user and evaluates Conditional Access.
3. Application Proxy routes the request through the connector to the internal URL (e.g., http://expenses.corp.contoso.com).
4. The connector performs Kerberos Constrained Delegation (KCD) if the back-end app uses Windows Integrated Authentication.

[!NOTE] For high availability, deploy at least 2 connectors in the same connector group. Connectors are stateless and auto-update.

See the LO7-level lesson for KCD configuration and connector group design patterns.

LO8 — Design a Solution for Secrets, Keys, and Certificates

Azure Key Vault comes in two tiers: Standard (software-protected keys) and Premium (HSM-backed keys, FIPS 140-2 Level 2). The exam tests when Premium is required — typically for regulatory mandates citing HSM protection.

Access model choice: Key Vault supports two access models — vault access policies (legacy) and RBAC (recommended). With RBAC, you assign Key Vault Secrets User or Key Vault Crypto Officer at the vault scope, unifying authorisation with the rest of Azure.

Networking: Key Vault supports private endpoints and service endpoints. For production, use a private endpoint in the workload VNet so that secret retrieval never traverses the public internet.

Key Vault integrates with several Azure services: App Service and Azure Functions read secrets via Key Vault references (@Microsoft.KeyVault(...)). Azure Disk Encryption uses Key Vault keys. Azure SQL TDE can use a customer-managed key stored in Key Vault.

See the LO8-level lesson for key rotation strategies and certificate auto-renewal patterns.

Worked Examples

Easy — Single-LO: Choose the Right Sync Method

Problem: Contoso has $5{,}000$ users in on-premises AD. Compliance requires that user passwords never leave the corporate network, even as hashes. The IT team has no AD FS infrastructure and wants the simplest possible setup. Which sync method should the architect recommend?

Step-by-step solution:

1. PHS syncs a hash of the password hash to the cloud — eliminated by the "no password derivative in cloud" constraint.
2. Federation requires an AD FS farm — eliminated by the "simplest setup" constraint.
3. PTA validates passwords in real time against on-prem AD via a lightweight agent — satisfies both constraints.
4. Recommend PTA with 3 agents across 2 on-prem servers for availability.

[!NOTE] Key insight: PTA is the middle ground between PHS simplicity and federation flexibility. It keeps passwords on-prem without AD FS overhead.

Medium — Two-LO Crossover: MFA Policy + RBAC Assignment

Problem: Fabrikam's cloud team has 20 engineers. The CISO mandates: (a) all engineers must complete MFA before accessing Azure portal, and (b) engineers may deploy VMs but must not modify IAM role assignments. Design the authentication and authorisation controls.

Step-by-step solution:

1. Authentication (LO4): Create a Conditional Access policy targeting the "Cloud Engineers" security group, scoping to the Azure Management cloud app, requiring MFA grant control.
2. Authorisation (LO6): Assign the Virtual Machine Contributor built-in role to the "Cloud Engineers" group at the relevant subscription scope. This role allows VM lifecycle operations but excludes Microsoft.Authorization/* actions (no IAM changes).
3. Verification: An engineer who passes MFA can create a VM but receives AuthorizationFailed if they attempt New-AzRoleAssignment.

[!NOTE] Key insight: Layering Conditional Access (who can authenticate) on top of RBAC (what they can do) implements defence in depth — neither control alone is sufficient.

Hard — Three-LO Crossover: Hybrid Identity + App Proxy + Key Vault

Problem: Northwind Traders runs a legacy ASP.NET payroll app on-premises using Windows Integrated Authentication. The company is moving to Entra ID for SSO. Requirements: (a) remote workers must access the payroll app without VPN, (b) the app's SQL connection string must not be stored in web.config, and (c) password sync to the cloud is prohibited. Design the end-to-end solution.

Step-by-step solution:

1. Identity (LO5): Deploy Entra Connect with PTA (password stays on-prem). Install 3 PTA agents.
2. Remote access (LO7): Deploy Entra ID Application Proxy with 2 connectors in a connector group. Configure KCD so the connector can obtain Kerberos tickets on behalf of the Entra-authenticated user.
3. Secret management (LO8): Store the SQL connection string in Azure Key Vault. The on-premises app reads the secret at startup via the Key Vault SDK, authenticating with a managed identity registered in Entra ID (or a service principal with certificate-based auth).
4. Conditional Access (LO4): Apply a CA policy to the Application Proxy enterprise app requiring MFA and a compliant device.

[!NOTE] Key insight: Application Proxy + KCD eliminates VPN while preserving Windows Integrated Auth. Key Vault removes the secret from configuration files, and PTA satisfies the no-cloud-password constraint.

Visual Explanations

Conditional Access Policy Evaluation Flow

This diagram shows how Conditional Access collects multiple signals before making a grant/block decision. The policy engine evaluates all matching policies — the most restrictive grant control wins.

Azure RBAC Inheritance Model

Roles assigned at a higher scope propagate downward. A Reader assignment at the management group level grants read access to every resource in every subscription beneath it. Use the narrowest scope that satisfies the requirement.

Hybrid Identity Architecture (TikZ)

This diagram illustrates the full hybrid identity architecture: Entra Connect synchronises identities, PTA agents handle real-time password validation, Application Proxy connectors provide remote access via KCD, and Key Vault is accessed through Entra ID RBAC.

Common Mistakes

❌ Myth: PHS sends user passwords to the cloud, so it fails every compliance audit. ✅ Reality: PHS syncs a SHA-256 hash of the MD4 hash — the original password is never transmitted or stored. Microsoft uses this double-hash to detect leaked credentials (Entra ID Protection). Many compliance frameworks accept PHS when the architecture is documented. Why it's tricky: The word "hash" sounds insecure to non-technical stakeholders, but PHS is actually the most secure sync method because it enables cloud-based threat detection that PTA and federation cannot.

❌ Myth: Assigning Owner at the subscription scope is fine for the lead architect because they need full access. ✅ Reality: Owner includes Microsoft.Authorization/*/Write, meaning the architect can grant anyone any role — including themselves elevated access. Use Contributor for resource deployment and grant User Access Administrator separately with PIM just-in-time activation if IAM changes are needed. Why it's tricky: Owner feels natural for a lead role, but it violates least-privilege and separation-of-duties. The exam specifically tests whether you choose Owner vs. Contributor + PIM.

❌ Myth: Key Vault access policies and RBAC can be used together on the same vault. ✅ Reality: A vault uses either the access-policy model or the RBAC model — not both simultaneously. The property enableRbacAuthorization is a boolean toggle. Microsoft recommends RBAC for new deployments because it unifies authorisation with the rest of Azure. Why it's tricky: Legacy documentation and older exam prep materials show access policies as the primary model, so candidates assume they can layer RBAC on top. They cannot.

❌ Myth: Application Proxy requires opening inbound firewall ports to the on-premises network. ✅ Reality: The connector agent creates outbound HTTPS connections to the Application Proxy cloud service. No inbound ports are needed, which is a key security advantage over traditional reverse proxies and VPNs. Why it's tricky: Candidates familiar with traditional DMZ architectures assume inbound ports are required. The outbound-only model is a distinguishing feature the exam tests.

Practice Exercises

🟢 Easy — Contoso wants to enable self-service password reset (SSPR) for cloud-only users. Which Entra ID licence tier is required?

▶💡 Hint

SSPR for cloud-only users is available at a specific premium tier. Check the licence table in the Deep Dive.

▶✅ Solution

Entra ID P1 is required for SSPR. Entra ID Free supports admin-only password reset, not self-service for all users.

🟢 Easy — Which Key Vault tier must Fabrikam choose if their auditor requires FIPS 140-2 Level 2 HSM-backed keys?

▶💡 Hint

Key Vault has two SKUs. Only one provides HSM backing.

▶✅ Solution

Key Vault Premium. Standard uses software-protected keys only.

🟡 Medium — Woodgrove Bank must ensure that only users on compliant, Intune-managed devices can access their Azure SQL databases via Azure Data Studio. They also need MFA. Design the Conditional Access policy.

▶💡 Hint

You need to combine two grant controls. Think about the operator (AND vs OR).

▶✅ Solution

Create a Conditional Access policy: target all users in the "Database Admins" group, scope to the "Azure SQL Database" cloud app, grant controls = require MFA AND require device to be marked as compliant. The AND operator ensures both conditions must be satisfied.

🟡 Medium — An engineer needs to read secrets from Key Vault kv-prod but should not be able to delete them or manage keys/certificates. Which built-in RBAC role should you assign?

▶💡 Hint

There are separate roles for secrets, keys, and certificates — and "User" vs "Officer" distinctions.

▶✅ Solution

Assign Key Vault Secrets User at the kv-prod resource scope. This role grants Microsoft.KeyVault/vaults/secrets/getSecret/action and list, but not delete or write. It does not grant any key or certificate permissions.

🔴 Hard — Litware Inc. is migrating $12{,}000$ users from three AD forests to a single Entra ID tenant. Forest A uses a .local UPN suffix (non-routable). Forests B and C use routable UPN suffixes. Password sync to the cloud is acceptable. Design the Entra Connect topology and address the UPN issue.

▶💡 Hint

Consider how many Entra Connect servers you need for multiple forests, and what happens when a UPN suffix is non-routable.

▶✅ Solution

Deploy a single Entra Connect server with multi-forest topology (one connector per forest). Use PHS for synchronisation. For Forest A, add an alternative routable UPN suffix (e.g., litware.com) in Active Directory Domains and Trusts, then update user accounts to use the routable suffix before sync. Alternatively, configure Entra Connect to use the mail attribute as the source anchor for sign-in if UPN remediation is infeasible. Deploy a staging-mode Entra Connect server for disaster recovery.

🔴 Hard — Synthetic scenario (AZ-305 style): Adatum Corp runs a legacy Java app on-premises that uses header-based authentication (the app reads X-Remote-User from the HTTP header). Remote workers need SSO via Entra ID without VPN. Which service should the architect recommend, and how does it handle header injection?

▶💡 Hint

Application Proxy supports multiple SSO modes beyond KCD. One of them is specifically designed for header-based apps.

▶✅ Solution

Deploy Entra ID Application Proxy with header-based SSO. Configure the connector to inject the X-Remote-User header with the authenticated user's UPN after Entra ID completes authentication and Conditional Access evaluation. This mode is designed for legacy apps that cannot negotiate Kerberos or SAML. For additional security, apply a Conditional Access policy to the enterprise app requiring MFA.

Summary & Concept Map

• Entra ID is the central identity provider for all Azure workloads; Conditional Access is the enforcement engine for Zero Trust.
• B2B extends your tenant to partners (they authenticate at their home tenant); B2C is a separate tenant for consumer-facing self-service sign-up.
• Entra Connect bridges on-prem AD to the cloud — choose PHS for simplicity and leak detection, PTA for on-prem-only passwords, federation only for advanced claims.
• RBAC + ABAC enforce least-privilege at every scope level; prefer built-in roles, use custom roles sparingly, and always assign to groups, not individuals.
• Application Proxy provides VPN-less access to on-prem web apps through outbound-only connectors with SSO (KCD, header-based, SAML).
• Key Vault centralises secrets, keys, and certificates; use RBAC access model, Premium SKU for HSM, and private endpoints for network isolation.
• Cross-cutting theme: layer authentication (who you are), authorisation (what you can do), and secret management (how credentials are stored) as independent, composable controls.

Connections & Next Steps

This topic integrates five learning objectives into one security design module. For deeper mastery, proceed through the lessons in this order:

1. LO4 — Design an authentication solution — deep dive into Conditional Access policy patterns, B2B cross-tenant settings, and B2C user flow customisation.
2. LO5 — Design identity management — Entra Connect topologies, staging-server failover, and password writeback configuration.
3. LO6 — Design authorisation for Azure resources — custom role JSON authoring, ABAC condition syntax, and PIM activation workflows.
4. LO7 — Design authorisation for on-premises resources — Application Proxy connector groups, KCD setup, and header-based SSO configuration.
5. LO8 — Design secrets, keys, and certificates management — Key Vault networking, key rotation automation, and certificate auto-renewal with App Service.

After completing this topic, move to Topic U1/T3 — Design solutions for logging and monitoring, where you will learn how to audit and monitor the identity decisions made here.