Theoretical Foundation: Create users and groups
1. Initial Intuition​
Imagine a company with hundreds of employees. Each person needs to access different systems: some need to read reports, others need to create virtual machines, others need only to view invoices. Without an organized way to control who is who and what each one can do, security and operations become unfeasible.
In Microsoft Azure, Microsoft Entra ID (formerly called Azure Active Directory, or Azure AD) is the service that solves exactly this problem. It is the Microsoft cloud identity directory: the place where you register who people are, organize them into groups, and define what each one can access.
A user in Entra ID represents an individual identity. It can be a real person (an employee), but it can also be a service account used by an application. A group is a collection of users (and potentially other groups) treated as a unit, which allows assigning permissions and policies collectively instead of individually.
The central logic is simple: instead of saying "João can access VM-Production," you say "the Developers group can access VM-Production" and then add João to the group. When a new developer joins the company, just add them to the group. When they leave, just remove them. The permissions don't need to change.
2. Context​
Entra ID occupies a central position in the Azure ecosystem. Virtually every resource, service, and policy depends on it to know who is acting and what that entity is allowed to do.
Entra ID is the identity provider for:
- The Azure portal and all Azure services
- Microsoft 365 (Teams, Exchange, SharePoint)
- External SaaS applications via SSO (Single Sign-On)
- Your organization's own applications
This means that learning to create and manage users and groups in Entra ID is not just about AZ-104: it's about controlling access to practically everything in the Microsoft ecosystem.
3. Building the Concepts​
3.1 The Tenant​
Before talking about users and groups, you need to understand the tenant. When an organization subscribes to Azure or Microsoft 365, Azure automatically creates a tenant dedicated to it. The tenant is an isolated instance of Entra ID that belongs exclusively to that organization.
Each tenant has a default domain name in the format organizationname.onmicrosoft.com. It's possible to add custom domains, like contoso.com, so users have more friendly addresses.
The tenant is the container of everything: all users, groups, applications, and security configurations live within a specific tenant.
3.2 User Types​
Not all users in Entra ID are equal. There are three main categories:
| Type | Description | Usage example |
|---|---|---|
| Member | User created directly in the tenant. Has default directory access. | Company employee |
| Guest | User from outside the tenant, invited to collaborate. Directory access is restricted by default. | External partner, consultant |
| Synchronized | User originated from on-premises Active Directory, synchronized via Azure AD Connect / Entra Connect. Not created directly in Azure. | Employee in hybrid environment |
The difference between member and guest goes beyond the name. Member users, by default, can read information from other users and groups in the directory. Guest users have much more restricted read permissions, which is a security measure for external partners.
3.3 Essential User Properties​
When creating a user, the most important properties are:
- User Principal Name (UPN): the user's unique identifier in the format
user@domain.com. Works as the main "login". Example:joao.silva@contoso.com. - Display Name: the name that appears in the interface. Example: "João Silva".
- Password: defined at creation time. Can be automatically generated or manually defined. The user can be forced to change it on first access.
- Usage Location: the user's country of location. This field is required to assign Microsoft 365 licenses, as some services are not available in all countries.
- Job Title, Department, Manager: organizational metadata. Don't control access, but are used for organization, filters, and reports.
3.4 Group Types​
There are two types of groups in Entra ID, and the distinction is fundamental:
| Type | What it's for | Where it's used |
|---|---|---|
| Security Group | Control resource access, assign permissions, apply policies | RBAC in Azure, conditional access policies, application access |
| Microsoft 365 Group | Collaboration between people | Exchange (shared mailbox), SharePoint, Teams, Planner |
For AZ-104 and for controlling access to Azure resources, the relevant type is the Security Group. Microsoft 365 Group is more relevant for productivity and collaboration scenarios.
3.5 Group Membership Types​
This is one of the most important distinctions for the exam and daily operations:
| Membership Type | How it works | Required license |
|---|---|---|
| Assigned | Administrator manually adds and removes each member | Free (Entra ID Free) |
| Dynamic User | Members are automatically added/removed based on user attributes | Entra ID P1 or P2 |
| Dynamic Device | Members are devices, automatically added based on device attributes | Entra ID P1 or P2 |
Dynamic groups are extremely powerful. You define a membership rule like:
user.department -eq "Engineering"
From that moment on, any user whose department attribute is "Engineering" automatically joins the group. When someone changes departments, they automatically leave. The administrator doesn't need to do anything manually.
Another rule example:
user.jobTitle -contains "Developer" -and user.accountEnabled -eq true
This rule adds to the group only users with "Developer" in their job title and with an active account.
3.6 Nested Groups​
Entra ID allows a group to be a member of another group. This is called nested groups.
Important note: permission inheritance via nested groups works for RBAC in Azure, but doesn't work for all functionalities. For example, when assigning Microsoft 365 licenses based on groups, nested groups are not supported; only direct members receive the license.
4. Structural View​
The general access flow works like this:
- A user is created or synchronized in Entra ID
- The user is added to one or more groups
- Groups receive RBAC roles (like "Contributor" or "Reader") over Azure resources
- The user inherits permissions from the groups they belong to
5. Practical Operation​
User lifecycle​
Critical point: when a user is deleted, they stay in the Entra ID "recycle bin" for 30 days. During this period, it's possible to restore them with all their attributes, group associations, and role assignments. After 30 days, the deletion becomes permanent.
Important behaviors​
-
Disable vs. Delete: disabling an account (
accountEnabled: false) blocks login immediately, but preserves the user and all their associations. It's the recommended practice when an employee leaves temporarily or when you want to block access without losing the record. -
Password reset: administrators with the role of "User Administrator" or higher can reset passwords of other users, except for Global Administrators (for that, you need to also be a Global Administrator).
-
License assignment: Microsoft 365 licenses can be assigned directly to the user or via group (group-based licensing). Assignment via group is more scalable and is the recommended approach for larger environments.
6. Implementation Methods​
6.1 Azure Portal (Graphical Interface)​
When to use: one-time tasks, learning, visual verification, creating few users.
Portal path: Microsoft Entra ID > Users > New user or Microsoft Entra ID > Groups > New group
Advantages:
- Visual and intuitive
- Immediate feedback on configuration errors
- Ideal for exploration and verification
Limitations:
- Doesn't scale for many users
- Not repeatable or auditable like code
6.2 PowerShell (Microsoft Graph PowerShell SDK)​
When to use: batch creation, automation, provisioning scripts, recurring tasks.
The relevant module is the Microsoft Graph PowerShell SDK, which replaced the AzureAD module (discontinued).
User creation example:
$PasswordProfile = @{
Password = 'TempPassword@123'
ForceChangePasswordNextSignIn = $true
}
New-MgUser `
-DisplayName "João Silva" `
-UserPrincipalName "joao.silva@contoso.com" `
-AccountEnabled `
-PasswordProfile $PasswordProfile `
-MailNickname "joao.silva" `
-UsageLocation "BR"
Group creation example:
New-MgGroup `
-DisplayName "Developers" `
-MailEnabled:$false `
-SecurityEnabled `
-MailNickname "developers"
Adding member to group example:
$userId = (Get-MgUser -UserId "joao.silva@contoso.com").Id
$groupId = (Get-MgGroup -Filter "displayName eq 'Developers'").Id
New-MgGroupMember -GroupId $groupId -DirectoryObjectId $userId
Advantages:
- Scriptable and repeatable
- Ideal for batch provisioning
- Can be integrated into CI/CD pipelines
Limitations:
- Requires authentication and permissions in Graph API
- Learning curve for the SDK
6.3 Azure CLI​
When to use: environments where PowerShell is not preferred, shell scripts on Linux/macOS, bash-based pipelines.
# Create user
az ad user create \
--display-name "João Silva" \
--user-principal-name joao.silva@contoso.com \
--password "TempPassword@123" \
--force-change-password-next-sign-in true
# Create group
az ad group create \
--display-name "Developers" \
--mail-nickname "developers"
# Add member to group
az ad group member add \
--group "Developers" \
--member-id <user-object-id>
Advantages:
- Simple and direct syntax
- Great for bash scripts and DevOps pipelines
Limitations:
- Less expressive than PowerShell for complex logic
6.4 Microsoft Graph API (REST)​
When to use: system integration, applications that need to create or manage users programmatically, custom automation.
POST https://graph.microsoft.com/v1.0/users
Content-Type: application/json
{
"accountEnabled": true,
"displayName": "João Silva",
"mailNickname": "joao.silva",
"userPrincipalName": "joao.silva@contoso.com",
"passwordProfile": {
"forceChangePasswordNextSignIn": true,
"password": "TempPassword@123"
},
"usageLocation": "BR"
}
Advantages:
- Any programming language can be used
- Maximum flexibility
- Foundation of all other tools (portal, CLI, and PowerShell use Graph internally)
Limitations:
- Requires managing authentication tokens
- More verbose for simple tasks
6.5 Bulk Import (Bulk Operations)​
The Azure portal allows creating users in bulk via CSV file upload. The path is: Microsoft Entra ID > Users > Bulk operations > Bulk create.
The CSV file must follow a specific template provided by the portal. This is a good option for initial onboarding of many users without needing to write scripts.
7. Control and Security​
Relevant Administrative Roles​
To create and manage users and groups, the administrator needs to have appropriate roles in Entra ID. The main ones are:
| Role | What it can do |
|---|---|
| Global Administrator | Everything. Unrestricted access to Entra ID and all Microsoft services. |
| User Administrator | Create, edit, delete users and groups. Reset passwords (except Global Admins). |
| Groups Administrator | Create and manage groups, including dynamic groups. |
| Guest Inviter | Invite external users (guests) to the tenant. |
| Helpdesk Administrator | Reset passwords for non-administrator users. |
These are Entra ID roles (directory roles), different from Azure RBAC roles (which control access to resources like VMs and storage). The two systems coexist and are complementary.
Security Best Practices​
- Principle of least privilege: assign only the minimum role necessary for each administrator. A helpdesk that only resets passwords doesn't need to be a full User Administrator.
- Separate administrative accounts: administrators should have a regular account for daily use and a separate account with elevated privileges for administrative tasks.
- Mandatory MFA for admins: accounts with administrative roles should always have multi-factor authentication enabled.
- Guest account monitoring: guest users accumulate over time. Periodically review which guests still need access.
8. Decision Making​
Which type of group membership to use?​
| Situation | Best choice | Reason |
|---|---|---|
| Small and stable team | Assigned | Simple, no need for P1 license |
| Many users with consistent attributes (department, job title) | Dynamic User | Automation eliminates manual errors and operational overhead |
| Need to control devices | Dynamic Device | Allows policies based on device characteristics |
| User attributes are not reliable or standardized | Assigned | Dynamic groups depend on the quality of attribute data |
Which tool to use for creating users?​
| Situation | Best choice | Reason |
|---|---|---|
| Create 1 to 5 users occasionally | Azure Portal | Quick and visual |
| Onboarding 20+ users at once | CSV Bulk Upload or PowerShell | Scales without excessive effort |
| Automated and recurring provisioning | PowerShell with Graph SDK or Graph API | Repeatable, versionable, integrable |
| HR system integration | Graph API | Maximum flexibility for integration |
| Linux/macOS environment or bash pipeline | Azure CLI | More natural syntax in these environments |
9. Best Practices​
Consistent naming: define and document naming conventions for UPNs and groups before starting. Example UPN pattern: firstname.lastname@contoso.com. For groups: SG-[Role]-[Scope], like SG-Devs-Production.
Use groups for everything: never assign permissions directly to individual users if you can use groups. This makes access management much more scalable and auditable.
Fill user attributes: fields like department, jobTitle and manager seem optional, but are essential for dynamic groups, security reports and access reviews. Invest in data quality from the beginning.
Always define Usage Location: it's easy to forget this field, but it blocks Microsoft 365 license assignment. Configure it at creation time.
Security groups vs. M365 Groups: don't mix purposes. Use Security Groups for access control. Use Microsoft 365 Groups for collaboration. Using an M365 Group to assign RBAC roles works technically, but creates confusion and is a bad practice.
Review group members regularly: especially groups with privileged access. Entra ID offers the Access Reviews feature (periodic and automated access reviews) for this.
10. Common Mistakes​
Confusing Entra ID roles with Azure RBAC roles: they are two different systems. The "Owner" role on an Azure subscription doesn't make someone a Global Administrator of Entra ID. And being Global Administrator doesn't automatically grant access to Azure resources like VMs or Storage Accounts.
Forgetting Usage Location when creating users: the user is created successfully, but any subsequent attempt to assign a Microsoft 365 license fails with an error that can confuse those unfamiliar with this requirement.
Relying on nested groups for licensing: as mentioned, group-based licensing doesn't propagate to members of nested groups. Only direct members receive the license. Administrators create group hierarchies thinking inheritance will work, and end up with unlicensed users.
Creating dynamic groups with incorrect or poorly formatted attributes: a poorly written rule can include incorrect users or not include anyone. Always use the "Validate Rules" button available in the dynamic group creation interface to test the rule before saving.
Deleting users instead of disabling them: when an employee leaves, the tendency is to delete the account immediately. The problem is this removes the user from all groups and all RBAC assignments. If future investigation or auditing is needed, access trails become harder to reconstruct. Best practice is to disable the account first, wait for the necessary retention period and only then delete.
Not configuring temporary password properly: when creating a user with the "Auto-generate password" option and not checking "Require password change at first login", the user receives a fixed password that never expires until manually changed. Always force password change at first login.
11. Operation and Maintenance​
Monitoring and Auditing​
Every action of creating, modifying and deleting users and groups generates records in the Entra ID Audit Logs. The portal path is: Microsoft Entra ID > Monitoring > Audit logs.
The logs record: who performed the action, what was done, when and on which object. These logs are retained for 30 days in the free plan and up to 90 days with Entra ID P1/P2. For longer retention, logs must be exported to a Log Analytics Workspace or Storage Account.
The Sign-in logs (also in Monitoring) records each login attempt: successes, failures, location, device used. It's essential for detecting suspicious access.
Important Limits​
| Item | Limit |
|---|---|
| Users per tenant | 300,000 (default, can be increased) |
| Groups per tenant | 300,000 |
| Members per group (assigned) | No documented practical limit |
| Dynamic groups per tenant | 5,000 (with P1/P2 license) |
| Groups a user can be member of | 2,048 (token limit) |
| Objects in recycle bin | 30 days retention |
The 2,048 groups per user limit is particularly important in large environments. When a user is a member of many groups, the authentication token can become too large, causing failures in applications that validate group members. This is a real problem in organizations with very granular group architectures.
12. Integration and Automation​
Synchronization with On-Premises Active Directory​
In hybrid environments (where there's a local Active Directory in addition to Entra ID), Microsoft Entra Connect (formerly Azure AD Connect) synchronizes users, groups and attributes from on-premises AD to Entra ID.
In this scenario, synchronized users are managed in on-premises AD, not directly in Entra ID. Any changes (name, department, password) must be made in local AD and will be synchronized to Entra ID.
Automated Provisioning via SCIM​
For external SaaS applications, Entra ID supports the SCIM (System for Cross-domain Identity Management) protocol for automatic provisioning. When a user is added to a specific group, Entra ID automatically creates an account in the target application. When removed, the account is deactivated.
Integration with Azure DevOps and GitHub​
Entra ID Security Groups can be linked to Azure DevOps and GitHub Enterprise organizations, centralizing access control to repositories and pipelines in the same identity managed in Entra ID.
Lifecycle Workflows​
Entra ID (with Governance license) offers Lifecycle Workflows: automations that execute predefined tasks based on user lifecycle events, such as account creation, department change and termination. Example: when a user is hired (employeeHireDate attribute arrives), the system automatically creates the account, assigns to the correct group, assigns licenses and sends welcome email.
13. Final Summary​
Essential concepts:
- Microsoft Entra ID is Azure's central identity service. All access goes through it.
- A tenant is the isolated instance of Entra ID for an organization.
- Users can be members (created in the tenant), guests (external) or synchronized (coming from on-premises AD).
- The UPN is the user's unique identifier. Usage Location is mandatory for license assignment.
- Groups can be Security type (for access control) or Microsoft 365 (for collaboration). For AZ-104, the focus is on Security Groups.
- Group membership can be Assigned (manual) or Dynamic (automatic via rules). Dynamic groups require Entra ID P1 or P2 license.
Critical differences:
- Entra ID roles control who can administer the directory (create users, reset passwords). Azure RBAC roles control who can act on resources (create VMs, access storage). They are separate systems.
- Disabling an account blocks login but preserves the object. Deleting removes the account (with 30-day restoration window).
- Nested groups propagate RBAC permissions, but don't propagate Microsoft 365 licenses.
- Assigned groups are free. Dynamic groups require Entra ID P1 or P2.
What needs to be remembered:
- Always assign permissions to groups, never directly to individual users.
- Dynamic groups depend on the quality of user attributes. Dirty data generates wrong groups.
- Deleted users remain recoverable for 30 days and auditable for 30 days (90 with P1/P2).
- The 2,048 groups per user limit can cause authentication failures in very granular environments.
- In hybrid environments, synchronized users are managed in on-premises AD, not in the Azure portal.