Azure AD (Entra ID)

What is Microsoft Entra ID?

Microsoft Entra ID — formerly Azure Active Directory (Azure AD) — is Microsoft’s cloud-based identity and access management platform. It’s the identity provider behind Microsoft 365 (Office, Teams, Outlook), Azure, and thousands of third-party SaaS applications, providing authentication, single sign-on (SSO), multi-factor authentication, and conditional access for organizations. For any company running on Microsoft’s ecosystem, Entra ID is the identity backbone — the system that stores users and groups, authenticates them, and federates that identity out to every connected app. The rename from Azure AD to Entra ID (2023) is worth knowing because both names are still everywhere in documentation and practice.

What it does — cloud identity for the enterprise

Entra ID plays the full identity provider role. It’s the directory (users, groups, devices, and their attributes) and the authentication authority that issues signed tokens (OIDC/OAuth for modern apps, SAML for enterprise SSO) so apps can trust it to vouch for users — the federated identity model with Microsoft as IdP. Its enterprise-grade capabilities are what distinguish it: Conditional Access (policies that grant or block access based on user, device, location, risk, and other signals — “require MFA from unmanaged devices,” “block sign-ins from unexpected countries” — the engine of Microsoft’s zero-trust story), MFA and increasingly passwordless/passkey authentication, Identity Protection (risk-based detection of compromised sign-ins), Privileged Identity Management (just-in-time elevation for admin roles), and provisioning (automatically creating/updating/deprovisioning accounts in connected apps). Note an important distinction Microsoft draws: Entra ID is not the same as on-premises Windows Active Directory — traditional AD is the on-prem domain directory (domain controllers, Kerberos, group policy) for internal networks, while Entra ID is a cloud identity service for web/SaaS/modern-app authentication; many organizations run both and synchronize them (via Entra Connect) so on-prem identities extend to the cloud. Conflating the two is a frequent source of confusion.

Where it fits — and the crown-jewels reality

Entra ID competes with Okta, Google Workspace, Auth0, and Ping as an enterprise IdP; the choice usually follows ecosystem gravity — organizations deep in Microsoft 365/Azure default to Entra ID because it’s included and tightly integrated, while others pick a vendor-neutral IdP for broader flexibility. Whatever the choice, the essential reality is the one that governs every identity provider: because it authenticates access to potentially everything, Entra ID is the highest-value target and a single point of both failure and compromise. If it’s breached, an attacker can reach every federated app (identity-based attacks — phishing, MFA-fatigue/push-bombing, token theft, consent-phishing of OAuth apps — increasingly target exactly this); if it’s down, users can’t log into Microsoft 365 or connected apps. This drives the non-negotiable protections: strong, phishing-resistant MFA on all accounts and especially admins (a compromised Global Administrator is catastrophic), tight admin-role scoping with just-in-time elevation (few standing Global Admins), Conditional Access policies enforcing device and risk requirements, monitoring of sign-in and audit logs, and disciplined deprovisioning (disabling a departing employee’s Entra account cuts off every connected app at once — the payoff of centralized identity). The recurring mistakes: weak MFA on the identity that unlocks everything, sprawling standing admin privileges, confusing Entra ID with on-prem AD when designing hybrid identity, and neglecting the OAuth-app consent surface (malicious third-party apps granted broad permissions are a modern Entra-specific attack vector).

What people get wrong

• Weak MFA and sprawling admin roles — Entra ID unlocks every connected app, so it needs phishing-resistant MFA and tightly-scoped, just-in-time admin access; a compromised Global Admin is catastrophic.
• Confusing it with on-prem Active Directory: Entra ID is cloud identity for modern/SaaS apps, not the on-prem domain directory — hybrid setups synchronize the two, and conflating them causes design errors.
• Ignoring the OAuth consent surface — over-permissioned or malicious third-party apps that users consent to are a real Entra-specific attack path; govern app registrations and admin consent.

Primary source: Microsoft Entra ID documentation