What Is Entra ID? Azure AD Renamed, Explained

In July 2023 Microsoft renamed Azure Active Directory to Microsoft Entra ID. The product did not change. The name did. Every tenant, every sign-in log, every Conditional Access policy that ran under "Azure AD" runs under "Entra ID" today, with the same APIs and the same license SKUs. The rename matters mostly because half the tooling, scripts, and threat reports a defender reads still say "Azure AD," and you need to know they mean the same control plane.

Entra ID is the identity service behind every Microsoft 365 and Azure tenant. It decides who a user is and what they can reach, for cloud apps the way a domain controller does for an on-premises Windows estate. If you administer Microsoft 365, you already run Entra ID whether you configured it or not: every tenant is an Entra tenant by default.

This guide covers what Entra ID is, how it differs from the on-premises Active Directory it is often confused with, the building blocks you actually configure, the attacks that target it, and the controls that blunt them. It is written for SOC analysts and responders who have to read Entra sign-in logs and tell a legitimate token from a stolen one.

What is Entra ID?

Microsoft Entra ID is a cloud-based identity and access management (IAM) service. It authenticates users, devices, and workloads, then enforces policy on what they can access across cloud applications and resources. It is the foundational product in the broader Microsoft Entra family, which also includes governance, verified credentials, and network access products.

The rename is the first thing to get straight. "Azure Active Directory," "Azure AD," and "AAD" are all the old name for the same service. Microsoft announced the change to Microsoft Entra ID on July 11, 2023, and rolled the naming through its consoles and documentation over the rest of that year. No features moved, no pricing changed, no licenses lapsed. A 2022 threat report describing an "Azure AD" attack describes an Entra ID attack.

What Entra ID does, in plain terms:

• Authentication. It verifies identities through passwords, multi-factor methods, passwordless options like FIDO2 keys and Windows Hello, and certificate-based auth.
• Authorization. It enforces who can reach which application and under what conditions, through Conditional Access and role assignments.
• Single sign-on (SSO). One authenticated session reaches thousands of integrated SaaS apps without re-entering credentials.
• Identity protection. It scores sign-in and user risk from signals like impossible travel, anonymized IPs, and leaked-credential matches, and can trigger remediation.
• Directory. It holds the objects (users, groups, devices, applications) that the rest of the tenant references.

Entra ID is licensed in tiers: a Free tier bundled with Microsoft 365 and Azure subscriptions, then Entra ID P1 and P2. Risk-based Identity Protection and Privileged Identity Management, the features a defender leans on most, require P2.

Entra ID vs. on-premises Active Directory

The shared word "Active Directory" causes more confusion than anything else about Entra ID. They are different products with different protocols, and treating one like the other is how misconfigurations happen.

On-premises Active Directory Domain Services (AD DS) is the directory most enterprises have run for decades. It authenticates with Kerberos and NTLM, queries over LDAP, and applies Group Policy to domain-joined Windows machines inside a trusted network. Entra ID was built for the cloud, where there is no trusted network perimeter. It authenticates with web protocols (SAML, OAuth 2.0, and OpenID Connect), has no concept of Group Policy or organizational units, and treats every request as untrusted until proven otherwise.

Most organizations run both and synchronize them. Microsoft Entra Connect (formerly Azure AD Connect) replicates on-prem identities up to Entra ID so a user has one identity across both worlds. That hybrid link is also an attack path: compromise the sync account or the on-prem AD, and the blast radius can extend into the cloud tenant. For legacy apps that still need Kerberos or LDAP in the cloud, Microsoft Entra Domain Services provides a managed domain, separate from Entra ID itself.

A point worth holding onto: the AD attacks you may know, Kerberoasting, DCSync, Pass-the-Hash, do not exist in Entra ID, because the protocols they abuse are not there. Entra ID has its own attack surface, built around tokens and OAuth, covered below.

Core building blocks of Entra ID

Five objects make up almost everything you configure or investigate in a tenant.

• Tenant. A dedicated, isolated instance of Entra ID for one organization, created with every Microsoft 365 or Azure subscription. It gets an initial domain like contoso.onmicrosoft.com, to which you add your real domains. Tenant boundaries are the strongest isolation in the service.
• Objects. Users, groups, devices, and service principals (the identities applications run as). These are what policies and roles apply to.
• Applications and service principals. Every app integrated with the tenant, internal or third-party SaaS, is registered and represented by a service principal. This is the object that holds an app's granted permissions, and it is central to the OAuth attacks below.
• Conditional Access. The policy engine that evaluates each sign-in against signals (user, device, location, risk) and decides allow, block, or require a step like multi-factor authentication. It is the heart of enforcement in Entra ID.
• Roles. Built-in and custom administrator roles such as Global Administrator, Privileged Role Administrator, and Application Administrator. Role assignments decide who can change the tenant, and over-assigned roles are a top-tier risk.

