From Microsoft: What’s the difference between Privileged Access groups and role-assignable groups – Azure AD – Microsoft Entra | Microsoft Docs

We saw this new feature, liked the look of it, read about it and then set about implementing it.  In my opinion I don’t think Microsoft had a well documented process for implementing it so I’ve decided to share my experience on setting it up.

In essence, this is an extension of Azure AD Groups that are “Role assignable”. This feature has been around for a while.  The concept for those is to add a group of users that all often use a Role, put them in a Group, and assign that Group to the Role and they can PIM up.  As admins come and go, you only need to update the group, rather that the Role directly.

Privileged Access Groups goes one step further in that it allows you to bundle up multiple Roles on to the Role Group, and then a Group of Admins can PIM up to a Group of Roles in one action – rather than having to PIM up multiple times to multiple Roles.

What are Azure AD role-assignable groups?

Azure Active Directory (Azure AD) lets you assign a cloud Azure AD security group to an Azure AD role. A Global Administrator or Privileged Role Administrator must create a new security group and make the group role-assignable at creation time.

Only the Global Administrator, Privileged Role Administrator, or the group Owner role assignments can change the membership of the group. Also, no other users can reset the password of the users who are members of the group. This feature helps prevent an admin from elevating to a higher privileged role without going through a request and approval procedure.

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/concept-privileged-access-versus-role-assignable#what-are-azure-ad-role-assignable-groups

What are Privileged Access groups?

Privileged Access groups enable users to elevate to the owner or member role of an Azure AD security group. This feature allows you to set up just-in-time workflows for not only Azure AD and Azure roles in batches, and also enables just-in-time scenarios for other use cases like Azure SQL, Azure Key Vault, Intune, or other application roles. For more information, see Management capabilities for Privileged Access groups.

Activate multiple role assignments in a single request

With the Privileged access groups preview, you can give workload-specific administrators quick access to multiple roles with a single just-in-time request.

An example of that might be to give an Administrator privileged access to Exchange Admin, User Admin, Teams Admin and SharePoint admin in one go for their job, rather than needing the Administrator to PIM up three times, or worse, opting for Global Admin.  They can now PIM up and get all four in one go.

Set-up

Step 1 – Create an Azure AD Role Assignable Group

Step 2 – Activate Privileged access

This to me appeared to be a missing step in the MS documentation, and took a while to figure out.  Open the Group in the Azure AD Admin portal and head to Activity.  Normally I would not look in “Activity” for an extra setting, but that is where it is.  This isn’t the first time recently that MS have buried a new feature.  MFA “Require number matching” is a prime example.

In the centre pane you will see the option to Enable Privileged Access.

Step 3 – Configure Role group settings

Now you need to click that Activity again for Privilege access (Preview) and update the Member and Owner Settings for Users.  Setting the usual PIM things like, require justification, require MFA, how long the access should be for, require approvals and notifications.

Step 4 – Update Roles from Eligible to Active

You might need to update the Assigned Roles from Eligible to Active.  This ensures that when a user PIMs up, they get the Role, rather then PIM into the Group as an active member, and then needing to PIM the Role.

Step 5 – Add eligible Users

This should be done by Add assignments under the Activity\Privilege access (Preview) section of group.  This should NOT be done via updating Members directly as this would make them PERMANENTLY activated and would bypass notifications that get sent to relevant recipients.  More on this under How are role-assignable groups protected? 

In fact, only Global Administrators, Privileged Role Administrators and the Group Owners can update memberships in any event.

Step 6 – Activate PIM

Users need to go to a new place to activate themselves into a Role Group.  Instead of Azure AD Roles, they now go to Privileged access groups (Preview).  Here they will see all the Role Groups they are eligible to activate.  If they are directly assigned on Roles, they will still see them on Azure AD Roles.

After this competes, Users will be able to see their Active Role Group Assignments

And also the individual Role Assignments.

How are role-assignable groups protected?

You may think that anyone with any role that is allowed edit access to Azure Active Directory can just promote themselves to a higher role by updating the Group membership, right?  E.g. Intune Admin, Groups Admins, Exchange Admins.  Well, no they can’t.

Here you can see that I have elevated to: Intune Administrator, Groups Administrator – but NOT Global Admin or Privileged Role Admin

But I cannot update the Azure AD Role Assigned Groups

From Microsoft

https://docs.microsoft.com/en-us/azure/active-directory/roles/groups-concept#how-are-role-assignable-groups-protected

Only groups that have the isAssignableToRole property set to true at creation time can be assigned a role. This property is immutable. Once a group is created with this property set, it can’t be changed. You can’t set the property on an existing group.

Role-assignable groups are designed to help prevent potential breaches by having the following restrictions:

• Only Global Administrators and Privileged Role Administrators can create a role-assignable group.
• The membership type for role-assignable groups must be Assigned and can’t be an Azure AD dynamic group. Automated population of dynamic groups could lead to an unwanted account being added to the group and thus assigned to the role.
• By default, only Global Administrators and Privileged Role Administrators can manage the membership of a role-assignable group, but you can delegate the management of role-assignable groups by adding group owners.
• RoleManagement.ReadWrite.Directory Microsoft Graph permission is required to be able to manage the membership of such groups; Group.ReadWrite.All won’t work.
• To prevent elevation of privilege, only a Privileged Authentication Administrator or a Global Administrator can change the credentials or reset MFA for members and owners of a role-assignable group.
• Group nesting is not supported. A group can’t be added as a member of a role-assignable group.

Caveat on Notifications

One caveat we have learned about role-assignable groups is that notification settings are respected when you add the members / owners via Privileged access (Preview) section in the Azure AD Portal.

However, if an allowed Admin such as Global Admin or Privileged Role Admin updates the Group Membership DIRECTLY, no notification is sent.

Known issues

https://docs.microsoft.com/en-us/azure/active-directory/roles/groups-concept#known-issues

The following are known issues with role-assignable groups:

• Azure AD P2 licensed customers only: Even after deleting the group, it is still shown an eligible member of the role in PIM UI. Functionally there’s no problem; it’s just a cache issue in the Azure portal.
• Use the new Exchange admin center for role assignments via group membership. The old Exchange admin center doesn’t support this feature. If accessing the old Exchange admin center is required, assign the eligible role directly to the user (not via role-assignable groups). Exchange PowerShell cmdlets will work as expected.
• If an administrator role is assigned to a role-assignable group instead of individual users, members of the group will not be able to access Rules, Organization, or Public Folders in the new Exchange admin center. The workaround is to assign the role directly to users instead of the group.
• Azure Information Protection Portal (the classic portal) doesn’t recognize role membership via group yet. You can migrate to the unified sensitivity labeling platform and then use the Office 365 Security & Compliance center to use group assignments to manage roles.
• Apps admin center doesn’t support this feature yet. Assign the Office Apps Administrator role directly to users.

I have actually tested the known issue “If an administrator role is assigned to a role-assignable group instead of individual users, members of the group will not be able to access Rules, Organization, or Public Folders in the new Exchange admin center.” – and it actually worked correctly for me at time of writing.

Licensing

To use Azure AD Privileged Identity Management your organisation needs EMS E5 or Azure AD Premium P2.  Every user who is eligible for membership in or ownership of a privileged access group must have an Azure AD Premium P2 license.

Summary

Privileged access groups is a handy new feature if you want Admins to be able to PIM up to multiple Roles in one go. This can work well when you are aligning business Roles to Azure Admin Roles.

Also, be cognisant of just exactly what Roles do what. For example, Intune Admin is a very powerful Role, and does more than just allow work in the MEM (Intune) portal.