Azure Active Directory did not disappear when Microsoft renamed it Microsoft Entra ID. The name change announced on July 11, 2023 did not create a replacement tenant, move existing user accounts to a different directory, or require applications to be registered again solely because their provider’s product name changed. The continuity matters to administrators: older incident reports and scripts may say Azure AD, while today’s documentation and portal refer to the same cloud identity service as Microsoft Entra ID.
For learners using Microsoft AZ-104 Exam materials, the important task is to interpret identity and access requirements correctly despite mixed terminology. An administrator must know which directory contains the principal, how it authenticates, what application or Azure resource the principal may access, and which policies constrain the request. Those controls did not become interchangeable when the service was rebranded.
Separate the rebrand from an infrastructure migration
Microsoft’s announcement described a product-name change within the Microsoft Entra family. Existing organizations continued to use their tenant, application registrations, identities, authentication endpoints and licensing arrangements without a service migration caused by the renaming. The service-plan display names were adjusted in October 2023, but an old screenshot labeled Azure AD P1 can still document a capability now associated with Microsoft Entra ID P1.
This should not be confused with a different, real modernization task. Legacy AzureAD and MSOnline PowerShell modules were deprecated and retired on their own schedule, and Microsoft recommends using Microsoft Graph PowerShell or supported Entra PowerShell tooling for identity administration. Renaming a service and replacing an obsolete automation interface are separate events. An unchanged old API reference in a historical document does not prove that every historic client library or command is still supported today.
Keep a short terminology map in operational documentation: Azure Active Directory or Azure AD means the service now called Microsoft Entra ID; Windows Server Active Directory Domain Services refers to a distinct directory technology; Microsoft Entra is the wider product family; Microsoft identity platform is the collection of application and developer identity capabilities. This reduces the chance of treating unrelated components as a single “directory.”
Cloud identity is not a domain controller in a new location
Traditional Active Directory Domain Services supports directory functions associated with Windows domains, organizational units, Kerberos and LDAP, group policy and domain-joined computers. Microsoft Entra ID is a cloud identity and access management service used to authenticate users and applications to Microsoft 365, Azure and integrated services. Its management concepts and sign-in processes differ from administering an on-premises domain controller.
A hybrid organization may synchronize selected identities from Active Directory Domain Services to Microsoft Entra ID through a supported synchronization arrangement. Synchronization does not make the directories identical or cause every on-premises group policy to become a cloud access policy. The administrator must know which system is authoritative for a given attribute, which authentication method the user follows and what happens if synchronization or sign-in dependencies fail.
Suppose an employee changes departments and receives a new Microsoft 365 application role. That does not necessarily grant the same employee Azure subscription permissions. Similarly, changing a cloud user’s access to an enterprise application is not the same as editing membership in a domain group that controls an on-premises file share. The identity may be related across environments while the enforcement decisions remain different.
Tenants, users, service principals and managed identities
A Microsoft Entra tenant supplies an organizational identity boundary. Human accounts, invited external users, application registrations and service principals represent different kinds of identity or application context. A managed identity gives a supported Azure workload an identity for acquiring tokens without requiring the application to keep an ordinary reusable password in its configuration.
Consider a fictional public library that uses Azure to publish events. Staff authenticate to an internal publishing application; the application retrieves approved images from Blob Storage; an automation job archives expired listings. The staff member, web application and scheduled job need separately scoped permissions. A token accepted for one identity does not authorize every action on the storage account.
Application registration describes an application’s relationship with the identity platform, while a service principal represents the application’s instance within a tenant. Permissions depend on the target system and the consent or role model used. Administrators should be careful not to treat an application’s display name as proof that it possesses the appropriate permission, or to grant broad roles when a specific delegated or application permission is sufficient.
For application sign-in patterns and token handling, developer authentication with Microsoft Entra ID is relevant to the distinction between identifying the user and authorizing their subsequent business action. An authenticated employee still should not be able to update another department’s records unless the application enforces that business rule.
Authentication and Azure RBAC answer different questions
Authentication evaluates an identity claim: which person or workload is presenting credentials or a token, and under what conditions should the sign-in succeed? Azure role-based access control answers which Azure resource management or applicable data operations that principal may perform at a resource, resource-group or subscription scope. An authenticated principal can remain forbidden from a resource operation.
For example, the library’s infrastructure operator might sign in successfully through Microsoft Entra ID yet lack permission to delete a storage account. Giving that person a more powerful Azure role can change the result, but it may violate least privilege. An administrator should first inspect the required action, effective scope and intended resource owner before modifying assignments.
Azure Policy adds a further distinction. The operator could have sufficient role permissions to create a public storage account while an assigned governance policy rejects public network exposure. Azure RBAC and policy address different dimensions of control; neither can be diagnosed reliably by looking only at the user’s successful authentication event. The Azure Resource Manager hierarchy is relevant because both control types depend on where they are assigned.
Use an evidence-based test: record a permitted deployment and a deliberately prohibited configuration in an authorized sandbox. Identify which identity issued each request and whether the observed denial came from missing role permission, policy or an unrelated network/application error. Do not infer the cause solely from a generic “access denied” message.
Conditional Access evaluates the sign-in context
Conditional Access uses applicable policy conditions and grant or session controls to evaluate access to supported applications. Policies can account for signals such as targeted identities, applications, authentication strength, device conditions and risk where the organization has the necessary capabilities. It is not a replacement for application-specific authorization and should not be presented as a universal firewall for every action a signed-in user takes.
The library may require stronger authentication for privileged administrators while allowing ordinary staff to use approved client applications under different conditions. A policy change can block intended access if users, applications or conditions are misunderstood. Report-only evaluation and controlled test accounts can help teams assess effects before broad enforcement when the configuration supports those modes.
When a user reports that a cloud application stopped working, check sign-in logs, relevant Conditional Access policy results and application authorization separately. A successful identity-platform sign-in may be followed by an application denial; a blocked Conditional Access evaluation prevents the supported sign-in from completing. Those outcomes require different fixes.
The Conditional Access topic is important because its risk and device context operates at an access decision boundary rather than retroactively repairing every possible privilege or data exposure downstream.
Legacy PowerShell retirement is a separate operational risk
A company may have a script created years ago with AzureAD or MSOnline cmdlets. The rename to Microsoft Entra ID did not itself convert that script to newer APIs. Microsoft subsequently deprecated and retired the legacy modules. An administrator should inventory scheduled jobs and automation dependencies rather than assuming a historical script will continue to function because an old tenant still exists.
Microsoft recommends Microsoft Graph PowerShell for supported identity management. A change from an AzureAD cmdlet to a Graph cmdlet is not always a one-for-one string substitution; authentication, delegated or application permissions, consent, result shape and error handling may differ. A safe migration tests read-only inventory first, then a controlled create/update action in a test scope, with audit records and a rollback plan.
A scheduled group-maintenance script illustrates the risk. A successful interactive login to the Entra admin center does not demonstrate that the old unattended job has valid authentication or correctly scoped Graph permissions. Monitor its completion, verify the target group membership actually changed as intended, and ensure it does not continue silently with an insecure fallback credential.
This is particularly important when a replacement automation receives broader API permissions than the original job needed. Modernizing the module should preserve or reduce privilege, not become an excuse to grant tenant-wide access merely to remove errors from the logs.
Use one access incident to validate the full identity boundary
A newly hired staff member can sign in to the library’s productivity tools but cannot deploy a test resource to the library’s Azure subscription. The administrator should confirm the correct tenant, the principal represented by the token, the resource subscription and the applicable Azure role assignment. The inability to deploy does not prove an Entra authentication failure.
Later, the same person can deploy a permitted resource but cannot retrieve a blob from a web application. The diagnostic moves to the application’s workload identity, storage data-plane role, private endpoint and request path. An additional role assigned to the employee may be unrelated if the application performs the read using its own managed identity.
Finally, suppose a Conditional Access change blocks that staff member’s privileged application sign-in. Sign-in results, client details and applicable policy conditions now become central. The three incidents can all be described casually as an “Azure AD problem,” but they occur at different enforcement points and require distinct evidence.
Microsoft Entra ID is the current name of the cloud identity service formerly called Azure AD. The productive administrator skill is not memorizing the rename; it is accurately separating tenants, users, workloads, authentication, resource permissions and policy—and recognizing when a genuine technology retirement, such as an obsolete PowerShell module, requires a deliberate migration of its own.