Microsoft AZ-104 - Microsoft Azure Administrator - Manage Azure Identities and Governance - Manage Microsoft Entra users and groups
Manage Azure Identities and Governance — 20–25%
Manage Microsoft Entra Users and Groups
Overview of Azure Entre and Active Directory integration types
Create users and groups
Manage user and group properties
Manage licenses in Microsoft Entra ID
Manage external users
Configure Self-Service Password Reset (SSPR)
Manage devices
Overview of Azure Entre and Active Directory integration types
Organizations often use Active Directory Domain Services (AD DS) for their existing Windows environment and Microsoft Entra ID for cloud services. Integration allows users to access both environments with a consistent identity.
The essential distinction is:
Synchronization: Creates and updates corresponding directory objects.
Authentication (AuthN): Verifies who the user is.
Authorization (AuthZ): Determines which resources and actions the user can access.
Diagram 1: Hybrid identity—connecting on-premises AD DS to Microsoft Entra ID
AD DS provides domain services such as domain join, Group Policy, Kerberos, NTLM, and LDAP. Microsoft Entra ID provides cloud identity capabilities, including modern authentication, application single sign-on, MFA, and Conditional Access.
An identity provider (IdP) authenticates identities and supplies trusted authentication information to applications. Entra ID commonly fills this role for cloud applications.
For identities synchronized from AD DS, AD DS is normally authoritative for the synchronized attributes. Administrators make those changes in AD DS, and the synchronization service updates Entra ID. Cloud-only accounts are managed directly in Entra ID.
Synchronization does not copy an entire AD domain into the cloud. Entra ID does not become another domain controller, and organizational units and Group Policy do not become equivalent cloud structures.
Writeback enables specific supported operations in the reverse direction. For example, a password reset through Entra self-service password reset can update the password in AD DS. This requires configuration, permissions, and appropriate licensing; it is not unrestricted two-way directory synchronization. Both Connect Sync and Cloud Sync support password writeback.
Diagram 2: Connect Sync versus Cloud Sync
Microsoft Entra Connect Sync
Connect Sync runs its synchronization engine on an on-premises Windows Server. It supports established hybrid deployments and advanced synchronization rules.
For a tenant using Connect Sync, there is one active exporting Connect Sync server, with optional staging servers. Multiple independent active Connect Sync servers targeting the same tenant are not the supported availability model.
Microsoft Entra Cloud Sync
Cloud Sync moves synchronization configuration and orchestration into Microsoft’s cloud provisioning service. Lightweight agents still run on-premises to communicate with AD DS.
It supports multiple active agents for availability and can connect disconnected AD forests, making it useful for acquisitions or organizations with separate directory environments.
Feature | Connect Sync | Cloud Sync |
Synchronization engine | On-premises server | Cloud provisioning service |
Configuration management | Primarily on-premises | Microsoft Entra admin center |
On-premises component | Full synchronization server | Lightweight provisioning agents |
Availability model | Active server with staging server | Multiple active agents |
Disconnected AD forests | Requires connectivity to the central sync server | Supported through agents in each environment |
Password hash synchronization | Supported | Supported |
Password writeback | Supported | Supported |
Advanced synchronization rules | More extensive rule engine | Attribute mappings and expressions; different limitations |
These differences matter more than simply choosing the newer product. Select the tool that supports the required topology and features. Current Microsoft documentation also lists device synchronization for hybrid join in Cloud Sync, enabled separately; older comparison slides may show otherwise.
Multiple tenants and the writeback limitation
A single AD directory can synchronize objects to multiple Entra tenants. With Connect Sync, each target tenant requires its own Connect Sync server.
The statement “AD can receive writeback from only one tenant” needs a qualification:
For the same AD object, features such as device/group writeback and hybrid Exchange configuration are restricted to one tenant.
Password writeback is an exception. Microsoft supports it from multiple tenants when password hash synchronization is configured appropriately. A password written back from one tenant updates AD DS, and PHS then propagates the derived password hash to the other tenants.
Diagram 3: Authentication options—where is the password validated?
These are alternative sign-in designs. Directory synchronization and sign-in authentication are separate choices.
Method | Password validation | Main consideration |
PHS | Entra ID validates against a synchronized, further-derived hash | Simplest general choice; password validation does not require live on-premises connectivity |
PTA | An on-premises agent validates against AD DS | Useful when AD account restrictions must be checked during password sign-in |
Federation | A trusted IdP performs authentication | Useful for requirements that need a separate authentication system |
Microsoft recommends enabling PHS, including alongside PTA or federation for resilience and leaked-credential detection. For many organizations, PHS is the preferred starting point because of its simpler infrastructure. Passwords are not synchronized as plaintext or reversibly encrypted values.
PTA depends on working agents, domain controllers, and connectivity. Federation depends on the chosen IdP and its supporting infrastructure. Having PHS enabled as a backup does not mean PTA or federation automatically switches to PHS during an outage; switching must be planned.
Understanding federation in both directions
Entra trusts another IdP: An organization uses AD FS or another supported provider to authenticate its users. Entra accepts the trusted result and completes access to cloud services.
An application trusts Entra as its IdP: A SaaS application redirects the user to Entra. Entra authenticates the user, or uses an existing sign-in session, and issues the appropriate token or assertion. This is a common application SSO design.
Therefore, an application using federated SSO with Entra does not mean that the organization’s user sign-in domain is federated to AD FS.
AZ-104 points to remember:
Synchronization answers: “How does the identity reach Entra ID?”
Authentication answers: “Where and how is the user verified?”
Authorization answers: “What may the authenticated user do?”
PHS validates passwords in Entra; PTA validates through an agent against AD DS; federation delegates authentication to a trusted IdP.
Cloud Sync still requires on-premises agents.
Writeback is feature-specific, and password writeback has a documented multi-tenant exception.
Create Users and Groups
1. Microsoft Entra ID users and directory objects
Microsoft Entra ID is the cloud identity service that authenticates identities and helps control access to Azure, Microsoft 365, and other applications. A tenant is an organization’s dedicated directory.
Member users
Member users typically represent people within your organization. Cloud accounts can use a sign-in name, or user principal name (UPN), such as alex@contoso.onmicrosoft.com or alex@contoso.com when the custom domain is verified.
Guest users
Guest users typically represent external collaborators invited through Microsoft Entra B2B collaboration. They generally authenticate using their existing identity provider. The resource tenant maintains a user object for them and controls their access.
Exam distinction: Member and Guest describe the user’s relationship and default directory permissions within the tenant. They do not definitively identify where the user authenticates; an external user can also have the Member user type. Guest directory permissions are restricted by default, and access to resources must still be granted.
The diagrams also include service principals and managed identities. These represent applications and workloads rather than people. A managed identity is a special service principal whose credentials Azure manages.
2. Group types versus membership types
Choose two things when creating a group: what the group is for and how its membership is maintained.
Characteristic | Security group | Microsoft 365 group |
Main purpose | Manage access to resources | Provide shared collaboration resources |
Supported members | Users, devices, service principals, and other security groups, subject to feature limitations | Users, including permitted guests |
Assigned membership | Supported | Supported |
Dynamic User membership | Supported | Supported |
Dynamic Device membership | Supported | Not supported |
Dynamic is a membership type, not a third group type. Assigned membership explicitly identifies members; dynamic membership automatically adds and removes members when their attributes meet or stop meeting a rule.
For example:
(user.department -eq "Finance")This rule includes users whose Department property equals Finance. A dynamic group contains users or devices, never both, and you cannot manually add or remove its members. Dynamic device rules evaluate device attributes, not the attributes of the device owner.
Dynamic user membership requires sufficient Microsoft Entra ID P1 licensing, or another qualifying entitlement, to cover each unique user in dynamic groups. Dynamic device membership does not require a license for each device. Membership processing is asynchronous, so changes might not appear immediately.
Practical uses: User groups can support license assignment, application access, and Conditional Access targeting. Device groups commonly support Intune application and configuration assignments.
3. Creating users and groups
To create an internal cloud user:
Open Microsoft Entra admin center → Entra ID → Users → New user → Create new user.
Enter the display name and UPN, selecting a tenant domain.
Configure the initial password and first sign-in password-change requirement.
Populate relevant properties, such as department, job title, and usage location.
Add appropriate groups and assign licenses or roles where needed.
Create the account and verify sign-in and access.
To invite an external user: Select Invite external user, enter the collaborator’s email and invitation details, and assign the required access. For an environment synchronized from on-premises AD DS, create synchronized identities in the authoritative source directory and synchronize them into Entra ID.
To create a group:
Open Entra ID → Groups → All groups → New group.
Select Security or Microsoft 365.
Enter the name and description.
Select Assigned, Dynamic User, or, for security groups, Dynamic Device.
Assign owners and either add members or configure a dynamic membership rule.
Create the group and configure its resource or policy assignments. Microsoft Learn
For scripting, use Microsoft Graph PowerShell for directory operations, for example, New-MgUser and New-MgGroup. The older AzureAD and MSOnline modules are legacy tools.
Key exam reminders:
Creating a user does not automatically grant access to Azure subscriptions or paid Microsoft 365 services.
Azure RBAC roles control Azure resource access; Microsoft Entra roles control directory administration.
A group owner manages the group; ownership does not automatically make that person a member.
A group used to assign Microsoft Entra roles must use Assigned membership, not dynamic membership. Microsoft Learn
Manage User and Group Properties
Microsoft Entra ID administrators maintain identity information, control account access, and manage the groups used for permissions, licensing, and collaboration.
Diagram 1: Managing user properties and account access
Open Microsoft Entra admin center → Entra ID → Users → All users, then select the user.
Management task | What to configure | Important distinction |
Update profile information | Display name, UPN, contact information, department, job title, and usage location | Display name and sign-in name are different properties |
Assign a manager | Set the Manager relationship in job information | Does not automatically grant the manager administrative permissions |
Reset a password | Issue a temporary password and require a change at next sign-in, where supported | A password reset does not replace MFA methods |
Enable or disable an account | Change Account enabled | Disabling preserves the user object; deleting removes it |
Configure authentication methods | Manage supported registered methods and require re-registration when necessary | User registrations and tenant authentication-method policies are separate settings |
Profile fields support more than contact information. For example, changing a user’s Department property can change their dynamic group membership and, consequently, group-based access. Usage location is especially relevant to license assignment. For synchronized users, edit attributes at their authoritative source, normally on-premises AD DS, rather than assuming every property should be changed in Entra.
Authentication methods require separate attention. A profile telephone number is not automatically the user’s registered MFA telephone number. Administrators manage individual registrations under the user’s Authentication methods; the tenant’s Authentication methods policy determines which methods targeted users may register and use.
Disabling an account blocks new sign-ins, but existing access may persist. When immediate access removal is needed, also revoke sign-in sessions and account for application sessions and token lifetimes. A password reset alone is not a complete access-revocation procedure.
Diagram 2: Managing group properties, membership, and ownership
Open Entra ID → Groups → All groups, then select the group.
Management task | Where or how to manage it | Key consideration |
Update name and description | Properties | Use a name and description that explain the group’s purpose |
Manage assigned membership | Members → Add members / Remove | Membership changes can affect access and licensing |
Manage dynamic membership | Dynamic membership rules | Change the rule or source attributes; do not manually add or remove members |
Modify ownership | Owners → Add owners / Remove | Owners administer the group; membership is a separate relationship |
Change membership type | Properties, where supported | Converting to dynamic membership causes membership to be evaluated against the rule |
Configure additional settings | Relevant Entra or Microsoft 365 settings | Options depend on group type, licensing, and administrative permissions |
The group’s Object ID is its stable identifier. Renaming the group preserves that ID and its existing references. Group type, Security versus Microsoft 365, cannot be changed through the group’s Properties page. Membership type can be changed where supported, but role-assignable groups must retain Assigned membership.
For ownership, assign at least two owners to support continuity. An owner is not automatically a member in every creation or management workflow; verify both relationships when the owner also needs member access.
Additional settings can include Microsoft 365 group privacy, guest participation, naming policies, expiration policies, and sensitivity labels. These settings are not all available for every group, and some are managed through other Microsoft 365 administration interfaces. Groups synchronized from AD DS normally have their membership managed on-premises; distribution lists and mail-enabled security groups use Exchange or Microsoft 365 administration tools.
AZ-104 reminders:
User Administrator commonly handles user profiles and account management; sensitive operations depend on the target user’s role.
Groups Administrator commonly manages ordinary cloud group properties, members, and owners.
Authentication administration requires the appropriate authentication role; Azure subscription Owner does not automatically grant Entra directory administration rights.
A manager, group owner, and group member are distinct relationships.
Dynamic membership depends on accurate attributes. Changing a department can change access without a manual membership edit.
Review audit logs and verify the resulting properties and membership after changes.
Manage Licenses in Microsoft Entra ID
Licenses provide entitlement to Microsoft services and premium identity features. Management involves assigning products to users, controlling the included services, monitoring consumption, and reclaiming unused assignments.
Current administration location: Use the Microsoft 365 admin center → Billing → Licenses for user and group license assignments. Microsoft Graph and Microsoft Graph PowerShell also support licensing operations.
Diagram 1: Direct assignment versus group-based licensing
Assignment method | How it works | Typical use |
Direct assignment | Assign a product to a particular user | Individual requirements, exceptions, or small deployments |
Group-based licensing | Assign products to a group; eligible user members inherit them | Consistent licensing by role, department, or workforce category |
Dynamic group-based licensing | Attribute rules maintain group membership, triggering licensing updates | Automated onboarding and job-change workflows |
Group-based licensing is generally preferred for consistent administration at scale. Adding or removing a user triggers assignment or removal of the group’s licenses. It does not purchase additional seats: insufficient capacity can leave users without a successful assignment.
For example, a dynamic user group could use:
(user.department -eq "Finance")Assign the required product to that group. When a user meets the rule, membership processing and then licensing processing apply the assignment. These processes are asynchronous.
Important membership rules:
Nested-group membership does not propagate licenses. Users must be members of the licensed group itself.
To remove an inherited assignment, change the group assignment or the user’s membership.
Removing a direct assignment does not remove an equivalent group assignment, and leaving one group does not remove assignments received elsewhere.
Before replacing direct licensing with group licensing, confirm that the group assignment supplies all required service functionality.
Diagram 2: License and service-plan management lifecycle
Products and service plans
A product license, identified technically by a SKU, can include multiple service plans. These represent individual services or capabilities within the product.
Concept | Meaning | Example |
Product / SKU | The licensed product or bundle | Office 365 E3 |
Service plan | A service entitlement within that product | Exchange Online or SharePoint Online |
Assignment options | Which included plans are enabled | Enable Exchange while disabling an unneeded service |
Administrators can enable or disable included services during assignment or later. Some plans depend on others, and some combinations conflict. Disabling a service plan does not create an additional product license seat.
Common management tasks
Task | What to do |
Assign an individual license | Select the user or product, choose the license, and configure included services |
Assign group licenses | Select the group and product; configure the services members should receive |
View consumption | Compare purchased, assigned, and available quantities for each product |
Remove an assignment | Remove the direct license or its group-based source |
Reassign a license | Reclaim an available seat, then assign it to an eligible user |
Troubleshoot failures | Inspect Errors & issues, correct the cause, and reprocess |
The Licenses page can aggregate multiple subscriptions for the same product. For example, subscriptions containing five and eight seats can appear as 13 total licenses for that product.
Common assignment problems
Insufficient licenses: Free unused seats or obtain additional capacity.
Invalid or unsupported usage location: Correct the user’s country or region and check service availability.
Conflicting service plans: Adjust overlapping products or disable the conflicting plan.
Missing dependencies: Supply the prerequisite service or remove the dependent service.
Membership processing incomplete: Verify that the user actually appears in the licensed group.
Set Usage location explicitly during onboarding, especially for multinational organizations. Group-based licensing can use the tenant location when a user has no explicit location, which might not represent where that user works.
When moving between licensed groups: Add the user to the destination group, verify that the replacement license has applied, and then remove the original membership. This helps prevent an interruption in service.
AZ-104 reminders:
A license grants service entitlement; an Azure RBAC role grants permissions to Azure resources.
Synchronizing a user from AD DS does not automatically assign a Microsoft 365 license.
Disabling a user account does not automatically reclaim its licenses.
Removing a license assignment does not reduce the purchased subscription quantity.
License removal can affect service access and data retention; follow the applicable service’s offboarding requirements.
License Administrator is a purpose-built role for license assignment management.
Manage External Users
Microsoft Entra B2B collaboration lets partners, suppliers, and contractors use their existing identities to access your organization’s applications and resources. Your tenant controls what they can access.
Microsoft Entra External ID covers both business collaboration in workforce tenants and customer identity in external tenants. These are different deployment scenarios.
Diagram 1: B2B collaboration—external authentication, organizational access control
The external user typically retains their original credentials. Your tenant creates a B2B user object, normally with User type = Guest, to represent that person and manage their access.
Supported authentication options include Microsoft Entra work or school accounts, personal Microsoft accounts, configured Google federation, and configured SAML/WS-Fed providers. Email one-time passcode can authenticate guests who cannot use another supported identity.
A guest UPN commonly looks like:
This identifies the guest object in your directory. The guest generally signs in using their original identity rather than typing this generated UPN.
Authentication and authorization remain separate: Successfully signing in does not grant access to every resource. Assign the required application, group membership, or Azure RBAC role. Guest directory restrictions also do not replace resource-level permissions.
Diagram 2: Onboard, protect, and manage external users
Direct invitations
In the Microsoft Entra admin center, open Entra ID → Users → New user → Invite external user. Enter the external email address, configure invitation details, and send the invitation.
Guests can redeem access through the invitation email or a suitable direct application link. Administrators can check the invitation’s redemption status on the user object.
For automation, use Microsoft Graph PowerShell, such as New-MgInvitation, or the Microsoft Graph invitations API. When using Azure CLI, Graph operations can be invoked through az rest; a standard user-creation command is not equivalent to a B2B invitation.
Self-service sign-up
Self-service sign-up lets external users register for a specific application without an administrator inviting each person.
For B2B self-service sign-up:
Enable guest self-service sign-up under External Identities → External collaboration settings.
Configure the required identity providers.
Create a user flow specifying providers and collected attributes.
Associate the flow with your application.
These user flows apply to applications built by your organization; they are not a general sign-up mechanism for Microsoft applications such as Teams or SharePoint.
Provider distinction: Facebook is supported for configured B2B self-service sign-up flows, but not for redeeming direct B2B invitations. Provider support depends on the tenant configuration and onboarding method.
External-user controls
Control | What it governs |
External collaboration settings | Who may invite guests, guest directory visibility, invitation domain restrictions, and enabling self-service sign-up |
Cross-tenant access settings | Inbound and outbound collaboration with other Entra organizations, including user/group and application scope |
Cross-tenant trust settings | Whether to accept a partner tenant’s MFA, compliant-device, or hybrid-joined-device claims |
Conditional Access | Sign-in requirements applied to external users and resources |
Resource assignments | The applications, groups, sites, or Azure resources the user may access |
External collaboration settings and cross-tenant access settings serve different purposes; configuring one does not replace the other.
Trusting a partner’s MFA or device claims allows your Conditional Access policies to recognize those claims. Trust does not itself grant application access or create an MFA requirement. Configure the relevant policies and resource assignments separately.
Diagram 3: Business guests versus customer identities
Characteristic | B2B collaboration | External ID for customers |
Main purpose | Collaborate with external people | Authenticate users of customer-facing applications |
Tenant configuration | Workforce tenant | External tenant |
Typical onboarding | Invitations or B2B self-service sign-up | Customer sign-up and sign-in flows |
Identity representation | B2B user object, usually Guest | Customer account in the external tenant |
Example | A supplier accesses a project’s SharePoint site | A customer signs in to an online service |
Customer identity and access management is often abbreviated CIAM. An External ID external tenant provides a directory and authentication experience for consumer and business-customer applications, separate from the workforce collaboration model.
Update to the attached B2C screenshots: Azure AD B2C is an older customer identity product. It has been unavailable for purchase by new customers since May 1, 2025. Existing customers can continue using it, with support committed until at least May 2030. Microsoft Entra External ID is the current offering to evaluate for new customer identity deployments; it is not simply a rename of an existing B2C tenant.
Licensing distinction: Current External ID billing uses monthly active users (MAU), with feature-specific add-ons. The older 1:5 employee-to-guest license ratio should not be used as the current licensing model. External ID billing also does not automatically include licenses for every application a guest accesses.
AZ-104 reminders:
B2B guests usually keep their existing credentials.
An invitation establishes an identity relationship; resource permissions still determine access.
Guest Inviter is a purpose-built role for inviting guests, subject to tenant policy.
Use collaboration settings for invitation controls and cross-tenant settings for partner-tenant access and trust.
Review guest access periodically and remove access when the business need ends.
Keep workforce B2B collaboration distinct from customer identity in an external tenant.
Control who can invite B2B guests
Configure Entra ID → External Identities → External collaboration settings → Guest invite settings.
To restrict invitations to designated administrators, select Only users assigned to specific admin roles can invite guest users. For someone whose only responsibility is inviting guests, Guest Inviter is the least-privilege role. Permission to invite guests does not automatically grant those guests resource access.
Understand where users reset their passwords
Assuming the required SSPR licensing, policy scope, and registration are configured:
User | Password-reset behavior |
User1: Synced member | Can use SSPR with password writeback, which updates the password in on-premises AD DS |
User2: Cloud-only member | Can use SSPR directly in Entra ID; writeback is unnecessary |
User3: External B2B guest | Resets the password through their home tenant or identity provider, where their credentials are managed |
Password writeback connects cloud password resets to the authoritative on-premises directory. The determining factor for an external user is where the credentials are managed, rather than simply the Guest label. learn.microsoft.com
B2B enables access using an existing identity
Microsoft Entra B2B collaboration lets users access another organization’s resources using their existing identity and credentials. They generally do not need a separate username and password for the resource organization.
Clarification: B2B collaboration normally creates a guest user object in the resource tenant to manage permissions. Therefore, “no additional credentials” is more accurate than “no additional accounts.”
Configure Self-Service Password Reset (SSPR)
Microsoft Entra SSPR lets eligible users reset a forgotten password or unlock an account without contacting the help desk. Users must first register sufficient authentication information to verify their identity.
Diagram: Registration, verification, and password reset
Main configuration tasks
In the Microsoft Entra admin center, open Entra ID → Password reset.
Configuration area | What to configure |
User scope | Select None, Selected, or All; start with a pilot group |
Authentication methods | Enable supported verification methods for the targeted users |
Verification requirement | Require one or two methods to reset |
Registration | Require registration at sign-in and configure periodic reconfirmation |
Notifications | Notify users about resets and administrators about administrator resets |
On-premises integration | Enable password writeback and, where appropriate, unlock without resetting |
Monitoring | Review reset successes, failures, and registration activity |
Manage which methods users can use through Entra ID → Authentication methods → Policies. Legacy MFA and SSPR method-management policies were retired for this purpose beginning September 30, 2025. The reset verification count remains an SSPR configuration setting.
Registration and identity verification
Combined security information registration lets users register methods for both MFA and SSPR in one experience. Users can register at aka.ms/ssprsetup and initiate recovery at aka.ms/sspr.
Available methods include supported Authenticator notifications, verification codes, SMS, voice calls, and email verification. Method availability and combinations depend on policy and account type.
Registering a method does not automatically make it eligible for SSPR. It must be supported and enabled for that user. If two methods are required but the user has only one qualifying method registered, the reset cannot proceed. Authenticator and OATH code methods count as a single method category for this purpose; they cannot be combined to satisfy a two-method requirement.
Secure initial registration and Temporary Access Pass
Users need a secure way to register their first strong authentication method.
Conditional Access can target the user action Register security information to protect registration.
A Temporary Access Pass (TAP) is an administrator-issued, time-limited passcode, configured for one-time or multiple use.
TAP helps users sign in and register strong methods when they do not yet have one or have lost access to it.
TAP supports onboarding and authentication-method recovery; it is not an SSPR password-reset verification method and does not replace the user’s password. Registration policies must also permit the intended onboarding path, for example, TAP does not by itself satisfy a compliant-device requirement.
Hybrid password reset and writeback
For a synchronized user whose password is managed in AD DS, password writeback sends the cloud reset to the on-premises directory through Connect Sync or Cloud Sync.
AD DS checks the proposed password against its policies before accepting it. Writeback operates synchronously, allowing the user to receive immediate feedback if the password is rejected or the operation fails. Where configured, users can also unlock an on-premises account without changing its password.
AZ-104 reminders:
SSPR requires appropriate licensing, policy scope, and registered methods.
Cloud-only users do not need password writeback.
Hybrid users need configured, functioning writeback for cloud resets to update AD DS.
MFA and SSPR share registration information but serve different purposes.
Administrator accounts have stricter reset requirements.
Monitor audit logs and notifications to verify operation and investigate unexpected resets.
SSPR reduces help desk calls and recovery delays. Its security depends on protecting registration and requiring suitable identity verification.
Device Management
Microsoft Entra ID provides a device identity used for sign-in and access decisions. Microsoft Intune provides device configuration, compliance assessment, and application protection.
Registration or join does not automatically mean a device is managed or compliant.
Diagram 1: Microsoft Entra device identity types
Identity type | Typical scenario | Device sign-in | Management approach |
Entra registered | Personal laptops, tablets, and phones accessing work resources | Local or personal credentials, depending on platform | Optional MDM enrollment and/or application protection |
Entra joined | Organization-owned devices using cloud identity | Organizational Entra account | Typically Intune or another supported management tool |
Hybrid Entra joined | Organization-owned devices that retain AD DS domain membership | AD DS organizational account | Group Policy, Configuration Manager, and optionally Intune co-management |
Microsoft Entra registered
Registration creates a device object while allowing the user to retain their existing device sign-in. It supports BYOD scenarios across Windows, macOS, iOS/iPadOS, Android, and supported Linux distributions.
Registration is separate from enrollment: a registered device can also be enrolled in Intune for additional management. “Registered” therefore does not necessarily mean “unmanaged.”
Microsoft Entra joined
Entra join establishes a cloud-native organizational device identity without joining an on-premises AD domain. Windows 10/11 business editions are the classic example; Home editions do not support Entra join.
Platform clarification: Windows Server 2019 and newer support Entra join in the documented Azure VM scenario, rather than as a general replacement for domain join on every server. Current documentation also lists supported macOS and Linux join scenarios. Device configuration still requires a management tool such as Intune; Entra ID alone does not provide full endpoint management.
Microsoft Entra hybrid joined
A hybrid joined device remains joined to on-premises AD DS and also has an Entra device identity. This supports organizations retaining Group Policy, existing deployment tools, or applications requiring AD machine authentication.
Hybrid join requires configuration; ordinary AD domain join does not automatically establish it. These devices retain dependencies on domain-controller connectivity.
Diagram 2: MDM versus MAM
Capability | MDM | MAM |
Primary scope | Device configuration and security | Organizational applications and their data |
MDM enrollment required | Yes | No, for supported MAM-without-enrollment scenarios |
Typical controls | Encryption requirements, device restrictions, certificates, application deployment | App PIN, copy/paste restrictions, approved storage locations |
Compliance | Assess device compliance against policy | Enforce application protection requirements |
Removal action | Device retirement or wipe, depending on platform and enrollment | Selective removal of corporate app data |
Common use | Corporate devices and enrolled BYOD | Personal devices needing protected access to work apps |
MDM manages devices, but the extent of control depends on the operating system and enrollment mode. For example, personally owned Android devices can use a managed work profile rather than giving the organization unrestricted control over personal content.
MAM protects organizational data inside supported applications. Intune app protection policies can require an app PIN, restrict copying work data into personal apps, and prevent saving corporate information to personal storage. These protections can operate on enrolled or unenrolled devices.
Application management also includes configuration, deployment, and updates, but capabilities differ by platform and enrollment state. MAM without enrollment does not provide unrestricted application installation or device-wide management. Microsoft Learn
Example: A company laptop uses Entra join and Intune MDM for device settings and compliance. An employee’s personal phone uses MAM to protect work information in supported apps. Corporate devices can use MDM and MAM together for both device and application protection.
AZ-104 reminders:
Entra registered: Typically BYOD; personal/local device sign-in remains.
Entra joined: Cloud-native organizational device identity.
Hybrid joined: AD DS domain membership plus Entra identity.
MDM enrollment, Entra join, and compliance are separate states.
Intune evaluates device compliance; Conditional Access can require that compliance for access.
MAM without MDM enrollment can still require Entra device registration, for example, supported Microsoft 365 MAM scenarios on Android.
Comments