Recommend an Identity Management Solution — Lesson

This lesson covers the identity lifecycle—how on-premises and cloud-based identities are synchronized, provisioned, and managed in hybrid and cloud-native Azure environments. Based on AZ-305 exam guidance (Ch. 2, §2.2, p. 47–65), the focus is on synchronization strategy, Seamless SSO, group sync, B2B/B2C, and managed identities. Identity management is distinct from authentication (LO4) and authorization (LO6/7) — we emphasize the lifecycle: how identities are created, synced, and deprovisioned.

Why This Matters

Identity management underpins security architecture. In hybrid organizations, on-premises directories contain thousands of user accounts; moving to Azure requires a synchronization strategy that is secure, low-latency, and maintainable. Wrong choices lead to:

• Orphaned accounts in the cloud with no on-premises counterpart (manual cleanup cost).
• Sync failures that break productivity (users cannot sign in).
• Security gaps (e.g., federation without proper token validation).
• B2B/B2C confusion (guest collaboration vs. customer identity, different policies).
• Managed identity misuse (resource-to-resource auth becomes fragile if you pick system-assigned when user-assigned is better).

AZ-305 expects you to recommend the right identity solution given a scenario: a multi-site enterprise, a startup going cloud-first, a partner ecosystem requiring B2B access, or a customer-facing app needing B2C. This lesson equips you to make that call.

Prerequisites

• Active Directory basics — domain controller, OU, group policy, trust relationships. Self-check: what is the role of a domain controller in Kerberos authentication?
• Microsoft Entra ID (Entra ID) fundamentals — tenants, users, groups, app registrations, role assignments. Self-check: what is the difference between a security group and a Microsoft 365 group in Entra ID?
• Azure networking — VNets, on-premises connectivity (ExpressRoute, VPN). Self-check: which connectivity method does Entra Connect use to reach Entra ID — internet HTTPS or private endpoint?
• PKI and certificates — SSL/TLS, token signing, federation metadata. Self-check: why does AD FS require a token-signing certificate?
• Authentication concepts — passwords, MFA, SSO, SAML, OAuth 2.0, OpenID Connect. Self-check: what is the difference between SAML and OpenID Connect?

Learning Objectives

After completing this lesson, you will be able to:

1. Evaluate synchronization methods (PHS, PTA, Federation) and recommend the right one for a given scenario (latency, security, complexity).
2. Configure Seamless SSO and explain how it interacts with PHS/PTA to reduce password prompts.
3. Design group synchronization (scoping filters, group writeback) for role-based access control in hybrid deployments.
4. Distinguish B2B from B2C identities and recommend collaboration tools (guest users, B2B cross-tenant access) vs. customer identity platforms (custom policies, external identity providers).
5. Choose between system-assigned and user-assigned managed identities for workloads and explain when to avoid managed identities entirely (switch to service principals).
6. Architect an end-to-end identity solution combining Entra Connect sync, Seamless SSO, managed identities, and B2B/B2C policies.

Building Blocks

Entra Connect — Analogy: think of a postal sorting office that takes letters from your local mailboxes (on-prem AD) and delivers copies to a central hub (cloud Entra ID) on a regular schedule. → Formal definition: an on-premises synchronisation engine (formerly Azure AD Connect) that replicates user, group, and contact objects from Active Directory to Microsoft Entra ID. It supports three authentication methods: PHS, PTA, and Federation. → Why it matters: Entra Connect is the bridge between your on-prem identity store and the cloud — getting its sync method and scoping right determines sign-in latency, disaster recovery posture, and compliance stance.

Password Hash Sync (PHS): Entra Connect hashes the user's on-prem password and syncs the hash to the cloud. The user types their on-prem password at cloud sign-in; Azure computes the hash and matches it. No password exposure over the internet.

Pass-Through Authentication (PTA): User enters password at cloud sign-in; Azure forwards it to an on-prem agent, which validates it against Active Directory. The password never leaves the organization.

