Object outside Tier Zero controls an Entra ID Tier Zero object

An object outside Tier Zero can take over an Entra ID Tier Zero object, such as a Global Administrator.

Category: Attack Path
Severity: At least High.
Typical owner: the identity team that administers Entra ID (and, for synchronized accounts, the Active Directory team)
Data needed: AzureHound output for the tenant, analyzed together with the AD collection. Entra ID support^* covers the directory, not Azure resources.

Most useful toIdentity and access engineers Defensive engineers Offensive operators

On this page

In plain language

Microsoft Entra ID (formerly Azure AD) has its own Tier Zero: the Global Administrator, Privileged Role Administrator and Privileged Authentication Administrator roles, the directory sync accounts, and whoever holds them. Controlling one of them controls every cloud workload and usually, through sync and device management, the on-premises directory too.

The most common mistake is an on-premises account that is synchronized to a Global Administrator: whoever compromises the AD account signs in to Entra ID as the admin. Others include lesser roles that can reset an admin's password, and owners of privileged applications.

What Pathwarden flags

AzureHound data shows that an object outside Tier Zero can take over an Entra ID Tier Zero object: the tenant, a Tier Zero role (Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Directory Synchronization Accounts), or a user, group or service principal that holds one. Typical cases:

An on-premises account holds an Entra admin role. The AD user is synchronized to the Entra user that is Global Administrator (SyncedToEntraUser). Whoever controls the AD account (resets its password, or reads its password from a computer it logs on to) signs in to Entra ID as the administrator. This is the most common hybrid Tier Zero mistake.
A lesser role can take over an admin. A Partner Tier2 Support holder can reset a Global Administrator's password; an Application Administrator can add a secret to a service principal that holds Global Administrator.
An owner. The owner of an application or service principal that holds a Tier Zero role can add a credential to it and sign in as it.
The Entra Connect server outside Tier Zero. It stores the password of the Entra sync account (HasEntraSyncCredential).
A Microsoft Graph application permission. A service principal granted Application.ReadWrite.All can add a secret to any application (AZMGAddSecret), including one whose service principal is Tier Zero. A service principal granted RoleManagement.ReadWrite.Directory or AppRoleAssignment.ReadWrite.All is Tier Zero itself: it can make itself Global Administrator.
A federated identity credential. The application trusts tokens an external issuer gives a subject (a GitHub repository and branch, a Kubernetes service account): whoever can get such a token signs in as the application (AZAuthenticatesTo). The finding names the issuer and subject.

The finding's path shows the step. Roles act through their holders: the finding lists who holds (or is eligible for) the role.

How attackers use it

Entra Global Administrator controls every cloud workload, every Microsoft 365 mailbox and, through Intune, Entra Connect and Azure, usually the on-premises directory too. Attackers who reach Active Directory look for the synchronized accounts and app registrations that lead to it (T1078.004, Cloud Accounts; T1098.001, Additional Cloud Credentials), because these paths cross a boundary most teams don't review together.

Find it with Pathwarden

Data needed: AzureHound output for the tenant, analyzed together with the AD collection. Entra ID support^* covers the directory, not Azure resources.

In the web UI or the HTML report, open the Findings tab and expand PW-031: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-031
# the step-by-step guide on this page, offline
pathwarden guide PW-031
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-031

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

Confirm the step in the Entra admin center: the role assignment (Roles and administrators), the owner (App registrations > Owners, Enterprise applications > Owners), or the account's sync status (Users > On-premises sync enabled).
For a synchronized administrator, create the replacement cloud-only account first and make sure the person can sign in with it (and has MFA) before removing the role from the synchronized one.
Keep a second Global Administrator (a break-glass account) while you work.

How to fix it

Option A: Remove the access (recommended)

Follow the finding's fix text:

