Microsoft Entra ID Users, Groups, and Applications

On this page

Microsoft Entra ID (formerly Azure AD) underpins identity, access, and resource management for cloud-connected enterprises. For developers and directory engineers, mastering the interplay of users, groups, and applications—especially as organizations evolve from classic Active Directory, mix in LDAP-based tools, or scale to cloud-only architectures—is essential. This article demystifies the technical realities, assignment patterns, edge cases, and operational boundaries that shape identity integrations and reliable access management in Microsoft Entra ID.

Microsoft Entra ID Object Types: Users, Groups, Applications

At its core, Microsoft Entra ID operates as a directory service, with three main object types:

Users: Unique identities for people (employees, guests, service accounts). Users can be created natively in Entra ID, synchronized from on-premises AD, or added as guest/external users for partner collaboration.
Groups: Collections of users (and sometimes devices) managed as a unit. Groups enable bulk access control, role assignment, and easier policy administration.
Enterprise Applications: Registered apps and resources (SaaS, custom, gallery apps) that require identity and access management. These map to service principals and often correspond to applications users sign into.

In classical LDAP or AD terms, users and groups map closely to user and group objects; applications typically correspond to service objects or entries but with richer access/consent models in Entra ID.

Understanding Group Types and Membership Models

Group Types

There are two primary group types in Entra ID:

Security Groups: Designed for access management. Use cases include granting permission to applications, managing policy scope, or controlling resource access.
Microsoft 365 Groups: Purpose-built for collaborative scenarios (e.g., Teams, Outlook groups), providing shared mailboxes and calendars in addition to traditional group capabilities.

Both types can be used for application access assignments, but their collaboration features and compatibility differ.

Membership Models

Groups support two membership models:

Assigned (Static) Membership: Admins explicitly add and remove members. Suitable where group membership changes infrequently or requires tight administrative control.
Dynamic Membership: Membership is automatically evaluated based on user or device attributes (e.g., department, location). For example, a dynamic group could include all users with jobTitle = Engineer. Dynamic membership requires Entra ID P1 or P2 licensing.

Nested Groups—the inclusion of one group as a member of another—are supported as an organizational model. However, and crucially, nested membership comes with strict limitations (explored below).

Nested Group Mechanics and Limitations

Nested groups do not function the same way for all access assignments. Specifically:

For most application assignments, only direct group members gain access. If Group A is assigned to an enterprise app and Group B is a member of Group A, users in Group B will not automatically inherit access to the app.
Nested memberships can be used for organizational models but must be treated cautiously when access control is required.

Example Scenario: Dynamic Group for Attribute-Based Membership

A dynamic group can be set up to auto-populate all users with jobTitle = "Engineer". If this group is assigned to an app, only direct members—those who match the rule—receive access.

Example Scenario: Nested Group Assignment Limitation

If "All Contractors" is a member of "All External Users," and only "All External Users" is assigned to an application, individual members of "All Contractors" will not be granted access—unless they are also directly included in "All External Users".

Assigning Applications to Users and Groups: Rules and Limitations

How Assignment Works

Enterprise applications in Entra ID support assignment of access rights to either users or groups. Assigning:

A user: Direct, straightforward—user receives access immediately.
A group: All direct user members gain access.

Assignment does not cascade through nested groups—only direct membership counts.

Role and Permission Requirements

To manage application assignments, an admin must have suitable RBAC (role-based access control) permissions:

Groups Administrator: Can manage group membership fully.
User Administrator: Manages user objects and their group memberships.
Application Administrator / Cloud Application Administrator: Controls app registration and assignment.

Admins lacking the correct role cannot perform related group or user management actions.

Licensing and Feature Access

Assigning groups to applications requires Microsoft Entra ID P1 or P2 licenses. Standard editions do not support group assignment to apps.
Dynamic groups and certain advanced features also require higher-tier licenses.

Application Assignment and Nested Groups: Edge Case