Federation (AD FS) — Analogy: a trusted notary who vouches for your identity — the cloud never sees your password; it only sees the notary's signed stamp. → Formal definition: AD FS (or a third-party STS) acts as a trust broker; the user is redirected on-prem for authentication, and AD FS issues a SAML token back to Entra ID. → Why it matters: Federation gives full control over authentication logic (custom MFA, hardware tokens, biometrics) but carries the highest infrastructure and maintenance cost.

Seamless SSO — Analogy: an automatic badge swipe — your domain-joined laptop silently proves your identity via Kerberos, so you never type a password for cloud apps. → Formal definition: an optional add-on for PHS or PTA that uses the AZUREADSSOACC computer account in on-prem AD to issue Kerberos tickets accepted by Entra ID. → Why it matters: eliminates password fatigue for corporate network users without requiring Federation infrastructure.

Group Synchronization: Entra Connect syncs on-prem security groups and distribution groups to the cloud. Writeback allows cloud-created groups to sync back on-prem (requires Enterprise licensing).

Managed Identities: Azure resources (VMs, App Services, Functions, Logic Apps, Data Factory, Synapse, Kubernetes) get an identity from Entra ID without managing secrets. System-assigned = 1:1 with resource. User-assigned = many resources share one identity.

Service Principals: The Azure object backing an app registration or managed identity. Used for resource-to-resource authentication.

B2B (Business-to-Business): Invite external users (partners, vendors, contractors) as guests into your Entra ID tenant. They retain their home org identity. Useful for collaboration, not customer identity.

B2C (Business-to-Customer): A separate Entra ID B2C tenant for customer-facing apps. Customers sign up, reset passwords, and authenticate without an internal user account. Supports external identity providers (Google, Facebook, SAML, OpenID Connect).

Deep Dive

1. Synchronization Methods: PHS vs. PTA vs. Federation

Password Hash Sync (PHS)

• How it works: Every two minutes, Entra Connect hashes on-prem passwords (one-way, salted) and syncs them to the cloud. User signs into Azure with the same password.
• Pros: Low latency (no on-prem call required), simple to deploy, built-in disaster recovery (if on-prem AD is down, users can still sign in with cached credentials).
• Cons: Requires trust in Microsoft's hashing; not suitable if compliance mandates passwords never leave the office.
• Use when: You want simplicity, resilience, and cloud-first migration; you have reliable Entra Connect health monitoring.
• Infrastructure: One Entra Connect server (or two in staging for HA), no extra agents required.

[!TIP] Always enable Entra Connect Health monitoring alongside PHS — it surfaces sync failures, hash-mismatch events, and agent-health issues before users notice broken sign-ins.

Pass-Through Authentication (PTA)

• How it works: User enters password at cloud sign-in; Entra ID forwards the credential to an on-prem agent (running on a server or VM), which validates it against Active Directory. Password is never stored in the cloud.
• Pros: Passwords never sync or hash; passwords never stored in cloud; tight on-prem control (if you disable on-prem account, cloud access stops immediately); works with Seamless SSO.
• Cons: Extra on-prem infrastructure (agents); latency (on-prem call per sign-in); if agents fail, sign-in fails (need HA).
• Use when: Compliance requires passwords to never leave on-premises; you have reliable on-prem network connectivity and agent infrastructure.
• Infrastructure: 2–3 PTA agents on-prem (HA), each running the PTA agent service; ensure redundancy.

[!WARNING] If all PTA agents go offline simultaneously, users cannot sign in — there is no cached-credential fallback as with PHS. Deploy agents in at least 2 separate data centres or availability zones.

Federation (AD FS / Custom STS)

• How it works: User is redirected to an on-prem identity provider (AD FS, Okta, Ping Identity, etc.). The provider authenticates the user and issues a SAML 2.0 token; the user's browser posts the token to Entra ID, which trusts it and issues a cloud token.
• Pros: Full control over authentication (custom MFA, device checks, hardware tokens); integrates with third-party identity solutions; existing AD FS investment.
• Cons: Highest complexity; requires PKI, token signing certs, and federation metadata; single point of failure if on-prem STS is down; latency (user is redirected on-prem).
• Use when: You need custom authentication logic; you have an existing AD FS or third-party STS; you require on-prem MFA device integration.
• Infrastructure: AD FS farm (2+ servers for HA), WAP (Web Application Proxy) for external access, certificate management.

