(2021-09-11) Azure AD Administrative Units – Delegating Scoped Admin Tasks In Azure AD

Quite some time ago I blogged about Azure AD Administrative Units (AU). The details can be found in the found through the following blog posts:

• (2019-07-04) Azure AD Delegation Through Roles And Administrative Units – The Good, The Bad And The Ugly (Part 1)
• (2019-07-07) Azure AD Delegation Through Roles And Administrative Units – The Good, The Bad And The Ugly (Part 2)

–

Microsoft documentation: https://docs.microsoft.com/en-us/azure/active-directory/roles/administrative-units

–

Since then many things have changed, and today it is a valuable feature to delegate management of a set of objects to other groups of people. It is different than OUs in Active Directory (AD). OUs in AD are for delegating management and applying policy. AUs in Azure AD are for delegating management only.

Figure 1: Administrative Units In Azure AD – From The Administrative Unit Perspective

–

Objects

Today AUs only support user and group objects, both cloud native and hybrid/synched. Those objects are not actually child objects of an AU. The objects are assigned to one or more AUs. The assignment basically behaves like a group membership. By allowing objects being assigned to multiple AUs, multiple groups of admins can manage the same set of objects.

Objects can be assigned to an AU

• …from the AU perspective => select AU, then add member object

OR

• …from the object perspective => select object, then assign an AU

Figure 2: User Objects Member Of A Certain Administrative Unit

–

Figure 3: Group Objects Member Of A Certain Administrative Unit

–

Figure 4: Administrative Units In Azure AD – From The Object (In This Case: User) Perspective

–

Administration

The main and only goal of AUs is the delegation of administration of user and group objects. At tenant level, Azure AD supports many administrative roles. Some of those roles, that focus on user and group objects throughout the complete Azure AD tenant, can therefore also be scoped at AU level allowing to perform the tasks supported by the administrative role on the objects that are assigned to the AU. In figure 5 you can see the administrative roles currently supported by an AU.

Figure 5: Administrative Units In Azure AD – Available Delegation Roles For Each Administrative Unit

–

This does not mean, delegation is configured by default. No, you still need to configure that by either assigning users and/or groups the respective role scoped for the corresponding AU. In terms of users you can assign any user the supported roles scoping the AU. With regards to groups, you can only assign groups only the supported Azure AD roles, if those groups have been created to support Azure AD role assignments. That support cannot be changed after the creation of the group. it must be configured when creating the group.

When looking at a specific Azure AD administrative role, you will be able to see what the scope of management is and which object (group or user) has been configured for that specific scope.

–

Assigning Objects To AUs

It is possible to add or remove assignments of individual objects, through either the Azure AD Portal, PowerShell or the Microsoft graph. Additionally, through the Azure AD Portal it is possible to bulk add or remove objects to/from the AU. When deleting an AU, only the AU, the delegating configuration (role assignment scoped to the AU, not the role itself) and the assignment of objects (users and groups, but not the objects themselves) will be deleted with it.

Figure 6: Administrative Units In Azure AD – Supported Bulk Operations

–

Another thing that would be very interesting is auto assigning users and groups to Administrative Units instead of all the current manual work that is needed. Dynamic assignment similar to dynamic groups would be very welcome and definitely a serious win!

Nevertheless, if you have something that can either leverage the Azure AD PowerShell module or the Microsoft Graph API, dynamic assignment is possible as long as you have something external to Azure AD (IAM System?) to determine the logic of adding or removing objects to/from AUs. More about these thoughts in a next blog post! Make sure to read that one!

–

PowerShell

The Azure AD PowerShell module supports CMDlets to manage AUs through either the Azure AD graph (deprecated!) (*-AzureADAdministrativeUnit*) or the Microsoft graph (preferred!) (*-AzureADMSAdministrativeUnit*)

 –

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

IAMTEC

Identity | Security | Recovery

https://iamtec.eu/
————————————————————————————————————————————————————-

(2021-09-09) Azure AD Graph Deprecation – Are You Already Migrating?

About more than a year ago, around June 30th 2020, Microsoft announced the deprecation of Azure AD Graph. At the same time everyone was told to start migrating away from Azure AD graph to Microsoft Graph. The latter supports both Azure AD and different Microsoft online services such Exchange, Sharepoint, Teams, etc.

At a very high level Microsoft said:

Azure Active Directory (Azure AD) Graph is deprecated. To avoid loss of functionality, migrate your applications to Microsoft Graph before June 30, 2022 when Azure AD Graph API endpoints will stop responding to requests. Microsoft will continue technical support and apply security fixes for Azure AD Graph until June 30, 2022 when all functionality and support will end. If you fail to migrate your applications to Microsoft Graph before June 30, 2022, you put their functionality and stability at risk.

–

Most of the time people read this and may think: “I’ll look at that later”. With that thought, time goes by and suddenly it June 30th 2022! Oops!

Well, it’s not too late, yet. In less then a year, everything still using Azure AD graph will stop working. Microsoft provides documentation and guidance on how to determine where Azure AD graph is being used and how to migrate to Microsoft graph. Information about this can be found through the following links:

• Migration From Azure AD Graph To Microsoft Graph – Overview
• Migration From Azure AD Graph To Microsoft Graph – Planning And Checklist
• Migration From Azure AD Graph To Microsoft Graph – FAQ

–

Please be aware that changes might be more work than you would expect. For example, if you look at the Azure AD PowerShell module it uses Azure AD graph in the backend. Today already the Azure AD PowerShell module already supports the Microsoft graph in addition to the Azure AD graph. For example, taking a the CMDLet “New-AzureADgroup” as example, Microsoft did not change that CMDlet to suddenly start using Microsoft graph. No, they introduced a replacement CMDlet “New-AzureADMSGroup” that targets Microsoft graph. If you have scripts, please be aware it might not be as simple as changing from *-AzureAD* to *-AzureADMS* . Due to the change of the CMDlet and therefore the endpint, there are also (subtle) schema changes. The easiest example is the change from ObjectID to ID.

–

Also be aware that new features will be implement in Microsoft graph only, and anything that leverages it. An example of such is the ability of assigning Azure AD groups to Azure (AD) roles. When creating a group in the Azure AD portal, you need to enabled the option “Azure AD roles can be assigned to the group”. Now, through PowerShell you need to use the CMDlet “New-AzureADMSGroup” with the parameter “-IsAssignableToRole”

–

Now, if you have not started yet migrating away from Azure AD graph to Microsoft graph, make sure to start A.S.A.P.!

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

IAMTEC

Identity | Security | Recovery

https://iamtec.eu/
————————————————————————————————————————————————————-