Last week, Alex Simons announced on behalf of his team the Public Preview of assigning groups to Azure AD roles with a blogpost titled Assigning groups to Azure AD roles is now in public preview! on the Microsoft Tech Community.
Ten things you need to know
Assigning groups to Azure AD Roles sounds perfect, but in reality, there are a couple of things you’ll want to know before deploying it to address your organizations’ needs:
Assigning Roles to Azure AD Roles Public Preview
Assigning groups to Azure AD Roles is currently in Public Preview. This means that Microsoft doesn’t really want you to deploy in production, just yet.
Looking back at Conditional Access Baseline Policies, you might want to hold off on embracing Public Preview functionality, as they might change at any moment: the granular Conditional Access Baseline Policies became rigid Security Defaults.
Also, looking at Azure MFA’s Hardware Token functionality, some functionality stays in Public Preview for an awful long time. As you lock your organizations’ strategy on these features, you might face architectural debt.
Requires an Azure Premium P1 license
Assigning a user to one or more Azure AD roles is available in every Azure AD tenant, including the Azure AD free tenants. However, assigning a group to one or more Azure AD roles, requires at least one Azure AD Premium P1 license.
Microsoft previously held off on requiring licenses on features in Public Preview. This time, though, Microsoft wants organizations to benefit from this security feature only when a paid licensing plan is activated.
Support for Azure AD Groups, but not on-premises groups
In Public Preview, the Assign Groups to Azure AD Roles feature is supported only for groups that live in Azure AD. Groups that are synchronized from an on-premises directory, like one or more Active Directory forests or LDAP v3 compatible directories are not supported at this time. However, the feature is planned.
As backup and restore of Azure AD is currently a pain, many organizations are looking at assigning a synchronized group to Azure AD roles, removing yet another configuration stored exclusively in Azure AD.
Requires new groups
Azure AD roles can only be assigned to groups that have the Azure AD roles can be assigned to the group (Preview) setting enabled.
This setting configures the isAssignableToRole property. It is set to true.
However, the setting can only be set at the time of creation of a group. This means that the groups you want to use the assign groups to Azure AD roles functionality with need to be new groups.
No support for Dynamic Groups
When you create a new group to use use the Assign groups to Azure AD roles functionality with, it must be created with the Assigned membership type. Dynamic Groups are not supported with the functionality at this point.
No support for nested groups
Of course, you might be tempted to create new groups to use with the new Assign groups to Azure AD roles functionality and simply specify existing groups as members of the new group.
However, group nesting is not supported for the functionality at this point.
A maximum of 200 role-assignable groups per Azure AD tenant
Before you go ahead and create all the groups you might ever need to assign Azure AD roles to, be aware that there is a maximum of 200 role-assignable groups per Azure AD tenant. Up to 200 groups can have the isAssignableToRole property set to true.
A matter of scope
As true administrators, you want to scope the administrative privileges assigned to people. The Assign Groups to Azure AD Roles functionality is currently 100% scoped to groups.
This means, that once a group has the isAssignableToRole property set to true, it can be used to assign any Azure AD role to the built-in Azure AD roles. However, the available roles can’t be scoped down. Additionally, there is no support for custom Azure AD roles or Azure AD Administrative Units (AUs).
Group Ownerships woes
Complexity is the enemy of security.
By default, only people with the Global administrator and Privileged role administrator role can create groups with the isAssignableToRole property set to true. By default, they are the only ones that can manage the memberships of a role-assignable group, but you can delegate the management of role-assignable groups by adding group owners.
There are many scenarios in which I can see a group owner be able to elevate privileges. I would refrain from using group owners with the Assign Groups to Azure AD Roles functionality, unless you consider these group owners the equivalent to Global admins.
Integration with Privileged Identity Management (PIM) Preview
Microsoft provides integration with Azure AD Privileged Identity Management (PIM) for the Assign Groups to Azure AD Roles functionality. For instance, this integration enables approval workflows for adding members to a role-assigned group.
However, you must be on the updated version of PIM to be able to assign a group to an Azure AD role via PIM. You could be on older version of PIM because your Azure AD organization leverages the PIM API.
You’ll need to reach out to pim_preview@microsoft.com to move your organization and update your API, in this case.
Concluding
For small cloud-only organizations with Azure AD P1 subscription licenses, the current Public Preview for the Assign Groups to Azure AD Roles functionality is good news. Without the on-premises integration, these organizations can be sufficiently agile to cope with any changes to the functionality in the future.
However, organizations with complex delegation needs, privileged identity management challenges and stringing along an on-premises directory, might have more problems putting the feature to effective use. The maximum of 200 groups without nesting might even put them off indefinitely.
Are we within licensing rights to use the Roles to Groups functionality as long as the user doing the assigning has a P1 license but not necessarily those within the groups?
Hi Brent,
As the feature is still in Public Preview, licensing terms are not yet available.
Why is this management feature not available to B2C tenants? Using role management to developer teams would be beneficial to be consistent with other directory management.
Now that this is not in preview anymore, there is still one important thing that still doesn't work: the WhatIf function of conditional access. When you have a policy applied to Directory Roles, the WhatIf only works when an account has been assigned a Role directly. It doesn't work when the Role has been assigned using these groups. WhatIf simply tells you that the policy is not applied then!