Microsoft Entra ID

What Entra ID is

Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It holds user accounts, groups, devices and applications, signs people in, enforces multi-factor authentication (MFA) and conditional access, and issues the tokens that Microsoft 365, Azure and thousands of other applications accept. In the terms of What Is Identity Management?, it is an identity provider. Until 2023 it was called Azure Active Directory (Azure AD); Microsoft announced the rename on 11 July 2023, and older documentation, scripts and exam material still use the old name. Microsoft asks people not to abbreviate it as "AAD" any more.

The old name caused a lasting misunderstanding: Entra ID is not Active Directory Domain Services (AD DS) hosted by Microsoft. AD DS (see Active Directory Fundamentals) was designed for a company network: computers join a domain, talk to domain controllers over Lightweight Directory Access Protocol (LDAP), Kerberos and NTLM, and receive Group Policy. Entra ID was designed for the internet: everything goes over HTTPS, using the token protocols described in Single Sign-On and Federation.

Applications that really need LDAP or Kerberos can use Microsoft Entra Domain Services, a managed domain that Microsoft runs for you — but it is a separate service, and you still cannot use it as a full replacement for your own domain controllers.

The Microsoft Entra family

"Microsoft Entra" is the name of a product family; Entra ID is its core. As of 2026, Microsoft's overview lists these members:

• Entra ID and Entra ID Protection (risk detection for users and sign-ins);
• Entra ID Governance: access reviews, lifecycle workflows, entitlement management and Privileged Identity Management (see The Identity Lifecycle);
• Entra External ID: identities of customers and partners. It succeeds Azure AD B2C, which stopped being sold to new customers on 1 May 2025;
• Entra Verified ID: verifiable credentials that a person holds in a wallet;
• Entra Private Access and Entra Internet Access: network access based on identity, a replacement for many virtual private network (VPN) uses;
• Entra Workload ID: identities for applications and services (see Identity for Applications and Machines);
• Entra Agent ID: identities for AI agents, so an agent that acts on its own (see AI Agents and Tool Use) can be governed like any other identity;
• Entra Domain Services (above).

Product names in this family change often. When you read older material, translate: Azure AD Connect is now Entra Connect, Azure AD Identity Protection is ID Protection, and "Hybrid Azure AD join" is Entra hybrid join.

The tenant

An Entra tenant is one dedicated instance of Entra ID for one organization: its own directory of users, groups, devices and applications, its own policies and its own administrators. A tenant is created automatically when an organization first subscribes to Microsoft 365, Azure or another Microsoft cloud service. It is identified by a tenant ID (a GUID, a globally unique identifier) and starts with an initial domain of the form <name>.onmicrosoft.com. Administrators then add and verify their own domain — Kestrel Energy verifies example.com by adding a DNS TXT record — so that users sign in as lucia.romero@example.com, their user principal name (UPN).

Some properties of a tenant that matter in daily work:

• It is a security boundary. Administrators of one tenant have no rights in another. People from other organizations come in as guest users (Entra B2B collaboration) and keep signing in with their own organization's account.
• Azure subscriptions trust exactly one tenant for their identities. Entra roles (who manages the directory) and Azure role-based access control (who manages resources in a subscription — see Azure role assignments) are separate systems.
• Licenses decide features. Entra ID Free comes with every subscription; Entra ID P1 adds conditional access and dynamic groups; Entra ID P2 adds ID Protection's risk-based policies and Privileged Identity Management. Microsoft 365 and Entra Suite bundles include these plans.

Users and groups

A user in Entra ID is either a member (part of the organization) or a guest (invited from outside), and either cloud-only (created in Entra ID) or synchronized from Active Directory. For a synchronized user, the on-premises directory stays the source of authority: change the department in AD DS, not in the Entra admin center, or the next synchronization overwrites your edit (most attributes are read-only in the cloud for that reason).

Entra ID has two group types:

