Entra ID controls on-premises Tier Zero (hybrid path)

A path starts in Entra ID and ends in on-premises Tier Zero, through password writeback or Intune.

Category: Attack Path
Severity: At least High, or Medium.
Typical owner: the Active Directory team together with the Entra ID (or Intune) team
Data needed: AzureHound output for the tenant, analyzed together with the AD collection, which shows the Entra Connect account's reset rights. Whether writeback is turned on can't be seen in the data: confirm it in Entra Connect. 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

Hybrid identity runs both ways. With password writeback, resetting a synchronized user's password in the cloud also sets it on-premises. With Intune, a cloud administrator can run scripts as SYSTEM on hybrid-joined computers.

So a cloud helpdesk or Intune role, or whoever phishes one of its holders, can end up controlling on-premises Tier Zero. Cloud and on-premises are usually owned by different teams, which is why these paths often go unreviewed.

What Pathwarden flags

A path starts in Entra ID and ends in on-premises Tier Zero. A cloud role, or whoever compromises one of its holders, can take over an Active Directory object that is Tier Zero or has a path to it. Pathwarden reports two crossings today:

Password writeback (SyncedToADUser). The AD account is synchronized to Entra ID, and the Entra Connect connector account can reset its password on-premises. A helpdesk, user or authentication administrator who resets the Entra copy's password sets the AD password too. Pathwarden draws this only when the AD data shows the connector account's reset permission on that account. It can't see whether writeback is turned on, so confirm that in the Entra Connect configuration.
Intune on a hybrid-joined computer (SyncedToADComputer). The AD computer is hybrid joined and Intune-managed, so an Intune administrator can run a script on it as SYSTEM. That takes over the computer, and with it the Tier Zero logons on it.

If the AD object is not Tier Zero itself but has a path to it, the finding says so and its severity starts at medium.

How attackers use it

Cloud administrators are easier to phish than domain admins, and helpdesk roles are widely granted. A path from a cloud role down to a domain admin crosses a boundary that most organizations treat as separate: the cloud team owns one half and the AD team the other (T1098, Account Manipulation; T1072, Software Deployment Tools).

Find it with Pathwarden

Data needed: AzureHound output for the tenant, analyzed together with the AD collection, which shows the Entra Connect account's reset rights. Whether writeback is turned on can't be seen in the data: confirm it in Entra Connect. Entra ID support^* covers the directory, not Azure resources.

In the web UI or the HTML report, open the Findings tab and expand PW-032: 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-032
# the step-by-step guide on this page, offline
pathwarden guide PW-032
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-032

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 crossing:
- password writeback in Entra Connect (Optional features > Password writeback);
- the device's join type and management in Intune (Devices > Windows).
Check whether the account or computer needs to be in sync scope or in Intune at all. Tier Zero accounts and servers rarely do.

How to fix it

Option A: Take Tier Zero out of the cloud's reach (recommended)

Synchronized Tier Zero accounts: exclude them from Entra Connect sync (an OU or attribute filter). Tier Zero administrators use separate, cloud-only accounts in Entra ID and AD-only accounts on-premises.
Writeback permission: remove the Entra Connect connector account's Reset password permission from Tier Zero OUs and accounts. Accounts protected by AdminSDHolder (adminCount=1) don't have it by default, so someone granted it on purpose.
Intune on Tier Zero computers: don't enroll Tier Zero servers, or workstations Tier Zero accounts log on to, in Intune. Otherwise scope Intune administrators to them with Intune RBAC and scope tags.

Option B: Reduce the cloud side

Remove holders of the role in the path who don't need it, and protect those who stay with role-assignable groups and Privileged Identity Management.

PowerShell

# Connector account permissions on a Tier Zero account (Entra Connect module, on the Connect server)
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
Get-ADSyncObjectsWithInheritanceDisabled -SearchBase "<Tier Zero OU DN>"
(Get-Acl "AD:\<Tier Zero account DN>").Access |
    Where-Object { $_.IdentityReference -like '*MSOL_*' } |
    Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

# Remove an explicit reset-password grant for the connector account
$acl = Get-Acl "AD:\<DN>"
$acl.Access | Where-Object { $_.IdentityReference -like '*MSOL_*' -and -not $_.IsInherited } |
    ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl "AD:\<DN>" $acl

Verify the fix

Collect AD data and AzureHound data again and analyze them. The finding is marked fixed only when that tenant was collected this run; otherwise it stays open as "can't tell".

Roll back

Re-add the account to sync scope (and run a sync cycle with Start-ADSyncSyncCycle -PolicyType Delta), re-grant the permission you removed, or re-enroll the device.

References

Microsoft: Self-service password reset writebacklearn.microsoft.com
Microsoft: Configure AD DS connector account permissions (Entra Connect)learn.microsoft.com
Microsoft: Protecting Microsoft 365 from on-premises attackslearn.microsoft.com
SpecterOps BloodHound docs: SyncedToADUserbloodhound.specterops.io
SpecterOps BloodHound docs: AZExecuteCommandbloodhound.specterops.io
SpecterOps: Hybrid attack paths, new views (2024)specterops.io
MITRE ATT&CK T1098: Account Manipulationattack.mitre.org
MITRE ATT&CK T1072: Software Deployment Toolsattack.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.