The Misconception With Global Admins

Microsoft are continuing to break out the roles in Azure Active Directory to help isolate “roles” and grant least privilege access. Although they aren’t quite there yet, it should be rare that you would need to grant global admin rights to an account.

Microsoft recommend that you limit GAs as much as you can and instead look to use designated roles. This excludes the two emergency accounts which should be setup should AAD fail.

Recently, I’ve seen an increase in posts and tweets about some misconception around Global Admins and Azure RBAC. Two main topics being:

• Thinking that Azure Active Directory Roles are the same as Azure RBAC (Infra).
• Comparing Global Admins to Domain Admins

Thinking that Azure Active Directory Roles are the same as Azure RBAC…

Let’s start with the two role-based access controls.

• Azure AD Roles: Manage all your O365 suite and Azure AD integrated application/services. Think Sharepoint, SSO apps, Teams and Exchange.
  
  
• Azure RBAC: Role based access for your infrastructure and services which sit within your Azure tenant. Think subscriptions, resource groups and Databases.

Here is a diagram which shows the split. As you can see, the two are broken up:

If you choose to grant Global Admins, Owner access to all subscriptions and resources, that account can pretty much dominate your environment. An environment that can be reach over the internet (Portal.azure.com). This is why it’s important to apply additional controls such as Conditional Access, MFA and strong password policies. These aren’t enabled by default though so you’re going to have to implement them yourselves.

So what can a Global Admin do?

Microsoft say “A Global Admin has unlimited access to all management features and most data in all admin centers.”

What that means is, they manage and have access to:

• Azure Active Directory
• Exchange Online
• Sharepoint Online
• Skype for Business
• Microsoft Teams
• OneDrive
• Intune
• Additional Office 365 portals/applications
• Azure joined machines
• Security Access
• Compliance Access
• License Management

Although high-level it may seem harmless for some, it does mean that they:

• Get Security and Azure alerts by default
• Query mailboxes
• Manage data within Sharepoint, Onedrive and Teams
• Escalate privilege for any account
• Reset passwords for privileged accounts
• View and manage users, groups and applications within Azure AD
• Export data from O365 services
• Grant third party applications access your Azure AD
• Manage and remove security controls

Hopefully you can start to see the concern. If your vendor or users are requesting access to manage your Azure environment, it may be Azure RBAC and not Azure roles.

Even if you granted a user ‘Owner’ access to all your Azure subscriptions, they wouldn’t be able to do all the above. They would however be able to manage all resources assigned to those subscriptions which is a different risk.

The main concern is that Global Admins have access to services which often store sensitive or company data. Data which could have laws or legal requirements wrapped around it.

This brings me onto the second part…

Comparing Global Admins to Domain Admins…

As with everything, there will always be some sort of “god” privilege. It doesn’t mean that it needs to be used for every use case though.

We often compare or match privilege when migrating to another platform or environment. This is never the best approach and instead we should take the opportunity to review what exactly is needed.

Domain Admins are not Global Admins. I’ve put together a simply table to show the main differences…

The other difference is access. Traditionally, the domain admin privilege will be contained within your network by default. It’s rare that you would allow you users to login with such privilege remotely and will instead have a separate account to use day to day.

For Azure, the default is over the internet, so the attack surface is greater.

You can put MFA and conditional access in place however, you need to be aware of APIs and legacy protocols which CA doesn’t support.

This means that legacy protocols use single factor with global privilege.

For most though, the authentication will pass Conditional Access, MFA or any additional layers you apply. That is, if done correctly…

If you miss an application, location or accidentally exclude the account, the second factor could be removed.

An example of this would be creating a Conditional Access policy to MFA the Azure Portal. It must be a safety feature but I’ve noticed that the account creating the rule will be excluded by default. That means if you are Global Admin, the rule won’t apply to you. This is something to look out for as it doesn’t notify you.

The levels of access to data is also different for GAs and DAs. Although Domain admins may have local admin access, they might not be able to touch the data inside. Default ACL policies could be in place to strip local admins and restrict based on AD groups or users. This may not be done in O365 as Global Admins are granted access by nature.

This is just a basic overview of the separation of roles but hopefully helps you to understand the big difference around the two. Should you wish to read more, take a look at the useful article below.

https://docs.microsoft.com/en-gb/azure/active-directory/users-groups-roles/directory-assign-admin-roles#available-roles