Azure AD RBAC: Custom roles & administrative units for devices now available

[Alex Simons (AZURE)]

Howdy folks,

In our first blog of this series, we discussed general availability of custom roles for delegated app management. Continuing the series of announcements for Azure Active Directory (Azure AD) role-based access control (RBAC), I’m excited to share several new features to enable fine-grained delegation of device administration in Azure AD. With these new capabilities, you can now:

• Create custom roles using permissions for device objects.
• Add devices as members of administrative units and assign built-in or custom roles for managing devices over the scope of an administrative unit.

Let’s take a look at some of the cool things you can do with these new capabilities.

You can also watch and experience these new features in action:

Create a custom role
To create a custom role using device permissions, go to Roles and administrators, then select New Custom Role. In this example, we’ll create a custom role called “BitLocker Recovery Key Reader.”

Give the role a name and description. Next, use the new device permissions for custom roles to select only the BitLocker permissions for this role.

Finally, click Next and create the role. Now you have a custom role that you can use to delegate access only to read BitLocker recovery keys without having to grant any unnecessary permissions.

Add devices to an administrative unit

In addition to customizing the permissions in the role, you can also use administrative units to scope those permissions to a specific set of devices.

In the example below, devices have been added to an administrative unit called “Service Department.” You can click Add device to add additional device(s) to the administrative unit.

Putting it all together

You can now go to the Roles and administrators tab and assign the custom role you created over the scope of the administrative unit. This allows you to ensure that the BitLocker permissions you specified when you created the role apply only to the devices specified in the administrative unit.

Note: we highly recommend assigning the custom role as an eligible assignment through Privileged Identity Management.

That’s it! For more information, check out our documentation on custom roles or administrative units. You can also access these same capabilities using PowerShell and Microsoft Graph APIs.

What’s next

Stay tuned for more great features around Azure AD RBAC. In the meantime, we'd love to hear your feedback, thoughts, and suggestions. You can share these with us on the Azure AD administrative roles forum or leave comments below.

Best Regards, 

Alex Simons (Twitter: @Alex_A_Simons)

Corporate VP of Program Management   

Microsoft Identity Division

Learn more about Microsoft identity:

• Related Articles: Custom roles for app registration management is now in public preview!
• Return to the Azure Active Directory Identity blog home
• Join the conversation on Twitter and LinkedIn
• Share product suggestions on the Azure Feedback Forum

[Peter_Holdridge]

Not trying to say this is bad, but AU still has the MAJOR issue of manually putting in devices instead of device groups. The same issues exist as before with users, but now devices also can be added manually. This is not scalable.

We need AU's to be able to add users or devices by GROUP MEMBERSHIP and include DYNAMIC GROUPS too for scalability and operationalization.

[Doug_Kirschner]

@Peter_Holdridge Good news. We are actively rolling out support for dynamic AU membership as well - look for an official announcement soon on this blog very soon, and in the meantime you can check it out for yourself under the "Properties" tab of an administrative unit.  For more information: https://docs.microsoft.com/azure/active-directory/roles/admin-units-members-dynamic

[Joshua Bines]

@Doug_Kirschner Great thx! Might be idea to change the red Xs listed here for 'Add or remove groups dynamically based on rules': Administrative units in Azure Active Directory | Microsoft Docs

Edit: I noticed in the rules that you can have Dynamic User or Dynamic Device can you use dynamic rules to populate both users and devices to a single AU? 

@Peter_Holdridge - For the last couple of years we used the following to bridge the gap. https://github.com/JBines/Set-AADAUDynamic and might still be cheaper than granting every admin a Azure premium license but depends on your requirements and budget. 

[Peter_Holdridge]

@Joshua Bines Thanks. Yes, we already use Azure Automation to update the AU users from an existing dynamic group to get around this but we shouldn't have to. AU should have this built-in. You don't even need to setup rules in AU. Just the ability to select an existing dynamic group would be fine. Or any group...

[ENT57]

This is certainly a move in the right direction, at least in terms of being able to delegate access to read BitLocker keys for specific devices but there’s a much larger hole in Microsoft’s desktop management strategy that needs to be addressed, at least in terms of delegation.

Some InTune features can only be targeted at device groups and group ownership allows for selection of any device in the directory.  It’s effectively impossible to delegate both these features and ownership of the associated groups without giving a delegate the ability to target and affect every device.  MECM(SCCM) does this by allowing us to limit selections to specific collections (eg not All Devices).  What are the  Azure and InTune teams doing to correct this gap?

[Doug_Kirschner]