A defender mostly lives in two surfaces over these objects: the sign-in logs (every authentication, with the conditions and policies that applied) and the audit logs (every change to the directory). Both are reachable in the Entra admin center and via the Microsoft Graph API.

Common Entra ID attacks

Because Entra ID has no Kerberos or NTLM, attackers go after credentials, tokens, and consent. The goal is the same as on-prem: a valid identity, ideally a privileged one, that survives a password reset. These techniques are well documented, and most leave signal in the sign-in or audit logs.

Password spray and credential attacks. Rather than hammer one account and trip lockout, an attacker tries one common password across thousands of accounts. It is slow, quiet, and effective against tenants without strong MFA. Credential theft from infostealer malware and credential stuffing from breach dumps feed the same goal: a working username and password.

Adversary-in-the-Middle (AiTM) phishing. A reverse-proxy phishing kit (Evilginx and its successors) sits between the user and the real Microsoft login page. The user authenticates and even completes MFA, but the proxy captures the resulting session cookie. The attacker replays that cookie and is signed in as the user, MFA already satisfied. AiTM is the standard way attackers defeat basic MFA today.

Token theft and replay. Entra ID issues access and refresh tokens after a successful sign-in. Steal the token, from a compromised endpoint, an AiTM proxy, or a vulnerable app, and you authenticate as the user without their password and often without re-triggering MFA. Tokens stay valid until they expire or are explicitly revoked; a password reset alone does not kill an active refresh token.

OAuth consent phishing (illicit consent grant). Instead of stealing a password, the attacker registers a malicious application and tricks the user into granting it OAuth permissions, often through a convincing consent screen for a normal-looking app. Once consent is given, the app holds a token to read mail, files, or other data within the granted scope. This is durable: the grant survives password resets and MFA, because the user authorized it. Microsoft documents this as illicit consent grant, and it is a favored persistence move, including by state actors such as APT29 (Midnight Blizzard).

Privilege escalation and persistence. With a foothold, an attacker hunts for paths to Global Administrator or other high roles, then plants persistence that is hard to spot: adding credentials to an existing service principal, registering a new federated trust, or creating a backdoor admin. These changes show up in the audit log if you are watching for them.

The defender takeaway: nearly all of this produces telemetry. A sign-in from an anonymized IP, a successful auth followed by activity from a new ASN, a new consent grant to an unverified app, a credential added to a service principal, these are detectable events when the logs reach a SIEM.

How to secure Entra ID

No single setting hardens Entra ID. The controls stack, each one closing a class of the attacks above.

Enforce phishing-resistant MFA. MFA is the single highest-impact control, but not all MFA is equal. SMS and basic push are defeated by AiTM and MFA-fatigue attacks. Move privileged accounts, and ideally everyone, to phishing-resistant methods: FIDO2 security keys, Windows Hello for Business, or certificate-based authentication. These bind the credential to the legitimate origin, so a proxy cannot replay them.

Build Conditional Access as the policy spine. Conditional Access is where enforcement lives. Baseline policies: require MFA for all users, block legacy authentication protocols (which cannot enforce MFA and are a password-spray haven), require compliant or hybrid-joined devices for sensitive apps, and restrict access by location where it fits. With P2, add risk-based policies that force a step-up or block when Identity Protection flags a risky sign-in. Conditional Access is covered in depth in the dedicated Conditional Access entry.

Apply least privilege to admin roles. Audit who holds Global Administrator and other high roles, and cut it to the few who need it. Microsoft's guidance is to keep Global Admins to a small number and use granular roles for everything else. Use Privileged Identity Management (PIM, P2) to make privileged roles just-in-time and time-bound rather than standing, so an account is only an admin for the window it is actively used.

Govern application consent. Turn off the default that lets any user consent to any app. Restrict user consent to verified publishers and low-risk permissions, route the rest through an admin consent workflow, and review existing enterprise-app permissions for over-scoped or unused grants. This is the direct defense against illicit consent grants.

