March this year the Active Directory team announced Attribute Based Dynamic Group Membership for Azure AD. Until then, group membership was a manual thing that had to be done for each user. With this feature you can specify a rule on an Azure AD security group that will automatically manage the membership of that group based on user’s attribute values. Dynamic Group Membership is supporting by default a subset of user attributes which can be used.
But what if you use in your organization custom attributes for various applications-, business- and provisioning processes? In this blog post we go further and will explain how to use custom AD attributes, extend your Azure AD tenant and use these custom attributes to automatically populating a security group.
Custom Active Directory Attribute
First we’ll with Jimbo – our test user for today – start to configure local Active Directory by defining a custom user attribute. In this example we’re using the msDS-cloudExtensionAttribute1 user attribute with the value System Center User Group NL
Azure Active Directory Connect
In order to synchronize and extend your Azure AD schema, Azure AD Connect is required, to bring these custom attributes to the cloud. One of the new optional features of Azure AD Connect is Directory Extension Attribute Sync. With directory extensions you can extend the schema in Azure AD with custom attributes used by your organization.
During the initial setup of Azure AD Connect or configuration afterwards, attribute(s) can be selected in the Directory Extensions wizard. In this example we select the msDS-cloudExtensionAttribute1 user attribute.
Only single-valued attributes are supported and the value cannot be longer than 250 characters. The metaverse and Azure AD schema will be extended with the attributes selected. In Azure AD a new application is added with the attributes.
Configuring Azure AD Connect is resulting in a subset of in- and outbound synchronization rules. The Synchronization Rule Editor, part of the Azure AD Connect installation, allows you to add, remove or edit existing synchronization rules. Based on the selected custom user attribute a transformation rule is created including the Source attribute (AD) and Target Attribute (Azure AD).
Azure Active Directory Graph API
After a successful synchronization cycle your Azure AD schema should be extended with msDS-cloudExtensionAttribute1 user attribute. A way to verify this, is using Azure Active Directory Graph API. The Azure Active Directory Graph API provides programmatic access to Azure AD through OData REST API endpoints. Applications can use the Graph API to perform create, read, update, and delete (CRUD) operations on directory data and objects. For example, you can use the Graph API to create a new user, view or update user’s properties, change user’s password, check group membership for role-based access, disable or delete the user. For more information on the Graph API features and application scenarios, see AD Graph REST and Azure AD Graph API Prerequisites.
I’m not a dev, so I’m using the Graph Explorer tool to query my Azure AD schema to verify if the selected attribute extension is available. The output from our get query shows us our Azure AD schema is successfully extended with the user attribute msDS-cloudExtensionAttribute1 and is known by “extension_3e2cd06ca3494546888b069a891b4bb6_msDS_cloudExtensionAttribute1″ including the value “System Center User Group NL”.
Azure AD Dynamic Groups
The last part is configuring a dynamic group(s) using the msDS-cloudExtensionAttribute1 attribute in order to get Azure AD group automatically filled. In order to use a custom attribute we need to configure an advanced rule. More information of using advanced rules can be found here. The left parameter of the binary expression consists of declaring a custom extension, a unique quid complemented with the custom extension.
And finally our test user Jimbo became automatically member of the extended ad attribute (msDS_cloudExtensionAttribute1) security group.