๐ Recipe ยท Entra ID & Identity
Bulk Assign Custom Security Attributes to Users in Entra ID
Tag users matching an email-domain filter with a Custom Security Attribute value for governance and Conditional Access scoping
Complexity
Intermediate
Impact
identity-governance + bulk-operation + conditional-access + attribute-based-access-control
Context
Why This Matters
Custom Security Attributes (CSAs) in Microsoft Entra ID are key-value pairs you define at the tenant level to classify directory objects (users, service principals, devices). They are commonly used to drive Conditional Access scoping, ABAC on Azure resources, license governance, and HR reporting.
A frequent operational task is the bulk assignment of a CSA value to a cohort of users โ for example, tagging every employee of a specific domain with Accounts > UserType = Employee so they fall under the correct Conditional Access policy or ABAC role assignment. Doing this one user at a time in the Entra portal is tedious and error-prone; this recipe shows the three reliable paths.
Run this recipe whenever you:
- Onboard a new acquired domain and need to tag its users with a classification value.
- Roll out a new CSA set and need to backfill existing users.
- Periodically reconcile the CSA against a source of truth (HRIS, domain, group membership).
Expected Outcomes
What you will have
- Every user matching the target filter (e.g. mail ending in
@contoso.com) carries the specified Custom Security Attribute value. - A reconciliation report showing users that already had the attribute vs. users who were newly assigned.
- An audit trail of
PATCH /beta/users/{id}calls against the directory that can be reviewed in the Entra audit log. - Confidence that Conditional Access policies, ABAC roles, or reports keyed on that attribute correctly scope the tagged cohort.
Risks & Considerations
Warnings & considerations
- Privileged role required. Assigning CSA values is gated by the Attribute Assignment Administrator role (or equivalent custom role) โ Global Admin alone is not sufficient. The operator must be explicitly granted this role before the PATCH calls will succeed.
- Beta endpoint. Custom Security Attribute read/write currently lives on
/beta. The payload shape may evolve when it moves tov1.0. - PATCH is a merge, not a replace. Sending a partial
customSecurityAttributespayload merges into the existing attribute set. To remove a value, sendnullexplicitly. - Predefined values. If the attribute is configured with
usePreDefinedValuesOnly = true, you must use anisActiveallowed value โ free-text will fail. - Advanced queries.
endsWith()requires theConsistencyLevel: eventualheader and$count=true. Without them, the filter returns HTTP 400. - Do NOT run the bulk assignment without first dry-running the filter and reviewing the user list. A typo in the domain filter can easily tag the wrong cohort.
- Compliance. CSAs may contain data subject to internal governance (e.g. employment classification). Confirm who can read the attribute set before populating it โ visibility is governed by attribute-set-level permissions.
Required Permissions
| Permission | Why It's Needed |
|---|---|
| CustomSecAttributeDefinition.Read.All | Read the CSA definitions and allowed values to validate the attribute name and target value before assignment. |
| CustomSecAttributeAssignment.ReadWrite.All | Read and write Custom Security Attribute values on user objects. |
| User.Read.All | Query users by mail filter to build the target cohort. |
| Attribute Assignment Administrator (directory role) | Azure role required in addition to Graph scopes โ the signed-in principal must hold this role to persist CSA writes. |
The fastest way to get this done โ just ask Dex. Copy the prompt below and paste it into your Dex conversation.
For IT Admins
Paste into Dex CoAdmin