Blog Post

Microsoft Entra Blog
2 MIN READ

Introducing Restricted Management Administrative Units in Microsoft Entra ID

skwan's avatar
skwan
Icon for Microsoft rankMicrosoft
Jul 12, 2023

We’re excited to share the public preview of restricted management administrative units, a new role-based access control (RBAC) feature in Microsoft Entra ID. 

 

What you can do with restricted management administrative units 

With restricted management administrative units, you can now designate specific users, security groups, or devices in your Microsoft Entra ID tenant that you want to protect from modification by tenant-level administrators. 

 

Here are some situations in which this is useful: 

 

  • You want to protect sensitive user accounts, such as C-level executives, from being able to have their password or multifactor authentication settings changed by regular helpdesk administrators. 
  • You want to ensure that certain user accounts, security groups, or devices from a specific country can only be modified by designated administrators from that country.
  • You have specific security groups granting access to sensitive data and you want to restrict who can modify the membership only to a small set of administrators.

 

By placing your sensitive objects in a restricted management administrative unit, your tenant-level administrators will not be able to modify them.  Only the administrators you explicitly assign to the scope of the administrative unit itself will be able to make changes. 

 

Tenant-scoped and other admin unit-scoped administrators are blocked from resetting executives' account passwords.  Only the explicitly designated Executive admin can manage these accounts.

 

 

This is a much easier way to protect your sensitive objects than having to identify and scope every single role assignment in the tenant just to your non-sensitive objects. 

 

How to use restricted management administrative units in your tenant 

Here’s a quick example of how restricted management administrative units make it a breeze to secure a few sensitive user accounts in your tenant: 

 

 1. Under Roles & admins, select Admin units and click Add to create a new administrative unit. 

 

 

 

 2. Set the Restricted management administrative unit setting to “Yes” and click Next: Assign Roles 

 

 

 

3. Add the designated administrator(s) who should be the helpdesk administrators for these sensitive accounts (these are the people who you do want to manage the accounts) and finish creating the administrative unit. 

 

 

 

 4. Now, you can go ahead and add the sensitive user accounts to the restricted management administrative unit you just created (just like you would for any other administrative unit). 

 

 

 

That’s it!  Now the sensitive user accounts can only be modified by the users you designated, regardless of how many other administrative roles may be assigned in your tenant. 

 

To learn more details about how restricted management administrative units can help you secure sensitive resources in your tenant, check out our product documentation! 

 

Best Regards, 

 

Stuart Kwan  

Partner Manager, Product Management 

Microsoft Identity Division 

 

 

Learn more about Microsoft identity: 

Updated Jul 06, 2023
Version 1.0

2 Comments

  • GuidoG's avatar
    GuidoG
    Copper Contributor

    skwan Nice work, Stuart and team!  I've started to look at this and it is certainly an "interesting" feature, even though a GA won't have a problem to either remove a user from a restricted AU, change them, and then move them back ... but - of course - not without leaving traces in the audit-log.  So certainly worthwhile to hinder GAs from performing any unintentional change on objects in a restricted AU!  

    Nonetheless, my testing also showed that there are circumstances when using restricted AUs, where it's even more challenging to predict which objects can be edited by whom - i.e. what the resultant set of permissions an operator has on an object. E.g. when one of the objects in the restricted AU is themselves assigned to an AAD/EID role, the "restricted AU" admin (i.e. the "Executive admin" in the sample above) who may be assigned the User Admin role, won't be able to edit this object as it's "protected" by being a member of a (privileged) role [MikeCrowley - this object-protection by membership of a role is what I'd compare to AD's AdminSDholder/SDPROP process].  However, the GA can no longer edit that account either, unless also assigned to manage the objects in the restricted AU ... which obviously defeats the purpose. 

    So, good care must be taken when planning the use of the restricted AU feature - but in general, I very much welcome it!