Identity · Directories
Microsoft Entra ID
Microsoft's cloud identity and access management service, the identity control plane for Microsoft 365, Azure and thousands of federated applications.
IntermediateMicrosoftUpdated 2026-09-01
Overview
Entra ID (formerly Azure AD) is a multi tenant cloud directory and identity provider. It authenticates users, workload identities and devices, issues tokens for applications, and enforces access policy through Conditional Access.
It is not a cloud hosted Active Directory. There are no organisational units, no Group Policy and no Kerberos in the same sense; the model is tenant, users, groups, service principals, application registrations and policy. Understanding that difference prevents most hybrid design mistakes.
How it works
- 01Applications trust Entra ID as an identity provider. Users authenticate once, and applications receive signed ID and access tokens containing claims about the user, device and session.
- 02Hybrid environments synchronise identities from Active Directory using Entra Connect or Cloud Sync, choosing password hash synchronisation, pass through authentication or federation for the authentication method.
- 03Devices register or join the tenant, which allows device state, compliant, hybrid joined, managed, to become a factor in access decisions.
- 04Conditional Access evaluates signals (user, group, application, device, location, risk) and grants, blocks or requires additional controls.
Why it matters
- In a cloud first estate, identity is the perimeter. Nearly every SaaS access decision runs through the identity provider.
- Token based access means stolen tokens and consented applications can bypass password controls entirely, so monitoring sign ins and app consent is essential.
- Licensing tiers gate important controls such as risk based Conditional Access, Privileged Identity Management and access reviews.
Sequence
- 1User requests application
- 2Redirect to Entra ID
- 3Primary authentication
- 4Conditional Access evaluation
- 5MFA or device compliance if required
- 6Token issued with claims
- 7Application authorises based on claims
Where it is used
- Single sign on to Microsoft 365 and third party SaaS with SAML or OIDC.
- Guest collaboration through B2B external identities, and customer identity through External ID.
- Workload identity for automation using service principals and managed identities.
- Just in time privileged role activation with Privileged Identity Management.
Security considerations
- Require phishing resistant MFA for administrators and, progressively, for all users.
- Block legacy authentication protocols that cannot enforce MFA.
- Restrict user consent to applications and review existing OAuth grants for over privileged or malicious apps.
- Use PIM for eligible not permanent role assignment, with approval and justification.
- Monitor risky sign ins, impossible travel, token replay indicators and changes to Conditional Access policy itself.
Common misconfigurations
- Break glass accounts either missing or excluded from monitoring rather than only from policy.
- Conditional Access policies in report only mode indefinitely.
- Permanent Global Administrator assignments held by many people and by service accounts.
- Guest users granted the same default permissions as members.
- Synchronising highly privileged on premises accounts into the cloud, merging Tier 0 boundaries.
