Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

2.1.2.1. Design for Microsoft Entra ID

2.1.2.1. Design for Microsoft Entra ID

💡 First Principle: A centralized, cloud-based identity and access management service provides a unified platform for securing access to applications and resources, simplifying identity lifecycle management, and enabling modern authentication protocols.

Scenario: You are designing the identity solution for an organization moving to a cloud-first model. They want a unified identity platform for employees to access all Azure and Microsoft 365 services. They currently have an on-premises Active Directory but want to simplify authentication by reducing reliance on on-premises infrastructure for sign-in.

Microsoft Entra ID is a comprehensive cloud-based identity and access management service that provides a central directory for users, groups, and applications.

Key Design Considerations:
  • Microsoft Entra tenants: Each organization receives a dedicated Microsoft Entra tenant—a distinct, isolated directory. Design decisions include whether to use a single tenant (simplifies management, centralizes policy) or multiple tenants (useful for mergers, regulatory boundaries, or multi-organization scenarios).
  • Users and Groups: Users represent individual identities. Groups (security or Microsoft 365) allow you to manage permissions collectively, streamlining access control to resources and applications.
  • Application Registrations: Applications must be registered in Microsoft Entra ID to enable authentication and authorization. Registration creates a service principal, allowing apps to sign in users, request tokens, and access APIs securely.
    • Supported account types decide who can sign in: single-tenant accepts only the home directory, multitenant accepts users from any Microsoft Entra organization, and each customer tenant gets its own service principal when it consents. A multitenant registration is how a SaaS vendor lets enterprise customers sign in with their own corporate identities, with no per-customer registration.
    • Permissions and consent: delegated permissions let the app act as the signed-in user; application permissions let it act as itself with no user, and always need admin consent. Admin consent grants a permission on behalf of every user in the tenant, so users are not prompted individually.
  • Managed identities: A Microsoft Entra identity for an Azure resource (App Service, Functions, a VM) with no credential to store: Azure issues its tokens and rotates the credential. System-assigned shares the resource's lifecycle; user-assigned is a standalone resource that several resources can share. Enabling one grants nothing on its own: each target service must authorize it, through an Azure RBAC role on that resource or, for a database engine such as Azure SQL Database, a database user mapped to the identity (CREATE USER ... FROM EXTERNAL PROVIDER) once Microsoft Entra authentication is enabled.
Authentication Methods:
  • Password Hash Synchronization (PHS): Syncs password hashes from on-premises AD to Microsoft Entra ID for seamless cloud sign-in. Simple to deploy, highly available.
  • Pass-through Authentication (PTA): Authenticates users directly against on-premises AD without storing passwords in the cloud. Requires on-premises agents.
  • Federation (AD FS): Uses Active Directory Federation Services (AD FS) to enable single sign-on (SSO) and advanced policies (e.g., smart card authentication). More complex setup.
  • Cloud-only Authentication: Identities exist solely in Microsoft Entra ID, with no on-premises dependency.

Entra ID is not AD DS in the cloud. It is a managed service with no domain controllers to run, a flat directory with no organizational units or Group Policy Objects, and it speaks modern protocols (OAuth 2.0, OpenID Connect, SAML) rather than Kerberos and LDAP. That is what gives it single sign-on to Microsoft 365 and thousands of SaaS applications, with MFA and Conditional Access built in. Applications that need Kerberos, LDAP or domain join belong on Microsoft Entra Domain Services (a managed domain) or AD DS.

Sign-in and audit logs are retained for 7 days (Free) or 30 days (P1/P2), and no Microsoft Entra ID tier keeps them longer than that. For longer retention, forensics or a SIEM, use Microsoft Entra diagnostic settings to route them to a Log Analytics workspace, a storage account or Event Hubs.

⚠️ Common Pitfall: Creating separate cloud-only user accounts for employees who already have on-premises Active Directory accounts. This leads to credential sprawl and a disjointed user experience. A hybrid identity approach is almost always preferred.

Key Trade-Offs:
  • Simplicity (PHS) vs. On-Premises Dependency (PTA/Federation): PHS is the simplest and most resilient hybrid method as authentication doesn't depend on on-premises connectivity. PTA and Federation provide real-time validation against on-prem AD but introduce a dependency on on-premises infrastructure.

Reflection Question: How does designing for Microsoft Entra ID, considering its various authentication methods and security features, fundamentally provide a unified identity platform for employees, external partners, and applications, enabling secure and efficient access to cloud resources?

See how it connects
Alvin Varughese
Written byAlvin Varughese
Founder•20 professional certifications