Browse learn

How Microsoft Entra ID Works

Learn how Microsoft Entra ID tenants, identity objects, tokens, applications, and policy services work together during cloud authentication.

On this page

What is Microsoft Entra ID?

Microsoft Entra ID is the cloud-first identity and access management (IAM) service at the core of Microsoft’s modern identity platform. It evolved from Azure Active Directory (Azure AD), combining the operational continuity and global scale of a managed directory with advanced cloud-driven security and integration capabilities. Entra ID orchestrates secure authentication, single sign-on, policy enforcement, and governance for users, applications, and devices, serving both Microsoft and third-party environments.

Despite the new name, Entra ID is a direct functional successor to Azure AD—no core features or integration APIs have changed with the rebranding. For organizations familiar with on-premises Active Directory (AD), it’s crucial to understand that Entra ID is not “Active Directory in the cloud.” Entra ID was architected specifically for web, SaaS, and hybrid workloads, using fundamentally different identity models, protocols, and management paradigms.

Architecture Overview: How Entra ID Manages Identity

Entra ID organizes identity in a cloud-native directory model. At its foundation is a tenant: a dedicated, globally distributed directory instance. Within a tenant, core constructs include users (human or service accounts), groups (collections of users/devices for scalable management), devices (registered endpoints), and application objects (representing integrated apps).

Privileges in Entra ID are expressed through assignments of roles and group memberships. Entitlements, such as access rights or licenses, can be delegated and automated at scale. Unlike classic AD, objects in Entra ID are globally addressable and managed as cloud resources—there is no concept of forests, domains, or organizational units.

Key architectural principles:

  • Cloud-first management: Admins interact using web portals, REST APIs, and automation.
  • Flat and global hierarchy: No on-premises domain controllers, multi-site replications, or legacy trust relationships.
  • Multi-protocol endpoints: Natively supports web-centric authentication and API authorizations, while legacy protocols require separate managed services.

Authentication and Access: Protocols and Security Controls

Entra ID enables authentication through modern, standards-based protocols and advanced security controls to meet diverse application, user, and security requirements.

Supported Authentication Protocols

  • OpenID Connect (OIDC)/OAuth 2.0: Used broadly for modern web, mobile, and API authentication.
  • SAML 2.0: Widely used for federation and legacy SSO scenarios.
  • LDAP/Kerberos/NTLM: Not natively supported by Entra ID, but available via Microsoft Entra Domain Services for legacy compatibility.

This protocol support enables app integrations ranging from SaaS SSO to custom-built apps. Protocol selection impacts integration complexity, lifecycle management, and extensibility.

Multi-factor and Passwordless Authentication

Entra ID supports multiple sign-in methods:

  • Passwords — Standard but less secure; increasingly discouraged.
  • Multi-factor Authentication (MFA): Requires a second verification factor (e.g., phone call, SMS, app notification, hardware key).
  • Passwordless Authentication: FIDO2 security keys (passkeys), Windows Hello for Business, or Microsoft Authenticator app. These are considered phishing-resistant, particularly for administrator or sensitive roles.

Admins can enforce authentication method requirements based on risk or sensitivity through policy.

Conditional Access Policies

Conditional Access is a central security feature. Policies dynamically assess the context (user, device, application, sign-in risk, location) of authentication attempts. Based on this evaluation, Entra ID can:

  • Require additional factors (MFA)
  • Block or allow access
  • Trigger adaptive responses (e.g., prompt passwordless)
  • Enforce compliance (e.g., device health)

Conditional Access extends precision and automation to access decisions, supporting zero trust principles and frequently serving as the enforcement point for compliance and risk-mitigation controls.

Hybrid Identity and Integration: Supporting LDAP and Legacy Scenarios

Many enterprise architectures require a bridge between on-premises and cloud identity. Entra ID offers integration with existing Active Directory forests via Microsoft Entra Connect. This synchronization tool ensures users, groups, and password hashes or authentication signals flow securely to the cloud. As a result, organizations can deliver a unified identity across on-premises and cloud resources.

However, Entra ID itself does not expose LDAP or Kerberos endpoints. For workloads that require these legacy protocols—such as applications designed to talk to classic AD via LDAP—Microsoft offers Entra Domain Services (EDDS). This managed service creates a cloud-hosted, domain-joined environment synchronized with Entra ID, exposing traditional LDAP, Kerberos, and NTLM support without requiring organizations to run their own domain controllers.

Key points for integration:

  • Use Entra ID for modern, web-oriented authentication and SSO.
  • Use Entra Connect for hybrid directory synchronization and password management.
  • Use Entra Domain Services only for applications that have hard dependencies on legacy protocols.

Roles, RBAC, and Governance

Entra ID implements comprehensive role-based access control (RBAC) and governance mechanisms:

  • Built-in roles: Over 60 pre-defined roles (e.g., Global Administrator, User Administrator, Application Administrator) allow fine-grained delegation.
  • Custom roles: Organizations can define granular permissions for unique operational needs.
  • Privileged Identity Management (PIM): Enables just-in-time (JIT) access elevation for high-risk or sensitive roles, requiring approval or additional authentication before assigning elevated privileges. PIM reduces standing access and supports audit/compliance requirements.
  • Group-based management: Roles and access can be assigned through group membership, simplifying lifecycle control.

This model provides both operational agility and security, especially necessary for distributed organizations and regulated environments.

Common Misconceptions and Pitfalls

“Entra ID is just ‘Active Directory in the cloud’”

Entra ID is fundamentally different from traditional Active Directory. It lacks many Windows-centric features (e.g., GPOs, domain join, native LDAP)—it is purpose-built for cloud, web, and modern app integration.

“You can use LDAP natively with Entra ID”

Direct LDAP access to Entra ID is not supported. LDAP authentication is available only through Microsoft Entra Domain Services, which synchronizes relevant directory data from Entra ID but is a separate managed directory.

“The Azure AD to Entra ID rebrand broke integrations or APIs”

The rebranding from Azure AD to Entra ID effected no changes to APIs, endpoints, or functionality—existing integrations continue working. The update impacts naming, UI labels, and documentation, not technical capability.

Choosing and Integrating: Practical Considerations and Limitations

Entra ID is ideally suited for:

  • Cloud-centric organizations and those embracing zero trust security
  • Applications supporting modern protocols (OIDC, OAuth2, SAML)
  • Managing cloud resources, SaaS access, external user collaboration, and conditional security enforcement

However, it is not a full drop-in replacement for all on-prem AD features. Gaps and boundaries include:

  • Direct LDAP/Kerberos support: Requires Entra Domain Services, which introduces its own operational nuances.
  • Application compatibility: Legacy apps expecting AD DS protocols may need redevelopment or migration to use Entra ID natively.
  • Hybrid complexity: Robust hybrid scenarios require careful architecture, including synchronization and consideration for failover, account recovery, and policy overlap.

Thorough planning is required—especially around security policies (Conditional Access, MFA) to avoid accidental lockout and to enable smooth migration from legacy systems.

Sources