2.1 Microsoft Entra Users, Groups, and Properties
Key Takeaways
- Microsoft Entra ID is the identity plane for Azure sign-in, while Azure RBAC controls authorization to Azure resources.
- User type, source, account state, department, usage location, and group membership can all affect administration scenarios.
- Security groups, Microsoft 365 groups, and dynamic groups solve different administration problems and are not interchangeable.
- Exam questions often separate creating an identity from granting that identity access to a subscription or resource.
Identity Plane First
Microsoft Entra ID is the directory service that authenticates users, groups, service principals, and managed identities for Azure. Azure subscriptions trust an Entra tenant, but the tenant and the subscription are not the same object. A user can exist in a tenant and still have no access to a subscription until an Azure RBAC role assignment, classic administrator setting, or another resource-specific permission grants access.
For AZ-104, start every identity question by identifying the plane being tested. Creating, disabling, inviting, deleting, restoring, and grouping users are Microsoft Entra administration tasks. Letting a user create virtual machines, read storage accounts, manage locks, or assign roles is Azure resource authorization. The portal deliberately blends these experiences, but the exam expects you to separate them.
Portal path for common identity work: Microsoft Entra ID > Users for users, Microsoft Entra ID > Groups for groups, and Microsoft Entra ID > Roles and administrators for directory roles. Azure resource roles are usually assigned from Subscription, Resource group, or a resource blade under Access control (IAM).
User Properties That Matter
A user object has many properties, but administrators repeatedly use a smaller set for support and automation.
| Property | Why it matters |
|---|---|
| User principal name | Sign-in name and common lookup value, such as alex@contoso.com. |
| Display name | Human-readable name; not a security boundary. |
| Object ID | Immutable identifier used by scripts and role assignments. |
| Account enabled | Disabled users cannot sign in, but assignments may still exist. |
| User type | Usually Member or Guest; affects collaboration and default treatment. |
| Source | Cloud, synchronized from AD DS, or external. Some properties may be mastered elsewhere. |
| Usage location | Required before many Microsoft cloud licenses can be assigned. |
| Department, job title, country | Useful for dynamic group rules and reporting. |
Exam trap: deleting a user does not automatically explain every access symptom. A deleted user may be recoverable for a limited period, role assignments can become orphaned, and group-based access may need group membership review. If a synced user has the wrong department, the fix might be in on-premises Active Directory followed by synchronization, not direct editing in the cloud.
Group Types And Membership
Security groups are commonly used to assign Azure RBAC roles, grant application access, and manage access at scale. Microsoft 365 groups are collaboration groups with mailbox, SharePoint, Teams, and planner style workloads; they can be security-enabled in some scenarios, but they are not the default answer for Azure resource access. Distribution groups are for email distribution and are not the normal control for Azure RBAC.
| Group choice | Best use |
|---|---|
| Security group | Assign Azure RBAC, application access, device or policy targeting. |
| Microsoft 365 group | Collaboration workspace with group mailbox and shared services. |
| Dynamic user group | Membership based on user attributes such as department. |
| Dynamic device group | Membership based on device attributes. |
| Assigned group | Membership managed manually or by automation. |
Dynamic membership is powerful, but it depends on accurate properties and the right license level. If the question says all users in the Finance department need Reader access to a resource group and new hires must be included automatically, the pattern is dynamic group plus RBAC assignment. If the question says add one contractor for one week, manual assignment to a security group may be simpler.
Portal And CLI Decision Logic
Use the portal when you need to inspect several properties, confirm group membership visually, invite a guest, or troubleshoot a user support ticket interactively. Use Azure CLI or Microsoft Graph PowerShell when you need repeatable creation, bulk updates, or evidence for change control. Azure CLI can show Entra users and groups, but many modern Entra operations are richer in Microsoft Graph PowerShell or the Entra admin center.
Common CLI orientation commands:
az ad user show --id alex@contoso.com
az ad user list --filter "startswith(displayName,'Alex')"
az ad group show --group "rg-network-readers"
az ad group member list --group "rg-network-readers"
The exam may show Azure CLI because AZ-104 administrators are expected to work with CLI, PowerShell, portal, ARM templates, and Bicep. Read the command carefully. az ad user create creates an identity; it does not assign Azure resource permissions. az role assignment create assigns a role at a scope; it does not create a user.
Troubleshooting Identity Questions
A practical troubleshooting tree helps:
- Can the user sign in? If no, check account enabled, password, MFA, Conditional Access, tenant, and whether the user is a guest in the correct tenant.
- Does the user exist in the correct tenant? If no, invite, create, or switch directory context.
- Is the required access direct or group-based? Check direct assignments and group membership.
- Is the group the right type? Security group is the normal answer for Azure RBAC.
- Has membership or role assignment propagation completed? Azure access changes are not always instant.
Scenario: A new operator named Priya appears in Microsoft Entra ID, can sign in to the portal, but sees no subscriptions. The correct first answer is not to reset her password. Her identity exists, but she lacks Azure RBAC access to a subscription, management group, resource group, or resource. Add Priya to the approved security group or assign the minimum required role at the correct scope.
Scenario: A support team adds department = Helpdesk to new users and expects them to join a dynamic group. Some users do not appear. Check that the property is populated on the cloud object, the dynamic membership rule matches the exact attribute and value, the group is configured for dynamic user membership, and enough time has passed for membership processing.
Exam Traps
Do not choose Owner just because a user needs to view users. Directory administration and Azure resource administration are separate. A user with subscription Owner can manage Azure resources and RBAC for that subscription, but that does not automatically make the user a Global Administrator for the tenant.
Do not confuse group owner with Azure resource Owner. A group owner can manage group membership depending on group settings; Azure Owner is an RBAC role that can manage resources and delegate access at the assigned scope.
Do not assume display names are unique. Scripts and role assignments should prefer object IDs or UPNs when possible. In case studies, two users with similar names are often included to force you to use the stable identity property.
A user can sign in to the Azure portal but cannot see any subscriptions. What is the most likely missing configuration?
Which group type is the normal choice for assigning Azure RBAC permissions to many administrators?
A dynamic group rule uses the Department attribute, but new users are not joining. Which item should you check first?