How to Configure Microsoft Entra ID Custom Security Attributes for ABAC (Attribute-Based Access Control)

For decades, enterprise access control has been governed by Role-Based Access Control (RBAC). In RBAC, if an employee needs access to a sensitive financial SharePoint site, the IT admin adds the user to the “Finance-SharePoint-Readers” Active Directory group. The problem is group proliferation. In a 10,000-employee company, you end up with 15,000 hyper-specific security groups, creating an unmanageable, unauditable administrative nightmare known as “group bloat.”

The modern identity architecture replaces RBAC with Attribute-Based Access Control (ABAC). In ABAC, access is granted not by group membership, but by dynamically evaluating the metadata (attributes) attached to the user and the resource at the exact moment of access.

Microsoft Entra ID enables ABAC through Custom Security Attributes. Instead of creating a group, you tag the SharePoint site with an attribute: Project = Apollo. You then tag the user with an attribute: Project = Apollo. A single, dynamic Conditional Access policy states: “Allow access only if the User’s Project attribute matches the Application’s Project attribute.”

This guide explains how to configure and deploy Custom Security Attributes in Microsoft Entra ID to achieve true ABAC.

Understanding the Security Architecture

Custom Security Attributes are fundamentally different from standard Entra ID user properties (like Department or JobTitle). Standard properties can be modified by Helpdesk staff, HR sync scripts, or even the users themselves. You cannot build a zero-trust security perimeter relying on a field that a tier-1 helpdesk agent can arbitrarily change.

Custom Security Attributes are cryptographically isolated. They are so secure that even a Global Administrator cannot view or assign them by default. Microsoft requires explicit assignment of the Attribute Definition Administrator and Attribute Assignment Administrator roles to interact with this data.

Step 1: Elevating Permissions

Before you can create attributes, you must grant yourself the specific cryptographic rights.

1. Navigate to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Roles & admins > Roles and administrators.
3. Search for Attribute Definition Administrator and assign it to your administrative account.
4. Search for Attribute Assignment Administrator and assign it to your administrative account.
5. Log out and log back in for the new RBAC tokens to apply.

Step 2: Defining an Attribute Set

Attributes are organized into logical buckets called “Sets.” We will create a Set for highly classified projects.

1. Navigate to Protect & secure > Custom security attributes.
2. Click Add attribute set.
3. Attribute set name: ProjectClearances.
4. Maximum attributes: 10.
5. Click Add.

Now, click into the newly created ProjectClearances set to define the specific attribute.

1. Click Add attribute.
2. Attribute name: ProjectCode.
3. Data type: String.
4. Allow multiple values: Yes (a user might be cleared for multiple projects).
5. Only allow predefined values: Yes (This prevents typos. You define the exact values).
6. Click Add predefined values and enter ProjectApollo and ProjectZeus.
7. Click Save.

Step 3: Assigning the Attribute to a User

Now that the secure attribute is defined in the schema, you must stamp a user with their clearance level.

1. Navigate to Users > All users.
2. Select a user (e.g., Jane Doe).
3. In the left menu, select Custom security attributes.
4. Click Add assignment.
5. Select the ProjectClearances set and the ProjectCode attribute.
6. Select the value: ProjectApollo.
7. Click Save.

Jane Doe is now cryptographically tagged with the ProjectApollo clearance.

Step 4: Enforcing ABAC via Conditional Access

The final step is to build the Zero Trust policy that dynamically evaluates the attribute.

Assume you have an Enterprise Application (e.g., an internal financial web app) that has also been tagged with the ProjectApollo attribute.

1. Navigate to Protection > Conditional Access > Policies.
2. Create a New policy.
3. Users: Include All Users.
4. Target resources: Under Select what this policy applies to, choose Cloud apps. Instead of manually selecting the app, click Edit filter.
5. Configure the filter: Attribute = ProjectCode, Operator = Equals, Value = ProjectApollo. (This policy now automatically applies to any application tagged with Apollo).
6. Conditions: Under Filter for users, configure the exact inverse logic: Attribute = ProjectCode, Operator = NotEquals, Value = ProjectApollo.
7. Grant: Select Block access.

The Logic Explained: If a user attempts to access an application tagged with ProjectApollo, but the user’s secure attribute does not equal ProjectApollo, the connection is instantly blocked.

Conclusion

Attribute-Based Access Control completely eliminates the administrative overhead of managing thousands of static Active Directory security groups. By leveraging Microsoft Entra Custom Security Attributes and dynamic Conditional Access filters, enterprise architects can build highly scalable, cryptographically isolated Zero Trust perimeters where access permissions instantly adapt based on the real-time metadata of the user and the application.