Decision Matrix

2. Seamless SSO and Group Synchronization

Seamless SSO

Enables silent, password-less sign-in when the user is on a domain-joined computer and within the corporate network.

• How: Browser sends an HTTP request with Kerberos ticket (created via Windows NTLM) to a special Azure endpoint. No password prompt.
• Works with: PHS and PTA (not Federation; Federation already handles on-prem auth).
• Setup: Entra Connect wizard, relies on the AZUREADSSOACC computer account in on-prem AD.
• Deployment: Requires group policy or registry to set Azure endpoints as trusted sites in Internet Explorer / Edge.
• Benefit: Reduces password fatigue; users expect seamless experience on corporate networks.

Group Synchronization

• Default: On-prem security groups and distribution groups sync to Entra ID (read-only unless writeback enabled).
• Scoping: Use Entra Connect filtering to sync only certain OUs, groups, or user cohorts (e.g., sales only, not finance). Reduces Entra ID object count and blast radius if sync misconfigures.
• Writeback: Cloud-created security groups can be synced back to on-prem AD (Enterprise P1 license required). Useful for role-based groups created in the cloud that need on-prem permissions.

[!NOTE] Dynamic membership groups created in Entra ID do not support writeback to on-premises AD. If your access model relies on dynamic groups, keep those assignments cloud-only and use static security groups for any on-prem permission grants.

• Group types: Mail-enabled security groups, distribution groups. Dynamic groups in the cloud do not sync back.
• Use case: Grant on-prem file share access based on cloud role membership, or cloud-based conditional access policies based on on-prem group membership.

3. B2B vs. B2C Identities

B2B (Business-to-Business) — Guest Users in Your Tenant

• Scenario: Partner company employees, external consultants, vendors need access to your Azure resources, Microsoft 365, or apps.
• Mechanism: Invite them as "Guest" users into your Entra ID. They authenticate to their home organization; you trust their home org's authentication.
• Identity: Guest user has a UPN like partner@partner.onmicrosoft.com#EXT#@yourtenant.onmicrosoft.onmicrosoft.com; their directory lives in their home tenant.
• Licensing: Guest users don't consume your Entra ID licenses; they consume licenses in their home org. You pay only if they access resources you own (Microsoft 365, Azure apps).
• Conditional access: You can enforce conditional access policies on guests (require MFA, device compliance).
• B2B Cross-Tenant Access: Advanced feature — configure mutual trust with partner tenants to simplify guest invitation and resource sharing.

• Use case: Allowing partners to collaborate on a project SharePoint site, granting a contractor access to a Web App, or giving vendors read access to a Power BI dashboard.

B2C (Business-to-Customer) — Customer Identity

• Scenario: Your app serves external customers. You need a way for customers to sign up, sign in, reset passwords, and authenticate without having them as internal users.
• Tenant: Separate Entra ID B2C tenant (different domain, different management).
• User journeys: Customizable flows—sign-up, sign-in, password reset, profile edit. You control UI, validation, and post-auth redirects.
• Identity providers: Customers can authenticate via their own credentials (email/password), or via external providers (Google, Facebook, Twitter, SAML, OpenID Connect).
• Custom policies: SAML and OpenID Connect support. Build complex auth flows (e.g., "sign in with LinkedIn, then MFA, then consent screen").

[!IMPORTANT] A B2C tenant is a separate Entra ID tenant — it does not share users, groups, or policies with your primary (workforce) tenant. Treat it as an independent boundary for licensing, compliance, and data residency.

• Licensing: B2C billing is per-authentication (monthly active users). Significantly cheaper than internal licensing for large customer bases.
• Use case: E-commerce site with millions of customers, SaaS platform with free tier sign-ups, mobile app with social login.

B2B vs. B2C Comparison Table

4. Managed Identities: System-Assigned vs. User-Assigned

Why Managed Identities?

When an Azure resource (VM, App Service, Function, etc.) needs to authenticate to another resource (Key Vault, storage account, SQL database), it needs credentials. Managed identities provide credentials automatically without you managing secrets.

