Dynamic membership rules for Azure AD Administrative units

Administrative units have been around for a long time. I mean, my first post covering them is from Jan 2015, which in cloud terms is a century ago. Even back in the day, they were positioned as the building blocks of a robust RBAC model for Azure AD/Office 365. Yet, extending AU’s functionality has been a painfully slow process, to the disappointment of many.

On the other hand, AUs have continued to receive feature updates every now and then, be it enhanced UI support, the occasional new “scoped” role added or Graph API endpoints. Slow progress is of course better than no progress, and luckily AUs are still being worked on, unlike some other promising features we’ve seen descent into oblivion. Now, at long last, Microsoft is releasing a preview for one of the most requested improvements for AUs, namely support for dynamic membership. Let’s dig into it!

First, let’s look into enabling dynamic membership via the UI. Unlike using other methods, the UI only allows you to configure dynamic membership *after* you have created an AU, as in the option is not exposed as part of the AU creation process. In order to enable dynamic membership for a specific AU, navigate to the Azure AD blade > Administrative units > select the AU in question > Properties > select the corresponding value under Membership type. Here, you might notice that the UI¬† forces you to make an explicit choice between Dynamic user or Dynamic device membership, implying that you cannot have an AU with dynamic membership rules for both users and devices.

Once you make the selection for the Membership type, you will also need to provide a query, to be used as the dynamic membership rule/filter. The query itself can be added via the familiar rule builder UI, which makes things a bit easier. The same set of properties, operators and values as with dynamic membership rules for Azure AD Groups are supported, and the same restrictions/limitations apply. For example, you cannot use a rule that features both user and device clauses. And this is also the likely reason why we cannot have groups and other object types as dynamic members of AUs.

After you are satisfied with the query, press the Save button to get back to the Properties page. The query itself will not be shown on the Properties page, instead requiring additional clicks even if you only want to see what’s currently configured. Pressing the Save button will complete the process, and a warning that the current AU membership will be overwritten is displayed whenever you switch between dynamic and assigned membership.

At that point, you can refresh the page to have the Dynamic membership rules tab appear. The page brings the rule builder UI, where you can view or adjust the query as needed. A matching Membership rules button will be displayed under the Users tab, with the Add member/Remove member buttons and their “bulk” menu counterparts disabled. In other words, you cannot “manually” add/remove users from a dynamic membership AU. The same applies to other object types, and navigating to the Groups or Devices tabs will surface a warning, similar to the one below:

Devices cannot be added to the administrative unit because the membership type is Dynamic User. Go to properties to modify the membership type.

And that’s pretty much all there is to it. After configuring the dynamic membership rule, it will take few minutes to the membership list to be updated with any and all user objects matching the query we configured, which in our case was very simple. From here on, it’s business as usual, and you can assign roles as you would with a “regular” assigned membership AU.

Next, let’s turn to PowerShell. When using the good old MSOnline module, one can see the newly created dynamic membership AU, and can also query it’s membership list via the Get-MsolAdministrativeUnitMember cmdlet:

Get-MsolAdministrativeUnitMember -AdministrativeUnitObjectId b42de8c9-7062-4cc0-8c85-f6ae79bdb839

ExtensionData DisplayName EmailAddress ObjectId
------------- ----------- ------------ --------
System.Runtime.Serialization.ExtensionDataObject shared shared@michev.info cb38f772-b77e-47d2-a45c-efb7bd0a175e

As expected, you cannot add or remove members though. Using the Azure AD module results in similar behavior: you can query information about the AU and its membership via the Get-AzureADAdministrativeUnit cmdlet, but you cannot make any changes. Using the “newer” Get-AzureADMSAdministrativeUnit cmdlet reveals some additional details, such as the membership rule information:

Get-AzureADMSAdministrativeUnit -id b42de8c9-7062-4cc0-8c85-f6ae79bdb839

Id : b42de8c9-7062-4cc0-8c85-f6ae79bdb839
OdataType :
Description : All users in Bulgaria
DisplayName : Bulgaria users
IsMemberManagementRestricted : False
MembershipRule : (user.country -eq "Bulgaria")
MembershipRuleProcessingState : On
MembershipType : Dynamic

While adding or removing members is still not possible, using the *-AzureADMSAdministrativeUnit cmdlets allows you to make changes of the AU membership rules or membership type itself. For example, we can update the membership rule to something more comprehensive by using the following:

Set-AzureADMSAdministrativeUnit -id b42de8c9-7062-4cc0-8c85-f6ae79bdb839 -MembershipRule '(user.country -eq "Bulgaria") -or (user.usageLocation -eq "BG")'
Get-AzureADMSAdministrativeUnit -id b42de8c9-7062-4cc0-8c85-f6ae79bdb839

Id : b42de8c9-7062-4cc0-8c85-f6ae79bdb839
OdataType :
Description : All users in Bulgaria
DisplayName : Bulgaria users
IsMemberManagementRestricted : False
MembershipRule : (user.country -eq "Bulgaria") -or (user.usageLocation -eq "BG")
MembershipRuleProcessingState : On
MembershipType : Dynamic

After a few minutes, the membership changes should be reflected in both PowerShell and the Azure AD blade UI. If for some reason you want to temporary pause the membership update process, you can toggle the value of the MembershipRuleProcessingState parameter to “Paused”.

The same operations can also be performed via the Graph API, via the /beta/administrativeUnits endpoint, and the corresponding GET, POST, PATCH or DELETE operations. As an example, let’s use the Graph API to create a new dynamic membership AU, one that will filter out users based on domain. As with PowerShell, we can perform the configuration via a single request, by issuing a POST request against the /beta/administrativeUnits endpoint, with the following payload:

{
"displayName": "Domain-based",
"description": "Contains all users that have an email address associated with specific domain",
"membershipRule": "(user.proxyAddresses -any (_ -contains \"michev.info\"))",
"membershipType": "Dynamic",
"membershipRuleProcessingState": "On"
}

Here, we have used a bit more complicated membership query, one that takes advantage of lambda query via the -any operator and compares each of the email addresses for a given user against the desired domain. You can refer to the official documentation for additional examples, such as switching back to assigned membership and more.

With that, we can conclude our short overview of the Dynamic membership functionality for Azure AD Administrative units. Long anticipated, it should give a substantial boost to the adoption of AUs and custom RBAC controls in Azure AD. The feature more or less delivers the same set of functionality as dynamic membership rules for Azure AD groups, and has the same requirements/limitations, such as not being able to “mix” object types when using dynamic membership. Another unfortunate limitation is the lack of support for group objects, additionally limiting the dynamic membership story. Azure AD Premium licensing is required, but that’s a given for anything AUs related.

On a related news, Microsoft recently announced some improvements on the custom roles front, such as support for granular permissions for Device (as well as Group) object  management. The same announcement brought support for Device objects as members of AUs, which as mentioned above also includes dynamic membership. Slowly but surely, the Azure AD RBAC story is finally starting to take shape!

This entry was posted in Azure AD, Graph API, Microsoft 365, Office 365, PowerShell. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.