• Security groups grant access to applications, Azure resources and policies; members can be users, devices, service principals and other groups. They play the role that security groups play in AD DS (see Users, Groups and Computers).
• Microsoft 365 groups are collaboration groups: each comes with a shared mailbox, calendar, SharePoint site and, optionally, a Team. Their members are users only.

Membership is either assigned (an administrator or group owner adds people) or dynamic: a rule over user or device attributes, re-evaluated automatically when attributes change. Dynamic groups need an Entra ID P1 license. A rule such as "everyone in Billing who is an enabled member" turns HR data into access automatically — when someone moves department, their access moves too. The sketch below evaluates such a rule the way Entra ID does, one condition at a time:

# A dynamic membership rule, written as (attribute, operator, value) conditions.
# Entra ID joins conditions with -and / -or; this sketch only supports -and.
RULE = [
    ("department", "-eq", "Billing"),
    ("userType", "-eq", "Member"),
    ("accountEnabled", "-eq", True),
]

USERS = [
    {"displayName": "Lucía Romero", "department": "Billing", "userType": "Member", "accountEnabled": True},
    {"displayName": "Joost Bakker", "department": "Billing", "userType": "Member", "accountEnabled": True},
    {"displayName": "Mei Chen", "department": "Service Desk", "userType": "Member", "accountEnabled": True},
    {"displayName": "Billing test account", "department": "Billing", "userType": "Member", "accountEnabled": False},
    {"displayName": "External auditor", "department": "Billing", "userType": "Guest", "accountEnabled": True},
]

OPERATORS = {
    "-eq": lambda actual, wanted: actual == wanted,
    "-ne": lambda actual, wanted: actual != wanted,
    "-startsWith": lambda actual, wanted: str(actual).startswith(wanted),
}


def rule_text(rule):
    """Show the rule in the syntax the Entra admin center uses."""
    def value(v):
        return str(v).lower() if isinstance(v, bool) else f'"{v}"'
    return " -and ".join(f"(user.{a} {op} {value(v)})" for a, op, v in rule)


def failed_condition(user, rule):
    """Return the first condition the user does not meet, or None."""
    for attribute, op, wanted in rule:
        if not OPERATORS[op](user.get(attribute), wanted):
            return f"{attribute} is {user.get(attribute)!r}"
    return None


print(rule_text(RULE))
print()
for user in USERS:
    reason = failed_condition(user, RULE)
    status = "member" if reason is None else f"not a member ({reason})"
    print(f"{user['displayName']:<22}{status}")

(user.department -eq "Billing") -and (user.userType -eq "Member") -and (user.accountEnabled -eq true)

Lucía Romero          member
Joost Bakker          member
Mei Chen              not a member (department is 'Service Desk')
Billing test account  not a member (accountEnabled is False)
External auditor      not a member (userType is 'Guest')

Dynamic groups are only as good as the data behind them. If HR types "billing" in one record and "Billing" in another, or a department attribute is never filled in, people silently fall out of (or into) groups. Treat the attributes that drive dynamic groups as part of your access control, with owners and checks.

App registrations and enterprise applications

Every application that signs users in through Entra ID, or calls an API with its own identity, exists in the directory as two linked objects. Beginners mix them up constantly, because the admin center shows them under two different menus.

An app registration is the global definition of an application, created in the tenant of the organization that builds it (its home tenant). It holds the application (client) ID, the redirect URIs where tokens may be sent, the API permissions the app asks for, and its credentials — client secrets or certificates.

An enterprise application is the local instance of an application in one tenant: technically a service principal (see Identity for Applications and Machines). It is where that tenant decides who may use the app (user and group assignment), which permissions were consented to, and how single sign-on is configured. An app built in-house has both objects in the same tenant. A software-as-a-service (SaaS) application from a vendor — a payroll service, say — has its registration in the vendor's tenant and only an enterprise application in yours.