System-Assigned Managed Identity

• Lifecycle: Created when the resource is created; deleted when the resource is deleted. 1:1 relationship.
• Identity: A service principal in Entra ID with the same name/ID as the resource.
• Scope: Can be accessed only by that one resource.
• Use when: Resource accesses a single backend (e.g., App Service → Key Vault). Tight coupling is acceptable.
• Cons: If you scale the resource (e.g., multiple App Service instances), they all share the same identity (no fine-grain audit trail per instance).

User-Assigned Managed Identity

• Lifecycle: Created separately, can be assigned to multiple resources. Many-to-one relationship.

• Identity: A standalone Entra ID service principal; you control its lifecycle.
• Scope: Can be shared across resources in the same or different resource groups/subscriptions.
• Use when: Multiple resources share the same backend identity, or you want to reuse an identity across deployments (Terraform, ARM templates).
• Pros: Better for Infrastructure-as-Code (lifecycle matches app tier, not individual resource). Easier to rotate (one change, all consumers updated).

System-Assigned vs. User-Assigned Decision

When NOT to Use Managed Identities

• Legacy app requires hardcoded connection strings or keys (use Key Vault reference or app settings instead).
• Cross-tenant authentication (managed identity works within one tenant; use service principal with certificate).
• Third-party service without Entra ID support (store secret in Key Vault, reference in app).

Worked Examples

Example 1: Easy — Single-Site Hybrid Sync

Scenario

A mid-size bank (500 users) has on-premises Active Directory and is piloting Azure cloud services. Users should sign into Azure apps with their current on-prem password. There are no special compliance mandates about password location. You need high availability and minimal on-prem infrastructure changes.

Solution

1. Deploy Entra Connect on a server (or VM) in the on-prem data center, with a staging replica for HA.
2. Choose PHS: Users sync to the cloud with password hashes. Setup is fast, and if on-prem AD goes down temporarily, users can still access cloud apps (cached login). Cost is minimal.
3. Enable Seamless SSO for domain-joined workstations: users on corporate network won't be prompted for password when accessing cloud apps.
4. Sync on-prem groups to govern access: Finance group in on-prem AD → Finance group in Entra ID → assign Azure RBAC roles or app access.
5. Monitor: Set up Entra Connect Health monitoring; alert on sync failures.

Example 2: Medium — Partner Collaboration with B2B

Scenario

A software vendor partners with an outsourced QA firm (20 employees) who need access to your Azure DevOps project, a shared SharePoint site, and a test environment. Grant access without creating internal accounts; restrict to test only.

Solution

