Administrative units (AUs) have been around for a long time. I mean, in my first post back in Jan of 2015, which – in the world of cloud computing – might as well have been a century ago. They were positioned as the building blocks of a robust Role-Based Access Control (RBAC) model for Azure AD/Office 365. However, the gradual extension of 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, such as:
Slow progress is, of course, better than no progress, and luckily AUs are still being improved, unlike some other promising features we've seen descend into oblivion. Now, at long last, Microsoft is releasing a preview for one of the most requested improvements for AUs, namely support for dynamic memberships.
Below, we’ll cover the basics of what AUs are, and what dynamic membership rules for AUs are. Then, we’ll detail how to create them via the Office 365 user interface (UI), with PowerShell, and finally via the Microsoft Graph API.
AUs in Azure Active Directory allows administrators to segment access and grant granular permissions to specific users and devices associated with a given segment. For example, within a large organization there will be divisions between departments – say marketing, sales, and operations. Within each of those departments, there will be folks with distinct roles who execute distinct functions and thus need sufficient permissions within the department to complete the specific tasks they are responsible for.
Active Directory AUs make this very thing possible. A central IT staff can segment access to your Office 365 resources and can further distinguish between roles within each segment; until just recently these rules had to be applied to each individual user or device being managed, which has amounted to an enormous cost in terms of time and resources required. Dynamic memberships seeks to reduce the workload required to achieve the same result.
Dynamic membership rules allow administrators to segment access to their Office 365 resources as well as subdivide permissions within those segments with far less effort and far less chance of user error in their creation. This is because an administrator can create a single rule that applies to all users or devices of a given class. For example, all users in each department or geographic region are already labeled as such in the system. So, a rule can be written that applies the desired permission levels to these Microsoft 365 groups, rather than applying them to each individual user. That way, when a user changes departments, say, the rules governing his or her permissions change as well.
First, let's look at enabling dynamic membership via Office 365 UI. When going this route, you’ll have to configure dynamic membership *after* you have created an AU, as this option is not available via the AU creation process in the UI.
In order to enable dynamic membership for a specific AU you’ve already created, you’ll need to:
1. Navigate to Azure AD Blade > Administrative Units
2. Select the AU in question and click on Properties
3. Select your desired value under Membership Type
Here, you might notice that the UI forces you to make an explicit choice between Dynamic User or Dynamic Device Group membership, as you cannot have an AU with dynamic membership rules for both users and devices.
4. Once you select a 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 that are available 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.
5. After you’ve created the query, click Save to get back to the Properties page.
The query itself will not be visible on the Properties page. However, clicking the Save button will complete the process, and you’ll see a warning that the current AU membership will be overwritten if you continue.
6. Refresh the page to have the Dynamic Membership Rules tab appear.
7. Use the rule builder UI to view or adjust your query as needed.
8. 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.
9. 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 a few minutes for 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, as 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 its membership list via the Get-MsolAdministrativeUnitMember cmdlet:
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:
While adding or removing members is still not possible, using the *-AzureADMSAdministrativeUnit cmdlets allow you to make changes to the AU membership rules or membership type itself. For example, we can update the membership rule to something more comprehensive by using the following:
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 temporarily 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, by way of 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 that will filter out users based on domain. As with PowerShell, we can perform the configuration via a single POST request to the /beta/administrativeUnits endpoint, with the following payload:
Here, we have a bit more complicated membership query that takes advantage of lambda query via the -any operator, and which 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 AUs. As it has been 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 (and limitations), such as not being able to "mix" object types when using dynamic membership. Another unfortunate limitation is the lack of support for group based objects, which further limits the dynamic membership story. Azure AD Premium licensing is required, but that's a given for anything AUs related.
On a related note, 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. If you are tired of waiting, however, CoreView can offer all this, and more, right now!
With CoreView’s Virtual Tenants, you can segment your tenant by almost any criteria – from agencies to departments or teams, or even by role or other criteria, thus giving you an even greater degree of granular control than that described above with the added benefits of powerful dashboard configurations, automation of repetitive tasks and more! Schedule a demo to see it in action.