Consent is how an application gets permissions: a user or an administrator approves a list such as "read your mail" or "read all users' profiles". Permissions that reach beyond the signed-in user need admin consent. Attackers abuse consent with fake applications that ask users for broad access (consent phishing, MITRE ATT&CK T1528), which is why many organizations restrict user consent to low-risk permissions from verified publishers and route the rest through an admin consent workflow. See Attacks on Identity.

Directory roles

A directory role is a set of administrative permissions over Entra ID and Microsoft 365 services, assigned to a user, group or service principal. Entra ID has dozens of built-in roles plus custom roles (P1). Roles can be assigned for the whole tenant or scoped to an administrative unit, so a regional service desk manages only its own users.

Least privilege (see Authorization Models) applies directly: a service desk analyst who resets passwords needs Password Administrator (or Helpdesk Administrator if they also sign users out), not Global Administrator. Microsoft's guidance is to keep Global Administrators to fewer than five, and to make powerful roles eligible rather than permanent through Privileged Identity Management, so they are activated just in time, with a reason and an expiry (see Privileged Access Management).

Hybrid identity

Most organizations that have used Windows for years still run AD DS for their file servers, line-of-business applications and domain-joined computers, and use Entra ID for Microsoft 365 and SaaS applications. Hybrid identity is the arrangement that gives each person one identity across both: accounts are created and managed on-premises and synchronized to Entra ID, so the same user name and password (and the same leaver process) work in both places.

Entra Connect Sync and Cloud Sync

Microsoft Entra Connect is Microsoft's tool set for hybrid identity; its synchronization component, Entra Connect Sync (formerly Azure AD Connect Sync), is a full synchronization engine installed on a Windows server on-premises. It reads users, groups and devices from one or more AD forests, applies filtering and attribute rules, and writes the result to Entra ID on a schedule (by default every 30 minutes). Because it holds powerful credentials for both AD DS and Entra ID, its server belongs in the same protection tier as your domain controllers.

Microsoft Entra Cloud Sync does the same job with lightweight provisioning agents on-premises, while the configuration lives in the cloud. Several agents give high availability, and disconnected forests (after a merger, for example) are easier to handle. Microsoft calls Cloud Sync the future of synchronization and says it replaces Entra Connect: as of 2026, its guidance is to consider Cloud Sync first for a new deployment, and to stay on Connect Sync only for features Cloud Sync does not support yet — check Microsoft's comparison table for your scenario. The older Azure AD Connect V1 was retired in August 2022, and DirSync and Azure AD Sync no longer work.

Two design decisions come up in every synchronization project:

• Scope: synchronize only the OUs and groups that hold real people and the groups they need in the cloud — not service accounts, disabled accounts or the built-in administrators.
• Matching: each synchronized object is linked to its cloud counterpart by an immutable anchor attribute. The UPN suffix (@example.com) must be a verified domain in the tenant, or users end up with an onmicrosoft.com name.

Password hash sync, pass-through authentication and federation

Synchronizing accounts is not enough; Entra ID must also be able to check the password when a user signs in to a cloud application. There are three ways.

With password hash synchronization (PHS), the sync engine takes the password hash that AD DS stores, hashes it again with a per-user salt and many iterations, and sends that result to Entra ID. The password itself, and the hash AD DS uses, never leave the network. Entra ID then checks passwords on its own, so cloud sign-in keeps working when the on-premises network is down, and ID Protection can compare the hashes with credentials found in leaks. Microsoft recommends PHS as the default — and turning it on as a backup even when you use another method.

With pass-through authentication (PTA), Entra ID sends the sign-in to lightweight agents on-premises, which check the password against AD DS. The agents only make outbound connections. Use it when policy forbids any password-derived data in the cloud, or when on-premises account states (such as logon hours) must apply instantly. Run at least three agents: if they are all down, nobody can sign in to the cloud.

