Theoretical Foundation: Manage user and group properties
1. Initial Intuition
Think of an employee registry in a company. When someone is hired, you fill in their name, position, department, and extension. When this person changes departments, you update the registry. When an extension changes, you correct it. The registry needs to be always correct because other systems depend on this information to function: access control uses the department, the email system uses the position, the organizational chart uses the manager.
In Microsoft Entra ID, managing user and group properties is exactly this work of keeping data correct, complete, and up-to-date. But here, the consequence of incorrect data goes beyond a wrong organizational chart: it directly affects who has access to what.
If a user changes departments and the department attribute in Entra ID is not updated, they remain in the dynamic group of the old department and fail to enter the new department's group. With this, they lose access they should have and maintain access they shouldn't. Property quality is not cosmetic; it's operational and security-related.
2. Context
In the previous module, we saw how to create users and groups. Creation is just the beginning of the lifecycle. Property management is what sustains the correct functioning of the directory over time.
User and group properties are consumed by various Entra ID and Azure subsystems:
This means that changing a property can have cascading effects: changing the department can remove the user from a group, revoke an RBAC role, and disable access to a resource, all automatically.
3. Concept Construction
3.1 User Property Categories
User properties in Entra ID are divided into functional categories:
Identity Properties
These are the data that identify the user in the directory and authentication systems.
| Property | Description | Mutable? |
|---|---|---|
| Object ID | Azure-generated immutable unique identifier (GUID) | No |
| User Principal Name (UPN) | Primary login in user@domain.com format | Yes, carefully |
| Display Name | Name displayed in interface and email | Yes |
| Mail Nickname | Email alias, basis for Exchange addresses | Yes |
| Proxy Addresses | List of alternative email addresses | Yes |
The Object ID is the identifier that Azure uses internally for all references: RBAC assignments, group members, audit records. It never changes, even if the UPN is altered. That's why when making scripts and integrations, always use the Object ID as a reference, never the UPN.
The UPN can be changed, but this has consequences. Any system that stored the UPN as an identifier (and not the Object ID) will lose the association. Additionally, the user will need to use the new UPN to log in.
Contact Properties
| Property | Description |
|---|---|
| Primary email address (may differ from UPN) | |
| Mobile Phone | Cell phone number. Used for MFA and SSPR (Self-Service Password Reset) |
| Office Phone | Business phone |
| Street Address, City, State, Country | Physical address |
The Mobile Phone has direct security relevance: it's one of the methods used for multi-factor authentication and for password recovery via SSPR. If this field is incorrect or empty, the user won't be able to use these features.
Organizational Properties
| Property | Description | Impact on dynamic groups |
|---|---|---|
| Job Title | User's position | High |
| Department | Department | High |
| Company Name | Company name (useful in multi-tenant) | High |
| Employee ID | HR system identifier | Medium |
| Employee Type | Type of employment (Employee, Contractor, etc.) | High |
| Manager | Reference to the manager user | Medium |
| Office Location | Office location | Medium |
These are the properties most used in dynamic group rules. The quality of this data directly determines the correctness of automatic group associations.
Account Configuration Properties
| Property | Description |
|---|---|
| Account Enabled | Whether the account is active or blocked |
| Usage Location | User's country. Required for Microsoft 365 licenses |
| Password Policies | Password expiration and complexity control |
3.2 Immutable vs. Mutable Properties
3.3 Group Properties
Groups also have manageable properties, and some of them have significant impact on group behavior.
Basic Group Properties
| Property | Description | Mutable after creation? |
|---|---|---|
| Object ID | Immutable unique identifier | No |
| Display Name | Group name displayed in interface | Yes |
| Description | Description of group purpose | Yes |
| Group Type | Security or Microsoft 365 | No |
| Membership Type | Assigned, Dynamic User, or Dynamic Device | Yes (with license) |
| Mail Nickname | Addressing alias (required at creation) | Yes |
| Owners | Users with permission to manage the group | Yes |
Critical point: the Group Type (Security vs. Microsoft 365) cannot be changed after creation. If you created the wrong type of group, you need to create a new group.
The Membership Type can be changed from Assigned to Dynamic (and vice versa), but changing from Assigned to Dynamic erases all current members, replacing them with those selected by the dynamic rule. This is not automatically reversible.
Group Owners
The concept of group owner is fundamental. A group owner can:
- Add and remove members (in Assigned groups)
- Edit basic group properties
- Delete the group
An owner doesn't need to be an Entra ID administrator. This is a way to delegate management of a specific group to a regular user, like a team leader who manages their team members without having global administrative access.
A group can have multiple owners, and it's recommended to have at least two to prevent management from being blocked if the only owner leaves the company.
3.4 Extension Properties
Entra ID allows adding custom attributes to users and groups when standard properties are not sufficient. There are two mechanisms:
| Mechanism | Description | Where visible |
|---|---|---|
| Extension Attributes 1-15 | 15 legacy text attributes, inherited from on-premises AD (extensionAttribute1 to extensionAttribute15) | Portal, Graph API, PowerShell |
| Directory Extensions | Custom attributes registered via application in Graph API | Graph API (less visible in portal) |
The extensionAttributes are widely used in hybrid environments where on-premises AD already populates them with HR system data. They are also usable in dynamic group rules:
user.extensionAttribute1 -eq "Contractor"
4. Structural View
The structure shows how user properties feed dynamic group rules, and how groups connect users to RBAC assignments. It's a dependency chain where data quality at the beginning determines permission correctness at the end.
5. Practical Operation
Property Update Flow with Dynamic Group Impact
Non-obvious behavior: dynamic group re-evaluation is not instantaneous. In small tenants, it may take seconds or minutes. In large tenants with many dynamic groups, it can take hours. This means that after changing a user property, the reflection on resource access may not be immediate.
UPN Change: Impact Flow
The Object ID is the anchor. Everything Azure manages internally uses the Object ID. The problem lies in external systems (third-party applications, proprietary databases) that stored the UPN as an identifier.
6. Implementation Methods
6.1 Azure Portal
When to use: point updates, attribute verification, occasional manual adjustments.
Path for user: Microsoft Entra ID > Users > [select user] > Properties or Edit properties
Path for group: Microsoft Entra ID > Groups > [select group] > Properties or Members (for member management)
Advantages:
- Complete visualization of all attributes
- Immediate and no configuration required
- Ideal for checking current user status
Limitations:
- Doesn't scale for multiple users
- No traceability of "who changed what" beyond audit logs
Point of attention: some properties don't appear in the portal's default "Properties" tab. Properties like extensionAttribute1 to extensionAttribute15 only appear when relevant to the tenant or need to be edited via PowerShell/Graph API.
6.2 PowerShell (Microsoft Graph PowerShell SDK)
When to use: batch updates, automation, synchronization scripts.
Update user properties:
Update-MgUser -UserId "joao.silva@contoso.com" `
-Department "Development" `
-JobTitle "Senior Software Engineer" `
-MobilePhone "+55 11 99999-0000" `
-UsageLocation "BR"
Update group properties:
Update-MgGroup -GroupId "<object-id-do-grupo>" `
-Description "Access group for backend development team" `
-DisplayName "SG-Development-Backend"
Add an owner to a group:
$ownerId = (Get-MgUser -UserId "leader@contoso.com").Id
$groupId = "<object-id-do-grupo>"
New-MgGroupOwner -GroupId $groupId -DirectoryObjectId $ownerId
Batch update from CSV:
Import-Csv -Path "user_updates.csv" | ForEach-Object {
Update-MgUser -UserId $_.UPN `
-Department $_.Department `
-JobTitle $_.JobTitle
}
The CSV file would have columns: UPN, Department, JobTitle. This is one of the most efficient approaches to synchronize HR data with Entra ID without a complete integration.
6.3 Azure CLI
Update user properties:
az ad user update \
--id joao.silva@contoso.com \
--set department="Development" \
--set jobTitle="Senior Software Engineer"
Update group display:
az ad group update \
--group "SG-Developers" \
--set description="Main developers group"
Important limitation: Azure CLI has less coverage of Entra ID attributes compared to PowerShell with Graph SDK. For more specific or custom attributes, PowerShell or Graph API directly are more complete.
6.4 Microsoft Graph API
For programmatic updates with full control over attributes:
PATCH https://graph.microsoft.com/v1.0/users/joao.silva@contoso.com
Content-Type: application/json
{
"department": "Development",
"jobTitle": "Senior Software Engineer",
"mobilePhone": "+55 11 99999-0000",
"officeLocation": "São Paulo",
"usageLocation": "BR"
}
To update extensionAttributes:
PATCH https://graph.microsoft.com/v1.0/users/joao.silva@contoso.com
Content-Type: application/json
{
"onPremisesExtensionAttributes": {
"extensionAttribute1": "Contractor",
"extensionAttribute2": "Project-Alpha"
}
}
PATCH advantage: the PATCH method updates only the specified properties. Properties not mentioned in the request are preserved. This is important to avoid accidentally deleting data.
6.5 Dynamic Group Rules: Syntax and Management
The dynamic membership rule is a property of the group itself. It can be defined at creation or changed later.
Basic rule syntax:
user.ATTRIBUTE OPERATOR "VALUE"
Rule examples:
# Everyone from IT department
user.department -eq "IT"
# All managers
user.jobTitle -contains "Manager"
# Active employees from SP or RJ
(user.state -eq "SP" -or user.state -eq "RJ") -and user.accountEnabled -eq true
# Excludes guests
user.userType -eq "Member"
# Based on extensionAttribute
user.extensionAttribute1 -eq "Contractor" -and user.department -eq "IT"
Available operators:
| Operator | Description | Example |
|---|---|---|
-eq | Equal to | user.department -eq "IT" |
-ne | Not equal to | user.userType -ne "Guest" |
-contains | Contains substring | user.jobTitle -contains "Dev" |
-notContains | Does not contain | user.jobTitle -notContains "Intern" |
-startsWith | Starts with | user.displayName -startsWith "A" |
-match | Regular expression | user.mail -match ".*@contoso\\.com" |
-in | Value in list | user.department -in ["IT", "Eng"] |
-notIn | Value not in list | user.department -notIn ["HR"] |
To change the rule of an existing dynamic group via PowerShell:
Update-MgGroup -GroupId "<object-id>" `
-MembershipRule '(user.department -eq "Development") -and (user.accountEnabled -eq true)' `
-MembershipRuleProcessingState "On"
The MembershipRuleProcessingState parameter can be "On" or "Paused". Pausing processing is useful during migrations or when you want to prevent automatic changes from happening while making batch adjustments.
7. Control and Security
Who Can Edit Properties
There are two levels of control over who can edit properties:
Administrative role level (Entra ID roles):
| Role | Can edit user properties | Can edit group properties |
|---|---|---|
| Global Administrator | Everything | Everything |
| User Administrator | Yes (except other higher-level admins) | Yes |
| Groups Administrator | No (users) | Yes |
| Helpdesk Administrator | Basic properties and password of non-admins | No |
Group owner level:
A group owner can edit basic group properties (name, description) and manage members, without needing any administrative role in Entra ID. This is the basis of group management delegation.
Change Auditing
Every property change generates an entry in the Entra ID Audit Log with:
- Who made the change (actor)
- Which object was changed (target)
- Which property was changed
- Previous and new value
To query user property changes:
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Update user'" -Top 50
This returns the last 50 user updates with all details.
Self-Service: What Users Themselves Can Edit
By default, regular users can edit some of their own properties through the MyAccount portal (myaccount.microsoft.com):
- Profile photo
- Mobile phone number (relevant for MFA/SSPR)
- Alternative email address
- Security information
The administrator can restrict which properties users can edit themselves, via tenant settings in Microsoft Entra ID > User settings.
8. Decision Making
When to update properties manually vs. automated?
| Situation | Best approach | Reason |
|---|---|---|
| 1 to 5 users, immediate urgency | Azure Portal | Fast, no configuration |
| 10 to 100 users, data in spreadsheet | PowerShell script with CSV | Scalable, auditable |
| Recurring synchronization with HR system | Graph API or SCIM via Entra Connect | Automatic, no manual intervention |
| Hybrid environment (AD on-premises) | Edit in AD on-premises | Authoritative source is local AD; edits in Entra ID will be overwritten on next sync |
| Custom extension attributes | PowerShell or Graph API | Portal doesn't expose all extensionAttributes |
When to change a group's membership type?
| Situation | Decision | Consequence to consider |
|---|---|---|
| Assigned group with clear pattern in attributes | Convert to Dynamic | Current members will be removed and replaced by the rule |
| Dynamic group with many exceptions to the rule | Convert to Assigned | Dynamic rule is deleted; members that the rule selected remain as direct members |
| Dynamic group doesn't reflect reality due to bad data | Pause processing, fix data, reactivate | Pausing avoids incorrect removals while data is adjusted |
9. Best Practices
Keep Object ID as canonical reference: scripts, integrations and external systems should always store and use the Object ID, never the UPN or Display Name, which are mutable.
Define ownership for all groups: groups without owners become orphaned. When the group creator leaves the company, no one has explicit authority to manage the group without escalation to a Global Administrator. Always define at least two owners.
Document the purpose of each group in the Description: the group's description property is often ignored. In environments with hundreds of groups, a clear description like "Read access to production log Storage Account - Created in 2024-03 by infrastructure team" is much more valuable than a name like "SG-Storage-Prod-Read".
Data quality before dynamic groups: before creating dynamic groups based on department or jobTitle, audit existing values. Inconsistent data (e.g., "IT", "it", "Information Technology", "I.T." for the same department) will make the dynamic group work incorrectly.
Standardize attribute values: create and communicate a dictionary of accepted values for fields like department, jobTitle, employeeType, state. This is especially important when multiple administrators or HR systems populate these fields.
Don't directly edit attributes synchronized from on-premises AD: in hybrid environments, synchronized attributes are owned by the local AD. Editing these attributes directly in the Azure portal results in a warning and the change will be overwritten on the next synchronization.
10. Common Errors
Editing synchronized user properties through Azure portal in hybrid environment
In environments with Entra Connect, attributes like department, displayName, manager are managed in on-premises AD. If an administrator edits these fields through the Azure portal, the portal allows the edit (with a warning), but on the next synchronization round (default: every 30 minutes), the on-premises AD value overwrites the edit. The administrator thinks they made the change, but it will be reverted.
Converting Assigned group to Dynamic without notifying current members
When changing the Membership Type to Dynamic, all current members are removed before the rule is applied. If the rule has any problem (like bad data in attributes), the group may remain empty for hours. This can revoke critical access without warning.
Creating dynamic rule without validating with real data
The portal interface offers a rule validation tool: you can test the rule against specific users to see if they would be included or excluded. Many administrators create the rule directly without using this resource and only notice the error when users complain about denied access.
Removing the only owner of a group
If a group has only one owner and that owner is removed or disabled, the group becomes ownerless. Group members continue with their access, but no one can manage the group without intervention from a User Administrator or Global Administrator.
Changing UPN without checking external dependencies
Before changing a UPN, it's necessary to audit if there are external systems (SaaS applications, internal databases, ITSM tools) that store the UPN as a user key. A UPN change in these systems can break integrations silently.
Confusing "Member" (user type) with "Member" (group membership type)
The term "Member" appears in two distinct contexts in Entra ID: a user's userType can be "Member" (internal employee) or "Guest" (external invitee). And a user's association to a group can be as "Member" (access to group resources) or as "Owner" (can manage the group). These are completely different concepts with the same name.
11. Operation and Maintenance
Identification of Outdated Properties
Over time, user properties become outdated without anyone noticing. Some important regular checks:
Users with empty usageLocation who may have licenses denied:
Get-MgUser -Filter "usageLocation eq null" -All `
-Property "displayName,userPrincipalName,usageLocation"
Users without filled department (problematic for dynamic groups):
Get-MgUser -Filter "department eq null" -All `
-Property "displayName,userPrincipalName,department"
Access Reviews
Entra ID (with P2 license) offers Access Reviews: periodic and automated reviews where group owners or managers are notified to confirm if group members should still have that access. If no action is taken within the deadline, the system can automatically remove access (configurable behavior).
This is the most scalable way to maintain group membership quality over time, especially for groups with access to sensitive resources.
Dynamic Group Monitoring
To check the processing status of a dynamic group:
Get-MgGroup -GroupId "<object-id>" `
-Property "displayName,membershipRule,membershipRuleProcessingState,onPremisesLastSyncDateTime"
If membershipRuleProcessingState is "Paused", the group is not being automatically updated, which may indicate a problem or a forgotten intentional action.
12. Integration and Automation
HR System Synchronization via SCIM
The SCIM (System for Cross-domain Identity Management) protocol allows HR systems like Workday, SAP SuccessFactors and BambooHR to send attribute updates directly to Entra ID when an employee changes position, department or manager.
This flow eliminates the need for any manual administrator intervention when an employee changes areas.
Automation via Logic Apps or Power Automate
For simpler scenarios or where there's no native SCIM integration, Azure Logic Apps and Power Automate allow creating flows that:
- Read an Excel or SharePoint spreadsheet with employee data
- Compare with current Entra ID data via Graph API
- Automatically update differences
Webhooks and Notifications via Graph API Change Notifications
The Graph API supports subscriptions (change subscriptions): you register an HTTP endpoint and Azure notifies that endpoint whenever a user or group is created, updated or deleted. This allows external systems to react to Entra ID changes in near real-time.
POST https://graph.microsoft.com/v1.0/subscriptions
{
"changeType": "updated",
"notificationUrl": "https://your-system.contoso.com/webhook",
"resource": "users",
"expirationDateTime": "2025-04-01T00:00:00Z"
}
13. Final Summary
Essential points:
- User and group properties are not just metadata: they control dynamic group memberships, license eligibility, conditional access and automation flows.
- The Object ID is the immutable and reliable identifier. The UPN can change; the Object ID never changes.
- The Group Type (Security vs. M365) is immutable after creation. The Membership Type can be changed, but converts all members.
- The group owners property allows delegating management without granting global administrative roles.
Critical differences:
- Hybrid environment: attributes synchronized from on-premises AD must be edited in local AD, not in the Azure portal. Direct edits will be overwritten.
- Dynamic groups depend on attribute quality. Inconsistent data generates incorrect associations.
- Pause vs. Convert: pausing a dynamic group preserves current members; converting from Dynamic to Assigned also preserves. Converting from Assigned to Dynamic deletes all members.
- "Member" as userType (internal vs. guest) is different from "Member" as group role (access vs. ownership).
What needs to be remembered:
- Always validate dynamic rules before applying in production, using the portal's validation tool.
- Define at least two owners per group to avoid orphaned groups.
- Fill
usageLocationand organizational attributes at user creation time. - In scripts and integrations, always use Object ID as reference to user or group, never UPN or Display Name.
- Changes to dynamic groups can take hours to propagate in large tenants. Plan adequate change windows.
- Check the Audit Log to track who changed what and when, especially before investigating access problems.