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

Within Active Directory (AD), organizational units (OUs) were used to apply policy and delegate administration. With regards to delegation of administration in AD, that came down to delegation of specific actions such as for example “Password Reset” (a so called Control Access Right (CAR)) or Read/Write of a specific attribute such as for example givenName. AD does not know the concept of roles. Those can be implement though by creating a security group that has one or more permissions for a specific scope of objects.

–

Azure Active Directory (AAD) in turn does not implement OUs like AD, but rather administrative units (AUs). Also, in AAD it is not possible to apply permissions as granular as is possible in AD. Nevertheless, AAD does know the concept of roles and every role has a predefined set of permissions. Some roles are available by default and ready to use and other roles need to be enabled/activated first. Within AAD you can make people permanent members of one or more roles, or when using roles together with Privileged Identity Management (PIM), you can make people eligible of specific roles and allow those eligible people to activate a specific role for a specific amount of time as needed.

–

Through the following CMDlet you can retrieve the current enabled AAD roles:

Get-AzureADDirectoryRole

In any AAD tenant the following AAD roles are by default enabled:

Figure 1: Default Enabled Azure AD Roles

–

Before you can assign an AAD role through PowerShell it must be enabled first through the following CMDlet:

Enable-AzureADDirectoryRole -RoleTemplateId <Role Template Object ID>

The available roles can be retrieved by asking for the available role templates and can be done through:

Get-AzureADDirectoryRoleTemplate

In any AAD tenant the following AAD role templates are by default available:

Figure 2: Default Available Azure AD Role Templates

–

However, in the AAD Portal (https://portal.azure.com/), it is not required to enable an AAD role first before being able to assign it to someone. As soon as you assign the AAD role through the AAD Portal it is enabled automatically if it was previously disabled. From an AAD portal perspective things look as displayed in the figure below. All AAD roles with a flag, are newly introduced roles.

Figure 3: Default Available Azure AD Role (Templates) In The AAD Portal

–

When using the Office 365 Admin Center (https://portal.office.com/) you can see a similar list with AAD roles that in addition also mention the category the AAD role is used in. Examples are “Identity”, “Security & Compliance”, “Devices”, “Billing”, “Collaboration” and some others.

–

Looking at the contents of figure 1 and compare it with the contents of figure 2 you can see a huge difference in AAD roles that have been added by Microsoft to AAD to prevent and offload the usage of the “Global Administrator” (a.k.a. “Company Administrator”) and use a less powerful AAD role to accomplish what you need. All AAD roles work at tenant level, so delegating stuff to a less powerful role is progressing by experience and what admins of AAD request. For example, not so long ago I requested Microsoft to implement a new role similar to “Global Administrator” in read-only mode. I have had and still have many occasions where I need “Global Administrator” role just to look a configurations and/or data. Having a “Global Administrator Read-Only” (or whatever Microsoft will call it in the end) would prevent me from having to use the “Global Administrator” role, which is of course a good thing. That way I could be a permanent member of “Global Administrator Read-Only” and use PIM to activate the “Global Administrator” as really needed!. And believe it or not, Microsoft can deprecate roles in AAD as specified in Administrator role permissions in Azure Active Directory at the bottom of the article.

–

Using the “administrative units” feature in AAD. Unfortunately that’s when things become more problematic and unfortunately experience today is not always consistent. As an example, I’m going to use the “Authentication Administrator”, which has a description of “Allowed to view, set and reset authentication method information for any non-admin user.”. That role will be assigned to the user account “admin.authn.am@iamtec.onmicrosoft.com” at either tenant level or AU level, depending on what I’m discussing.

–

First, let’s have a look at that role. The “Authentication Administrator” AAD role has a description of “Allowed to view, set and reset authentication method information for any non-admin user.”. Looking at the additional information as written in Administrator role permissions in Azure Active Directory it says:

Users with this role can set or reset non-password credentials. Authentication Administrators can require users to re-register against existing non-password credential (for example, MFA or FIDO) and revoke remember MFA on the device, which prompts for MFA on the next sign-in of users who are non-administrators or assigned the following roles only:

• Authentication Administrator
• Directory Readers
• Guest Inviter
• Message Center Reader
• Reports Reader

–

I have assigned the “Authentication Administrator” AAD role to the user “admin.authn.am@iamtec.onmicrosoft.com” at tenant level. So, what is described above that user can do against ANY non-admin user in AAD and members of the specified AAD roles.

Taking the targeted user “john.doe.am1@iamtec.onmicrosoft.com” as an example, after navigating to that user in the AAD Portal, I see the following in the “Authentication Methods” section of that user.

Figure 4: Authentication Methods Section For A User Through The AAD Portal

–

Looking at that I see I can do something with the following because it is not greyed:

• Edit Authentication Info
• Revoke MFA sessions
• Require Re-Register MFA
• Reset Password

–

Everything looks as expected, except for “Reset Password” because the description explicitly mentions “non-password credential”. After trying it, and yes I was able to reset the password of that account while I did not expect to be able to do so. Weird. Probably a bug, but hey it is still in public preview!

Going to the Office 365 Admin Center, I see:

Figure 5: The Properties For A User Through The O365 Admin Center

–

In that portal I cannot find a way to require re-registration of MFA or revoke MFA sessions, but I can reset the password.

–

Trying actions through PowerShell using any of the following CMDlets also work:

Revoke-AzureADUserAllRefreshToken –ObjectId <Object ID Or UPN>

Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName <UPN>

Set-MsolUserPassword -UserPrincipalName <UPN> -NewPassword ‘<Some Text String As Password>’

Set-AzureADUserPassword -ObjectId <Object ID Or UPN> -Password $(ConvertTo-SecureString -String ‘<Some Text String As Password>’ -AsPlainText -Force)

–

Microsoft is really putting a lot of effort in offloading the usage of the “Global Administrator” AAD role to other less powerful AAD roles. This is really a good thing and I can imagine that’s a lot of work due to all the possible AAD roles people can think of for all the richness that AAD has to offer!

Next time, I’ll continue with this and focus more on administrative units

–

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/ ###################
————————————————————————————————————————————————————-

Advertisement