@Joshua Bines thanks, actually that line "adding and removing groups dynamically based on rules" is not yet supported so the red X is correct. The line above ("add or remove users or devices dynamically based on rules) is what we are rolling out the support for in this initial release, i.e. the same things you can currently do with dynamic groups, you can do with administrative units.

@ENT57 thanks for the feedback. This release is just a first step, and also we're looking into ways to improve the scenario you describe with Intune.  Stay tuned!

[Karl_Wester-Ebbinghaus]

Hello @Doug_Kirschner this sounds like a welcomed and needed step forward.

What do you think about having the example of Bitlocker Key readers as an integrated part instead of a custom role.

Bitlocker is a major part of the security concept of Secured Core.

Thank you! 

[Reza_Ameri]

Thank you for sharing.

This is a really valuable feature and it is helpful in different cases.

[namor38]

Nice, thank you for sharing.

Is it also planned to be able to use the  administrative unit in Intune?
I'm thinking of software assignment by administrative unit and things like that.

[PacoB]

Hello,

I was trying to assign cloud device administrator at  administrative unit for scoped device management, but it seems that with such role I can only disable device not to delete. if assigned at directory level, then it works as expected. is it issue of the preview Device per administrative unit feature or did I miss anything ?

sorry to ask here ;)

Peter

[25564]

I have the same issue, Administrative Units are limited to a very short list of permissions. This unfortunately isn't enough to even delegate to each site helpdesk permissions.

Our helpdesk converts leavers mailboxes to shared before deleting the account.
We have found out that they need the Directory Exchange Administrator role, giving them permissions to manage every user and mailbox in our company, not just their Administrative Unit users and their mailboxes. 

Maybe I'm missing something but this isn't working as expected. The dynamic membership is great, we can populate them by country using that AD field automatically with a very simple rule. But the permissions that can be given are VERY limited. You cannot delegate MFA administration within the administrative unit, so instead we have to give each IT manager permissions to the whole Directory with the Privileged Authentication Administrator. 

You might say, well you're trying to delegate stuff that's Directory based by design and you cannot limit it to your AU. And you are probably right, but if you give someone the User Administrator at their AU level this is what happens:

They cannot see the Azure Active Directory admin center in the Microsoft 365 Admin Center sidebar. Is this a bug or is it intentional? Because they can still type entra.microsoft.com and login, where they will see thousands of users instead of just their AU. At least they're unable to modify them and this shouldn't be an issue, it's read only after all. But they still can see them. And because of that, the moment you give that user a Directory based permission (because there's no way to delegate most things within an AU) they can now see AND modify all the MFA users at the company, for example.

I tried making custom roles but to no avail. Those MFA management or Exchange mailbox permissions are set at the Directory level.

Maybe we're using it wrong and each site should have their own tenant? But the license pool would not be global anymore which is a big no no, and some other issues would come with that.

The official documentation makes great promises and that's why we implemented it, but unfortunately the feature seems to still be in beta: 

Administrative units restrict permissions in a role to any portion of your organization that you define. You could, for example, use administrative units to delegate the Helpdesk Administrator role to regional support specialists, so they can manage users only in the region that they support.

Please @Alex Simons let me know if I'm wrong and there's a way to make it work, I really hope I'm wrong because the feature is promising and RBAC is the foundation of Azure. 

[Joshua Bines]

@25564 We have it working well but it's not a 1 click solution you really need to take the time to review and setup the RBAC roles for aspects like Exchange and Intune and of course there are still gaps. The authentication admin works with the Admin unit and should allow scoped admins to reset MFA for only those within the scope as long as they do not have any assigned roles? May that's why you needed to assign the *Privileged* Authentication Administrator... which isn't a great idea to too many admins btw. 

For exchange you will need to setup the RBAC roles and and scopes. You can link these now directly to the AADAU but you might still have issues with groups etc but there is still work arounds. 

GitHub - JBines/Set-RoleGroupMembers: This script automates the population of members from one group...

[testuser7]

Hi  @Doug_Kirschner There is NO doubt about this facility.  It is helping us.

I wanted to confirm one point around AU, though.

This AU facility is only helping on Azure-portal.  I wanted  to extend it while that  "principal" invokes Graph-API

So for example, 

You will NOT find the admin-role which is scoped to particular AU in any access-token.
I tested it.
I created custom-role R1 and assign it to app1 scoped to AU1   (So that this app1 can only pull groups that are part of AU1)
When this app got token (Client-cred-flow),  this custom-role was NOT in the "wid" element.
As a result ,when this  app1  invoked graph api  (/group),  graph-api  gave "authorization error"