1. Invite B2B guests: Use "Invite external user" in Entra ID. Guests authenticate to their home org (the QA firm's Entra ID or Microsoft account).
2. Azure RBAC assignment: Assign the QA team a custom role (Contributor on test RG, Reader on DevOps) at the test resource group scope.
3. Conditional access: Require MFA for guests accessing your environment (corporate policy). Guest must authenticate to their home org first; then Azure validates the token.
4. Application integration: If you have a custom web app, add the guest's home org tenant as an external identity provider (federated); they can sign in with their corporate credentials.
5. Monitor guest activity: Use Entra ID sign-in logs to audit guest access; revoke access by deleting the guest user (no cleanup in their home org).

Example 3: Hard — Multi-Tenant SaaS with Managed Identities and B2C

Scenario

You are building a SaaS analytics platform. Customers (enterprises) want to sign their end-users (employees) into your app using their own Entra ID (i.e., your app is a multi-tenant app in their Entra IDs). You also have a B2C tier for small business customers who sign up directly. Your backend consists of a Node.js App Service that calls a SQL database and reads/writes to a storage account. You need least-privilege access and audit trails per customer.

Solution

1. Multi-tenant app registration: Register your app in your tenant with "Accounts in any Entra ID tenant" (multi-tenant). Customers add your app to their Entra ID; their users sign in via Entra ID.
2. B2C for self-serve customers: Create a separate B2C tenant for direct sign-ups (email/password, Google login). B2C users are redirected to your multi-tenant app after signing in.
3. User-assigned managed identity for the App Service: Create one identity scoped to serve the app tier. It has:
   • db_datareader, db_datawriter roles in SQL Database.
   • Storage Blob Data Contributor on the storage account.
   • Key Vault Secrets User on the key vault (to fetch database connection string, API keys).
4. Token refresh logic: App Service code fetches a managed identity token at startup and caches it (with 1-minute refresh buffer). Call Key Vault and SQL via token.
5. Per-customer data isolation: App code filters data by customer_id (from the signed-in user's token claim). SQL row-level security (RLS) enforces this at the database layer.
6. Audit: Enable SQL audit and storage account logging. Managed identity sign-in attempts appear in Entra ID logs (track which tenant's users hit your app).

Visual Explanations

Diagram 1: Sync Methods at a Glance

Diagram 2: B2B Guest Collaboration Flow

Diagram 3: Managed Identity Lifecycle

Diagram 4: Group Sync with Writeback

Comparison Table: Identity Management Patterns

Example TikZ Figure: Seamless SSO Handshake

Managed Identity Costs and Coverage

Common Mistakes

❌ Myth: "We chose PTA, so passwords are more secure than PHS." ✅ Reality: PTA validates passwords on-prem, but the password transmission from client to cloud is over HTTPS — equally secure for both PHS and PTA. The real benefit of PTA is policy control: if you disable a user on-prem, cloud access stops immediately. Choose PTA for enforcement latency, not transport security. Why it's tricky: The name "Pass-Through" implies the password travels somewhere unsafe, but HTTPS protects the wire in both models.

❌ Myth: "Seamless SSO requires Federation (AD FS)." ✅ Reality: Seamless SSO works with PHS and PTA only — it does not work with Federation, because Federation already handles on-prem authentication via SAML token redirect. If you want silent Kerberos-based sign-in for domain-joined users, pair PHS or PTA with Seamless SSO. Why it's tricky: Federation also provides "single sign-on," but through a completely different mechanism (SAML redirect, not Kerberos ticket). The exam uses both terms and expects you to distinguish them.

❌ Myth: "We should sync all on-prem groups to the cloud; Entra ID will auto-manage them." ✅ Reality: Over-syncing groups clutters Entra ID and creates orphaned permissions. Use scoping filters in Entra Connect to sync only groups relevant to cloud workloads (e.g., functional teams, not legacy distribution lists). Entra ID does not auto-delete or auto-disable stale synced groups — you must audit and prune regularly. Why it's tricky: The default Entra Connect configuration syncs all groups, which feels like the safe choice. In practice it creates noise that makes RBAC auditing harder.

❌ Myth: "B2B guests can just use a personal Microsoft account — it works fine." ✅ Reality: B2B guests can authenticate with personal MSAs, but you cannot enforce conditional access policies (MFA, device compliance) on personal accounts. Best practice: require guests to authenticate to their organizational Entra ID. For freelancers without one, invite as personal MSA but layer stricter conditional access (always require MFA, restrict to managed devices). Why it's tricky: The invitation flow accepts any email, and personal MSAs "just work" — the security gap only surfaces when you try to enforce compliance policies.

❌ Myth: "System-assigned managed identity is always simpler — just use it everywhere." ✅ Reality: System-assigned is simpler per resource, but at scale (10 App Services each needing Key Vault access = 10 separate RBAC role assignments). User-assigned lets you manage one identity for all 10, with a single set of permissions. For Infrastructure-as-Code and production workloads, user-assigned is often the better choice. Why it's tricky: Tutorials and quickstarts default to system-assigned because it is one toggle in the portal. The operational cost only becomes visible when you manage dozens of resources.

❌ Myth: "Our company uses B2B for partners, so we don't need B2C." ✅ Reality: B2B is for partner/vendor collaboration (business-to-business); B2C is for customer-facing apps (business-to-customer). A company often needs both: B2B for vendor portal access, B2C for customer app logins. Conflating them leads to poor licensing (customers consuming workforce Entra ID seats) and poor UX (customers seeing internal org branding). Why it's tricky: Both involve "external users," and the Azure portal surfaces them in similar-looking blades — but their tenants, licensing, and policy models are completely different.

Practice Exercises

Exercise 1: Sync Method Decision 🟢 Easy

Scenario: A healthcare provider has $5,000 users in on-prem AD. Compliance (HIPAA) mandates that passwords never leave the organization's network. The organization has reliable fiber connectivity and a 99.9% uptime SLA on-prem. Cloud apps should be available even if on-prem AD is temporarily down. Which sync method do you recommend, and why?

▶💡 Hint

Which sync methods keep passwords entirely on-premises? Consider the compliance requirement first, then availability.

▶✅ Solution

PTA + Seamless SSO. HIPAA rules out PHS (password hashes are sent to the cloud, even though hashed). Federation is overly complex here (no custom auth logic mentioned). PTA validates passwords on-prem and pairs with Seamless SSO for silent sign-in on domain-joined workstations. Deploy 2–3 PTA agents across separate sites for HA — if one AD server is down, users authenticate via another agent.

Exercise 2: B2B Guest Conditional Access 🟡 Medium

Scenario: Your company (Acme Corp) invites a guest user from PartnerCorp. The guest should access Acme's Azure SQL Database via Azure Data Studio, but only from Acme's corporate network or from a company-issued laptop with Intune compliance. What conditional access policy would you create?

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Create a conditional access policy with the following conditions:

• Users: Guest user (or "External users" if templated).
• Apps: Target the SQL Database or the Azure portal (depending on access method).
• Conditions:
  • Location: Allow only known corporate IP ranges or trusted locations.
  • Device: Require device compliance (Intune enrollment, or trusted device from partner org).
  • Sign-in risk: Low (do not allow risky sign-ins).
• Grant: Require MFA and compliant device.
• Session: Apply app-enforced restrictions (IP pinning, session timeout).

Why this works: Guests authenticate to their home org (PartnerCorp); Entra ID in Acme's tenant trusts that auth and layers on additional checks (MFA, device compliance, location). If the guest's device is not managed or they sign in from an unexpected location, access is blocked.

Exercise 3: Managed Identity for Multi-Database App 🟡 Medium

Scenario: You have an App Service that reads from a SQL Database (read-only query), writes to another SQL Database (operational data), and uploads files to a storage account. You want to minimize secrets in your app config. Should you use one system-assigned identity or create a user-assigned identity? Explain your choice.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Create a user-assigned managed identity (not system-assigned).

Rationale:

• A single user-assigned identity can be assigned to the App Service and given granular RBAC roles: db_datareader on DB1, db_datawriter on DB2, Storage Blob Data Contributor on the storage account.
• If you scale the App Service (add multiple instances), all instances share the same identity, making audit trails cleaner (one identity per app tier, not per instance).
• User-assigned identity is portable: if you redeploy the app (IaC/Terraform), the identity persists independently, so you don't lose permissions.
• Although system-assigned would also work functionally, user-assigned is operationally superior for multi-resource scenarios and Infrastructure-as-Code patterns.

Exercise 4: B2C Custom Policy Flow 🟡 Medium

Scenario: Your B2C tenant serves two types of customers: "Premium" (must authenticate via corporate SAML) and "Free" (can sign up with email/password). Design a user journey that branches on sign-up based on customer tier.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Create a B2C custom policy with the following elements:

1. Sign-up form: Collect email, password, and a "Tier" selection (radio: Premium/Free).
2. Conditional orchestration:
   • If Tier = "Premium": Redirect to SAML federated identity provider (customer's corporate SAML).
   • If Tier = "Free": Proceed with email/password validation and account creation.
3. Token claim: Add a tier claim to the final token, so your app can enforce tier-based permissions.
4. Redemption: Issue an ID token with the tier claim to your app; app uses it to apply tier-specific UI (e.g., premium features disabled for free tier).

Exercise 5: PHS to PTA Migration 🔴 Hard

Scenario: Your company used PHS for $2,000 users. A new compliance requirement mandates password hashes never leave on-prem. You must migrate to PTA without downtime. Outline the steps.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Deploy 2–3 PTA agents on separate on-prem servers; set up a staging Entra Connect instance. Enable PTA in the Entra Connect wizard while keeping PHS temporarily active. Pilot with 50 test users, then roll out department-by-department over 1–2 weeks. Monitor sign-in failures in Entra ID logs. Once all users are on PTA, disable PHS to remove password hashes from the cloud. Keep PHS as a documented rollback plan.

Exercise 6: Choosing System-Assigned vs. User-Assigned at Scale 🟡 Medium

Scenario: You manage a microservices platform with 20 stateless services deployed on AKS, App Services, and Functions. Each service accesses a central SQL Database, a shared Key Vault, and a logging storage account. You're using Terraform to manage all infra. Would you use system-assigned or user-assigned managed identities, and why?

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Use user-assigned managed identities, one per service tier (not per instance/pod).

Rationale:

• Scale: With 20 services, system-assigned would create 20 separate identities, each with its own RBAC bindings. User-assigned lets you group them logically: one identity per service tier (web, api, worker), reducing management overhead.
• IaC lifecycle: Terraform manages the app deployment; if you redeploy a service, a new system-assigned identity is created, losing RBAC permissions. User-assigned identity persists across redeployments (you define it as a separate Terraform resource).
• Audit trails: One identity per service tier is cleaner in audit logs; you see "api-service-identity accessed Key Vault" rather than "app-service-instance-12 accessed Key Vault."
• Migration: If you later move a service from App Service to AKS, the identity is reusable (just re-assign it to the new workload).

Exercise 7: Disaster Recovery Scenario 🔴 Hard

Scenario: A company uses PTA for sign-in. During a data-center outage, all on-prem PTA agents become unreachable for 2 hours. Users cannot sign into Azure apps. What could have mitigated this, and what actions do you take during/after?

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer:

Mitigation: Deploy PTA agents across 2+ data centres/availability zones, co-located with AD replicas. Enable PHS as a warm standby — if all agents fail, cached hashes provide sign-in continuity. During outage: Monitor Entra ID sign-in logs; alert on-prem IT; consider temporary PHS enablement. After: Verify agent health via Entra Connect Health; review locked-out accounts; implement PTA agent availability alerts.

Exercise 8: B2B + B2C Architecture 🔴 Hard

Scenario: Your organization runs both a B2B SaaS product (partners collaborate on projects) and a B2C product (customers subscribe and use features). Describe how you would architecture identities for this scenario to keep B2B and B2C separate and secure.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer:

Tenant A (Production): Internal users via Entra Connect (PHS + Seamless SSO); B2B guests from partner orgs. Tenant B (B2C): Separate B2C tenant for customer sign-ups (email/password, social IdPs). Backend: Single API deployment accepts tokens from both tenants; shared database uses row-level security (RLS) filtered by tenant_id. RBAC: Tenant A uses Azure RBAC for partners; Tenant B uses app-level tier logic for customers. Why separate: Isolation prevents cross-tier access, simplifies compliance (B2C may have different data residency), and avoids customers consuming workforce Entra ID licenses.

Summary & Concept Map

Key Takeaways

1. Sync method choice (PHS, PTA, Federation) depends on latency tolerance, on-prem infrastructure capacity, and compliance policy. PHS is simplest; PTA is most secure; Federation is most flexible but complex.

2. Seamless SSO layers atop PHS or PTA to give domain-joined users silent sign-in (no password prompt). Requires Kerberos delegation and special setup (AZUREADSSOACC account).

3. Group synchronization bridges on-prem and cloud: on-prem groups sync to cloud (read-only by default); cloud-created groups sync back with writeback (Enterprise license required). Use scoping to avoid sync bloat.

4. B2B is for partner/vendor collaboration (guests in your tenant, home org identity). B2C is for customers (separate tenant, customer-managed identity). Both serve different use cases and licensing models.

5. System-assigned managed identities are 1:1 with a resource; user-assigned are reusable. User-assigned is better for scale and IaC; system-assigned is simpler per-resource. Choose based on lifecycle alignment.

6. Avoid managed identities if your resource doesn't support them (use service principals instead) or if you need cross-tenant auth (use certificates, not tokens).

Concept Map