Step in the path	Fix
`SyncedToEntraUser` into an admin	Give the role to a cloud-only account (`admin@<tenant>.onmicrosoft.com`), remove it from the synchronized account
`AZHasRole` / `AZRoleEligible`	Remove the role assignment, or make it eligible with approval in Privileged Identity Management
`AZOwns`	Remove the owner
`AZResetPassword`, `AZAddSecret`, `AZAddOwner` from a role	Remove holders of that role who don't need it; or remove the Tier Zero role from the target (a service principal rarely needs Global Administrator)
`HasEntraSyncCredential`	Manage the Entra Connect server as Tier Zero
`AZMGAddSecret`, `AZMGAddOwner`, `AZMGAddMember`	Remove the Microsoft Graph application permission the fix names (Enterprise applications > Permissions), or grant a narrower one (Application.ReadWrite.OwnedBy)
`AZAuthenticatesTo`	Remove the federated identity credential (App registrations > Certificates & secrets > Federated credentials), or narrow its subject to one protected branch or environment
`SyncedToEntraGroup`	Don't give Entra ownerships or permissions to a synchronized group: use a cloud-only group

Option B: Protect the target

Assign administrative roles through role-assignable groups, or put administrators in a restricted management administrative unit: helpdesk, password, user and authentication administrators can then no longer reset them.

PowerShell (Microsoft Graph)

PowerShell

Connect-MgGraph -Scopes RoleManagement.ReadWrite.Directory, Application.ReadWrite.All

# Who holds Global Administrator, and whether each is synchronized
$ga = Get-MgDirectoryRole -Filter "RoleTemplateId eq '62e90394-69f5-4237-9190-012177145e10'"
Get-MgDirectoryRoleMember -DirectoryRoleId $ga.Id | ForEach-Object {
    Get-MgUser -UserId $_.Id -Property UserPrincipalName,OnPremisesSyncEnabled -ErrorAction SilentlyContinue
} | Select-Object UserPrincipalName, OnPremisesSyncEnabled

# Remove a role assignment
Get-MgRoleManagementDirectoryRoleAssignment -Filter "principalId eq '<ObjectId>'" |
    Where-Object RoleDefinitionId -eq '<RoleTemplateId>' |
    ForEach-Object { Remove-MgRoleManagementDirectoryRoleAssignment -UnifiedRoleAssignmentId $_.Id }

# Remove an owner of an application
Remove-MgApplicationOwnerByRef -ApplicationId '<AppObjectId>' -DirectoryObjectId '<OwnerObjectId>'

# Remove a Microsoft Graph application permission from a service principal
# (AppRoleId: e.g. 1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9, Application.ReadWrite.All)
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId '<SpObjectId>' |
    Where-Object AppRoleId -eq '<AppRoleId>' |
    ForEach-Object { Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId '<SpObjectId>' -AppRoleAssignmentId $_.Id }

# List and remove an application's federated identity credentials
Get-MgApplicationFederatedIdentityCredential -ApplicationId '<AppObjectId>' | Select-Object Id, Issuer, Subject
Remove-MgApplicationFederatedIdentityCredential -ApplicationId '<AppObjectId>' -FederatedIdentityCredentialId '<Id>'

Verify the fix

Collect again with AzureHound (azurehound list az-ad) for the same tenant and analyze it together with the AD data. The finding is marked fixed only when that tenant was collected this run (its AZTenant record, users and role assignments are in the file); otherwise it stays open as "can't tell".

Roll back

Re-add the role assignment or owner (New-MgRoleManagementDirectoryRoleAssignment, New-MgApplicationOwnerByRef). Do not re-add administrative roles to a synchronized account: give them to the cloud-only replacement.

References

Microsoft: Privileged roles and permissions in Entra IDlearn.microsoft.com
Microsoft: Protecting Microsoft 365 from on-premises attackslearn.microsoft.com
Microsoft: Use Entra groups to manage role assignmentslearn.microsoft.com
https://learn.microsoft.com/en-us/graph/permissions-referencelearn.microsoft.com
https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federationlearn.microsoft.com
SpecterOps BloodHound docs: SyncedToEntraUserbloodhound.specterops.io
SpecterOps BloodHound docs: AZResetPasswordbloodhound.specterops.io
MITRE ATT&CK T1078.004: Valid Accounts: Cloud Accountsattack.mitre.org
MITRE ATT&CK T1098.001: Account Manipulation: Additional Cloud Credentialsattack.mitre.org

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.