If a group with nested groups is assigned to an application, only direct members are granted access. Members who gain group membership solely via nesting will not see the application assigned and will not have access—even if the logical intent was to include all nested users.

Group Claims, Tokens, and Application Access: What the App Really Sees

How Group Membership Appears to Applications

When users sign into integrated applications, Entra ID emits security tokens (OpenID Connect, OAuth 2.0, or SAML). These tokens can include "group claims"—lists of group object IDs the user is a (direct) member of.

By default, only direct group memberships are included in the token.
Nested or transitive group memberships are not included in group claims.

Token Claim Limits and Overages

Tokens have limits on how many group IDs can be embedded in the groups claim:

JWT tokens: Maximum 200 group IDs
SAML tokens: Maximum 150 group IDs

If a user is a member of more groups, the token instead includes an "overage claim." Applications must then query Microsoft Graph separately to learn about full group membership.

Example: Group Claim Overages in Practice

A user who is a member of 250 groups tries to log into an app expecting access based on group claims. The token does not list every group ID; instead, the application must call the Graph API for a complete list. This pattern is not always supported in custom or legacy apps, leading to unexpected authorization failures.

Special Considerations: Licensing, Roles, and Directory Integration

Administrative Boundaries

Only admins with the appropriate Entra ID roles can manage user, group, or application objects. Lacking the role denies access to relevant operations—even for Global Administrators in certain scoped scenarios.

Licensing Realities

Group-based app assignment and dynamic group features require at least Entra ID P1/P2 licensing. Without correct licenses, options may be missing in the portal or fail silently.

Directory and LDAP Integration Patterns

Entra ID supports provisioning users and groups to certain LDAP directories using the on-premises provisioning agent.
Not all features (especially group types or dynamic group logic) map cleanly to LDAP schemas or non-Microsoft directories. Assignment limits and group claim distinctions are often lost in translation; design group structures with this in mind for hybrid or exporting scenarios.

Common Pitfalls, Misconceptions, and Real-World Scenarios

Nested Group Myths

Misconception: Assigning a group to an application grants access to all users in its child (nested) groups.
Reality: Only direct members of the assigned group gain access. This leads to denials when nested groups were presumed to be included.

Group Claim Surprises

Misconception: Application tokens always include full group membership for the user.
Reality: Tokens have strict group claim limits and do not include nested memberships. The application must be explicitly coded to resolve full memberships using Microsoft Graph if an overage claim is present.

Role Confusion

Misconception: Any admin can perform all user, group, or app assignments.
Reality: Only specific Entra built-in roles permit certain management tasks. Delegation and least-privilege assignment often block actions for users without the exact role.

Scenario: User Denied Application Access Despite Group Assignment

An administrator assigns Group A to an app. User X is a member of Group B, which is a nested member of Group A. User X is denied access because only direct members of Group A are considered during assignment.

Scenario: Administrator Unable to Manage Group

A helpdesk admin tries to add a user to a dynamic group but lacks the "Groups Administrator" role. Management is denied; only users with permission can perform this operation.

Best Practices and Troubleshooting Guidance

When planning access using groups, assign groups directly to apps; avoid relying on nested group memberships for application access.
For dynamic populations, use dynamic group rules but confirm licensing supports the feature.
For large organizations, monitor group claim counts in tokens to prevent silent authorization breakdowns.
Always verify role permissions before delegating group/app management to administrative users.
In hybrid environments or when exporting to LDAP, prefer security groups with static membership for robust cross-directory behavior.

Sources:

https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/assign-user-or-group-access-portal
https://learn.microsoft.com/en-us/entra/fundamentals/how-to-manage-groups
https://learn.microsoft.com/en-us/entra/identity/
https://learn.microsoft.com/en-us/security/zero-trust/develop/configure-tokens-group-claims-app-roles
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
https://learn.microsoft.com/en-us/entra/identity/users/groups-saasapps
https://learn.microsoft.com/en-us/entra/identity/app-provisioning/on-premises-ldap-connector-configure
https://learn.microsoft.com/en-us/entra/architecture/auth-ldap