Protect tokens and revoke fast. Shorten session lifetimes for sensitive access, require sign-in frequency in Conditional Access, and when an account is compromised, revoke its refresh tokens explicitly, not just reset the password. Continuous Access Evaluation (CAE) shortens the window between a revocation and its enforcement.

Monitor the logs. Feed Entra sign-in and audit logs into your SIEM and alert on the high-value signals: sign-ins from anonymized or anonymizing IPs, impossible-travel pairs, new consent grants, new credentials on service principals, changes to Conditional Access policies, and additions to privileged roles. Identity Protection surfaces risky sign-ins and risky users; treat its detections as leads to investigate, not just dashboard color.

The order matters less than the layering. Phishing-resistant MFA and Conditional Access close the front door; least privilege and PIM shrink what a compromised account can reach; consent governance kills the OAuth path; and monitoring turns whatever slips through into an alert.

Entra ID security checklist

A practical baseline, in rough priority order:

1. Enforce MFA for every user; require phishing-resistant methods for admins.
2. Block legacy authentication protocols tenant-wide.
3. Build Conditional Access baseline policies (MFA, device compliance, location, legacy-auth block).
4. Enable risk-based Conditional Access where P2 licensing allows.
5. Minimize Global Administrator assignments; use granular roles.
6. Make privileged roles just-in-time with Privileged Identity Management.
7. Restrict user app consent; require admin consent for sensitive permissions.
8. Review existing enterprise-app permissions and service-principal credentials.
9. Shorten session lifetimes for sensitive access; enable Continuous Access Evaluation.
10. Stream sign-in and audit logs to a SIEM; alert on risky sign-ins, new consents, and role changes.
11. Secure the hybrid link (Entra Connect sync account, on-prem AD) as Tier 0.

Frequently Asked Questions

Is Entra ID the same as Azure Active Directory?

Yes. Microsoft renamed Azure Active Directory to Microsoft Entra ID, announced on July 11, 2023 and rolled out through the rest of that year. The service, features, APIs, and licensing did not change, only the name. Older documentation, scripts, and threat reports that say "Azure AD" or "AAD" refer to the same product.

Is Entra ID the same as on-premises Active Directory?

No. On-premises Active Directory Domain Services authenticates domain-joined Windows machines with Kerberos, NTLM, and LDAP inside a trusted network. Entra ID is a cloud IAM service for SaaS and cloud apps that uses web protocols (SAML, OAuth 2.0, OpenID Connect) and has no Group Policy or organizational units. Many organizations run both and synchronize them with Microsoft Entra Connect.

What are the most common Entra ID attacks?

Password spray, adversary-in-the-middle (AiTM) phishing, token theft and replay, and OAuth illicit consent grants. AiTM and token theft are notable because they bypass basic MFA by stealing a session after the user authenticates. Consent phishing is durable because the malicious app keeps its access through password resets.

Does MFA stop Entra ID attacks?

It stops many, but basic MFA (SMS, push approval) is defeated by AiTM phishing and MFA-fatigue attacks that capture or wear down the session. Phishing-resistant methods such as FIDO2 keys, Windows Hello for Business, and certificate-based authentication bind the login to the real origin, so a proxy cannot replay it. Pair MFA with Conditional Access for real coverage.

What is Conditional Access in Entra ID?

Conditional Access is the policy engine that evaluates each sign-in against signals, the user, device, location, and risk level, and decides whether to allow, block, or require a step such as multi-factor authentication. It is the primary enforcement mechanism in Entra ID and the place where MFA, device compliance, and risk-based controls are actually applied.

Which Entra ID license do I need for security features?

The Free tier (bundled with Microsoft 365 and Azure) covers basic SSO and MFA. Conditional Access requires Entra ID P1. Risk-based Identity Protection and Privileged Identity Management, the features defenders rely on most, require Entra ID P2.

The bottom line

Entra ID is Azure Active Directory under a new name, and it is the identity control plane for every Microsoft 365 and Azure tenant. It is not on-premises Active Directory: no Kerberos, no Group Policy, no LDAP, and so none of the classic AD attacks. Its attack surface is tokens, credentials, and OAuth consent, and the techniques that hit it, password spray, AiTM phishing, token replay, and illicit consent grants, mostly aim at a valid identity that outlives a password reset. The defense is layered: phishing-resistant MFA and Conditional Access at the front, least privilege and just-in-time admin behind them, consent governance to kill the OAuth path, and log monitoring so what slips through becomes an alert. The way to make it instinctive is to read real Entra sign-in and audit logs and learn to tell a normal token from a stolen one.