Designing Identity Management
Managed identities, hybrid identity architecture, and Entra ID editions — design an identity management strategy that scales from 50 users to 50,000.
Why identity management design matters
If authentication is the front door, identity management is the building directory. It answers: Who works here? What’s their role? How do services talk to each other without sharing keys?
Three design areas: Human identity (users, groups, lifecycle), workload identity (how apps and services authenticate without passwords), and hybrid identity (keeping on-prem AD and cloud Entra ID in sync).
Managed identities: the credential-free future
Managed identities let Azure resources authenticate to other Azure services without storing credentials in code, config files, or Key Vault.
| Factor | System-Assigned | User-Assigned |
|---|---|---|
| Lifecycle | Tied to the resource — created and deleted with it | Independent — you create, assign, and delete separately |
| Sharing | One identity per resource — cannot share | One identity can be assigned to multiple resources |
| Use case | Single resource needs access to one service | Multiple resources need the same permissions |
| RBAC management | Role assignment per resource | Role assignment once, applies to all assigned resources |
| Example | A VM that reads from Key Vault | 10 VMs in a scale set that all access the same Storage account |
| Cleanup | Automatic when resource is deleted | Manual — must delete identity separately |
🚀 Marcus’s pattern: NovaSaaS’s microservices use user-assigned managed identities grouped by functional boundary:
mi-api-backend— assigned to all API containers, has access to Cosmos DB and Storagemi-worker-batch— assigned to batch processing Functions, has access to Queue Storage and SQLmi-monitoring— assigned to monitoring services, has read access to Log Analytics
Design decision: Managed identity vs service principal vs Key Vault secrets
Priority order for workload authentication:
- Managed identity — best option when the workload runs ON Azure. Zero credential management.
- Workload identity federation — for workloads outside Azure (GitHub Actions, Kubernetes) that can present a token. No secrets stored.
- Service principal with certificate — when federation isn’t possible. Certificate is better than secret.
- Service principal with secret — last resort. Secrets expire and must be rotated.
- Connection strings / passwords — avoid. If you must, store in Key Vault with short expiry.
Exam pattern: If the scenario says the workload is an Azure service (VM, App Service, Function), managed identity is almost always correct.
Entra Connect Sync: hybrid identity architecture
Synchronisation topology
Entra Connect Sync (formerly Azure AD Connect) synchronises identities from on-premises AD to Entra ID.
| Topology | Description | When to Use |
|---|---|---|
| Single forest, single tenant | One AD forest syncs to one Entra tenant | Most common — single organisation |
| Multiple forests, single tenant | Multiple AD forests sync to one Entra tenant | Post-merger, multi-division organisations |
| Single forest, multiple tenants | One AD forest syncs to multiple Entra tenants | Dev/test isolation (rare, complex) |
| Staging server | Passive Entra Connect server ready for failover | All production deployments (HA) |
🏗️ Priya’s challenge: After GlobalTech acquired a smaller company, they have two AD forests. Priya designed multiple forests → single tenant with one Entra Connect Sync server reaching both forests (using multi-forest connector configuration), matching accounts by email address (mail attribute). A staging server provides failover.
Entra Connect Cloud Sync vs Entra Connect Sync
| Factor | Entra Connect Sync | Entra Connect Cloud Sync |
|---|---|---|
| Architecture | Heavy agent on-prem (Windows Server) | Lightweight agent (provisioning agent) |
| Multi-forest | Yes — full support | Yes — simpler config |
| Password writeback | Yes | Yes |
| Group writeback | Yes | Limited |
| Device writeback | Yes | No |
| Exchange hybrid | Full support | Limited |
| HA model | Staging server (manual failover) | Multiple agents (automatic) |
| Best for | Complex hybrid with Exchange, device sync | Simpler sync needs, multi-forest, easier HA |
Exam tip: Cloud Sync is newer and simpler, but not always the answer
Cloud Sync is Microsoft’s newer, lighter synchronisation tool with automatic HA. However, it doesn’t support all scenarios — device writeback and complex Exchange hybrid still require the traditional Entra Connect Sync. If the exam scenario mentions Exchange hybrid or device sync, choose Entra Connect Sync.
Entra Domain Services: LDAP and Kerberos in the cloud
Some legacy applications need LDAP, NTLM, or Kerberos — protocols that Entra ID doesn’t speak. Entra Domain Services (Entra DS) provides managed domain controllers in Azure.
| Scenario | Solution |
|---|---|
| Cloud app uses OAuth/OIDC/SAML | Entra ID — native cloud identity |
| Legacy app needs LDAP bind or Kerberos auth | Entra Domain Services — managed DCs |
| App needs full AD control (custom schema, trusts) | Self-managed DCs in Azure VMs |
🏦 Elena’s scenario: FinSecure Bank has a legacy risk calculation engine that authenticates via LDAP. Migrating to modern auth would take 18 months. Elena deployed Entra Domain Services as a bridge — the app gets LDAP/Kerberos, and identities sync from Entra ID (which syncs from on-prem AD). No domain controllers to manage.
Entra ID editions and licensing
| Feature | Free | P1 | P2 |
|---|---|---|---|
| Basic SSO and MFA | Yes (security defaults) | Yes | Yes |
| Conditional Access | No | Yes | Yes |
| Dynamic groups | No | Yes | Yes |
| Self-service password reset | Cloud users only | Full (with writeback) | Full (with writeback) |
| Application Proxy (on-prem apps) | No | Yes | Yes |
| Identity Protection (risk-based CA) | No | No | Yes |
| PIM (just-in-time admin) | No | No | Yes |
| Access Reviews | No | No | Yes |
| Entitlement Management | No | No | Yes |
| Best for | Small orgs, basic cloud identity | Most enterprises — CA + dynamic groups | Regulated industries — full governance |
Design impact: Your Entra ID edition choice constrains your entire identity architecture. If you design Conditional Access into your solution, you need P1. If you design PIM or access reviews, you need P2. Always map features to licensing early.
Knowledge check
🚀 NovaSaaS deploys 30 microservices on Azure Container Apps. All services need to read from the same Cosmos DB account and write to the same Storage account. Which identity approach should Marcus recommend?
🏗️ GlobalTech has a legacy HR application that authenticates users via LDAP. The app will take 12 months to modernise. In the meantime, it needs to run in Azure and authenticate against the corporate directory. What should Priya recommend?
🎬 Video coming soon
Next up: Identities are managed — now let’s control what they can do — Authorizing Access to Resources.