With federation, Entra ID hands authentication to another identity provider — classically Active Directory Federation Services (AD FS) — and trusts the signed token it returns. It supports scenarios the others did not, such as third-party MFA servers or smart-card sign-in on-premises, but it is a farm of servers to run and patch, and its token-signing certificate is a crown jewel: whoever steals it can forge sign-ins for any user (Golden SAML, ATT&CK T1606.002). Migrating from AD FS to PHS or PTA is a standard project today, and SC-300 lists it as a skill.

With PHS or PTA, seamless single sign-on lets domain-joined computers on the company network sign users in to cloud apps without typing a password, using a Kerberos ticket. On Windows devices that are Entra joined or Entra hybrid joined, the Primary Refresh Token does this job for cloud sign-in.

Managing Entra ID with Microsoft Graph PowerShell

Everything in Entra ID is reachable through Microsoft Graph, the REST API behind the admin centers. For scripts, administrators use the Microsoft Graph PowerShell SDK (Install-Module Microsoft.Graph). The older MSOnline and AzureAD modules, which many scripts and blog posts still show, were retired in 2025 and no longer work (MSOnline from April–May 2025, AzureAD from mid-October 2025); rewrite such scripts with Microsoft Graph PowerShell (or the Microsoft Entra PowerShell module) instead of patching them. There is no tenant behind this page, so the commands below are not run; their output is illustrative.

You first connect and ask for the permissions (scopes) the session needs — read-only scopes for a report, nothing more:

Connect-MgGraph -Scopes "User.Read.All", "Group.Read.All", "RoleManagement.Read.Directory"

Welcome to Microsoft Graph!

Get-MgUser returns only a few default properties; ask for others explicitly with -Property. Here the service desk checks whether a user is synchronized from AD DS before trying to change her department in the cloud:

Get-MgUser -UserId "lucia.romero@example.com" `
    -Property DisplayName, UserPrincipalName, Department, AccountEnabled, OnPremisesSyncEnabled |
    Format-List DisplayName, UserPrincipalName, Department, AccountEnabled, OnPremisesSyncEnabled

DisplayName           : Lucía Romero
UserPrincipalName     : lucia.romero@example.com
Department            : Billing
AccountEnabled        : True
OnPremisesSyncEnabled : True

OnPremisesSyncEnabled : True means: change it in AD DS. The next example lists who holds the Global Administrator role — a report worth running regularly:

$role = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'"
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id |
    ForEach-Object { $_.AdditionalProperties["userPrincipalName"] }

admin-identity1@example.com
admin-identity2@example.com
breakglass-01@<tenant>.onmicrosoft.com
breakglass-02@<tenant>.onmicrosoft.com

Note that the administrators use separate admin accounts, not their everyday mailbox accounts, and that two emergency access (break-glass) accounts — cloud-only, on the onmicrosoft.com domain — are in the list on purpose. This lists active assignments only; people who are eligible through PIM appear in Privileged Identity Management (or Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance), so check both. Disconnect with Disconnect-MgGraph when you are done.

Securing the tenant

Mandatory MFA for Azure administration

Microsoft now enforces MFA for anyone who manages Azure, whatever the tenant's own policies say:

• Phase 1, from October 2024: sign-in to the Azure portal, the Microsoft Entra admin center and the Intune admin center; the Microsoft 365 admin center followed from February 2025.
• Phase 2, from 1 October 2025: Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools and the Azure Resource Manager API, for create, update and delete operations. Tenants could postpone this until 1 July 2026.

Break-glass accounts are included, so give them a phishing-resistant method such as a FIDO2 security key (see MFA and Passwordless). Workload identities — managed identities and service principals — are excluded, which is one more reason to move scripts that run under a user account to a workload identity.

Common mistakes

• Leaving legacy authentication (protocols that cannot do MFA, such as basic authentication for old mail clients) allowed; block it with conditional access or security defaults (see Conditional Access and Zero Trust).
• Letting users consent to any application, which invites consent phishing.
• Forgetting that guests stay in the tenant after a project ends; review them like any other access (see The Identity Lifecycle).