Soft match and hard match: when synchronisation can take over a cloud account
When an Active Directory object is synchronised for the first time, Entra ID checks whether a matching account already exists in the cloud. If it does, the two are merged and the cloud account comes under the control of the on-premises directory. Handy during a migration, this behaviour becomes an attack path when it targets an administrative account.
Source anchor and immutableId
Each synchronised object is linked to its cloud counterpart by a source anchor. In recent Entra Connect installations, it is stored in the ms-DS-ConsistencyGuid attribute of the Active Directory object, usually populated from its objectGUID. On the Entra ID side, this value appears, Base64 encoded, in the onPremisesImmutableId attribute, commonly called the immutableId. As long as the two values match, changes made on premises flow to the cloud.
Hard match and soft match
When a new object comes into synchronisation scope, Entra ID attempts two kinds of matching:
- Hard match: a cloud account already has an immutableId identical to the on-premises object's source anchor. The two are linked.
- Soft match: no immutableId matches, but a cloud account shares the same primary SMTP address or user principal name (UPN). The two are then merged.
In both cases, the cloud account becomes a synchronised account: its attributes are overwritten by those of the on-premises object and, if password hash synchronization is enabled, its password becomes the one set in Active Directory.
The takeover scenario
Picture an attacker who controls an account able to create users in a synchronised organisational unit. They create an on-premises user with the UPN or address of a cloud administrator, give it a password of their choice and wait for the sync cycle. If matching succeeds, they now hold a cloud account whose password they know. Likewise, an attacker able to write the ms-DS-ConsistencyGuid attribute can target a cloud account whose immutableId they know.
Microsoft has introduced protections that limit such matching for cloud accounts holding an administrative role. Their scope has changed over time: check their current status in the documentation and do not rely on them alone.
The principle to remember. An Active Directory compromise must never automatically turn into a compromise of cloud administrative accounts. Any mechanism that lets an attacker cross that boundary should be disabled or tightly controlled.
Locking down matching
Entra ID exposes tenant-level synchronisation settings, which can be changed through Microsoft Graph, to block these mechanisms:
- Block soft match once migrations are complete. It can be re-enabled temporarily if a one-off need arises.
- Block cloud object takeover through hard match, so that a cloud-managed account cannot be converted into a synchronised account this way.
- Keep administrative accounts cloud-only, with a UPN on the
onmicrosoft.comdomain or on a domain not used by any on-premises account. - Restrict the synchronisation scope to the organisational units that need it, and limit who can create objects there.
Monitoring
Entra ID audit logs record changes made by the synchronisation account. A previously cloud-managed account becoming synchronised, or an immutableId change on a privileged account, should raise an alert. On the Active Directory side, changes to ms-DS-ConsistencyGuid made by anything other than the sync account deserve the same attention.
What an audit checks
- The state of the settings that block soft match and hard match takeover.
- Administrative accounts synchronised from Active Directory instead of being cloud-only.
- Cloud accounts whose UPN or address could match an on-premises object.
- The synchronisation scope and the delegations that allow object creation within it.
- Monitoring of cloud accounts being converted into synchronised accounts.