1 November 2026, 08:13Виталий Лещенко

Windows Server for beginners. Part 32: How are accounts matched, and where are the pitfalls?

All parts of the series “Windows Server for beginners”

In part 31 synchronization created accounts in the cloud from scratch. That rarely happens. Usually, by the time Entra Connect shows up in an organization, the cloud has already had accounts for a year, created by hand when Microsoft 365 was set up: with the same names, with mail, with OneDrive full of documents. Synchronization must not create duplicates but link what already exists, and the rules of that linking are the first half of this final part. The second half is about what synchronization steers around in the domain, and about actions that look harmless as long as an object has no twin in the cloud.

Two kinds of matching

When an object arrives in the cloud from the domain for the first time, Entra ID looks for a pair among its own objects. The check only happens for new objects: if you later change an already synchronized object so that it matches someone else's, you get an error, not a match.

Hard match — on the anchor: the incoming object's sourceAnchor equals the cloud object's immutableId. That's how the link is restored after the sync server is reinstalled or after a move to a new forest that keeps mS-DS-ConsistencyGuid. You can also set the anchor on a cloud account by hand to make it count as the pair of a specific domain account — the Base64 of whatever serves as the anchor: mS-DS-ConsistencyGuid, or objectGUID while that is still empty:

PS C:\> $guid = (Get-ADUser carol).ObjectGUID
PS C:\> $immutableId = [Convert]::ToBase64String($guid.ToByteArray())
PS C:\> Connect-MgGraph -Scopes 'User.ReadWrite.All' -NoWelcome
PS C:\> Update-MgUser -UserId carol@example.com -OnPremisesImmutableId $immutableId

This only works with a cloud-only account that has no anchor yet, and it's the only way to link accounts with different names and addresses. Since July 2026 the cloud also refuses to let a hard match take over an account that is assigned or eligible for a privileged Entra ID role, or an account whose onPremisesObjectIdentifier is already set — that is, one that was once linked to a different domain object.

Soft match — on content, when the cloud object has no anchor. Two criteria:

By address: the primary address in the domain object's proxyAddresses (the value with an uppercase SMTP: prefix; lowercase smtp: values are secondary addresses and don't count) equals the cloud object's primary address.
By UPN: the domain object's userPrincipalName equals the cloud object's UPN. This is a separate tenant feature, SoftMatchOnUpnEnabled, on by default in new tenants.

On a match the cloud object gets an immutableId, becomes synchronized, and from then on hard matching applies. Accounts that hold an administrative role in the cloud are never soft-matched: Entra ID protects them from being taken over from the domain.

No match — the cloud creates a new object. If it turns out to have the same primary address or UPN as an existing one, duplicate attribute resiliency kicks in (it's on in every tenant): the cloud doesn't reject the object but quarantines the conflicting value. A UPN, without which the object can't be created, is replaced with a temporary <prefix><four digits>@<initial domain>.onmicrosoft.com; an address is simply not added. The export counts as successful, and the sync server logs no error: the conflict is visible only in the cloud, in the object's onPremisesProvisioningErrors property (category PropertyConflict, the attribute UserPrincipalName or ProxyAddresses, the conflicting value), and in the synchronization error report sent to the tenant's technical contact:

PS C:\> Connect-MgGraph -Scopes 'User.Read.All' -NoWelcome
PS C:\> Get-MgUser -All -Property UserPrincipalName, OnPremisesProvisioningErrors | Where-Object { $_.OnPremisesProvisioningErrors } |
    Select-Object UserPrincipalName, @{n='Error'; e={$_.OnPremisesProvisioningErrors.Category}}, @{n='Property'; e={$_.OnPremisesProvisioningErrors.PropertyCausingError}}, @{n='Value'; e={$_.OnPremisesProvisioningErrors.Value}}

A typical case: the cloud has carol@example.com with a mailbox, while in the domain carol has the UPN carol@corp.example.com (the suffix isn't verified and becomes carol@example.onmicrosoft.com in the cloud) and the address smtp:carol@example.com written in lowercase, that is, as a secondary one. Neither the UPN nor the primary address matches, a second Carol without mail appears in the cloud, and her address ends up in quarantine. It's fixed before synchronization — with the right UPN and primary address in the domain, which is what IdFix is for — or afterwards with a hard match; the extra object is then deleted in the cloud.

Microsoft advises keeping both kinds of matching off while they aren't needed: the tenant features BlockSoftMatchEnabled and BlockCloudObjectTakeoverThroughHardMatchEnabled are turned off only while cloud accounts are actually being brought under the domain's management, and on again afterwards. Otherwise anyone who can create an object in a synchronized OU can take over a cloud account with the same address — along with its mail and with a password that becomes the domain one after the match.

What happens to the cloud account after matching. It becomes synchronized: every attribute that has a value in the domain is overwritten with the domain's value — if addresses were only ever edited in the cloud and the domain doesn't have them, they are lost. Cloud groups it belonged to remain, domain groups are added. The cloud password stops working — from the first hash synchronization the domain password applies. The mailbox, OneDrive and licenses stay. The user needs to be told one thing: "your password is now your computer password".

Whom not to synchronize

Three categories, each for its own reason.

Emergency access accounts (break-glass): two cloud Global Administrator accounts with UPNs in onmicrosoft.com that depend on neither the domain, nor synchronization, nor federation, nor any single person's phone. Mandatory multi-factor authentication for Microsoft's admin portals applies to them too, so Microsoft recommends signing in to them with a FIDO2 key (a hardware key that signs the sign-in with a private key it never gives out) or a certificate, keeping the keys in a safe and monitoring every sign-in. If synchronization or federation breaks, they are the only way in.

Cloud administrators. An account with the Global Administrator role synchronized from the domain means that a domain administrator (or whoever has compromised a domain controller) becomes a tenant administrator — the password comes from the domain, after all. Microsoft explicitly advises against linking domain accounts to existing administrative cloud accounts: use separate cloud accounts for cloud roles; they don't need to exist in the domain.

Protected domain accounts — members of Domain Admins and the other groups from part 5, which have adminCount = 1, permission inheritance disabled, and a security descriptor rewritten from AdminSDHolder every hour by the SDProp process on the PDC. They can be synchronized, but synchronization treats them differently, and that's worth a closer look.

The MSOL_… account was granted rights on the domain root, and every object inherits them — except the protected ones. That doesn't stop it from reading a protected object: the connector reads the directory with replication rights, which are granted on the root and don't depend on the object's permissions. But it can't write anything to it: with an mS-DS-ConsistencyGuid anchor, Entra Connect can't write objectGUID into it, and password writeback and attribute writeback fail. Every export cycle to the directory ends with a permission-issue error with INSUFF_ACCESS_RIGHTS for such an object, and a password reset from the cloud ends with event 33004 "ADPermissionsError".

If protected accounts are needed in the cloud with writeback after all, the rights are granted not on the objects (SDProp would remove them within the hour) but on AdminSDHolder itself, from which SDProp spreads them to all protected accounts. Entra Connect has the AdSyncConfig module in its installation folder for this: it knows which rights each feature needs, and its cmdlets have an -IncludeAdminSdHolders switch:

PS C:\> Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1'
PS C:\> Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName MSOL_a1b2c3d4e5f6 -ADConnectorAccountDomain corp.example.com -IncludeAdminSdHolders
PS C:\> Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountName MSOL_a1b2c3d4e5f6 -ADConnectorAccountDomain corp.example.com -IncludeAdminSdHolders

Microsoft itself doesn't recommend this switch, and not only out of caution. Here is what sits in AdminSDHolder after Set-ADSyncExchangeHybridPermissions -IncludeAdminSdHolders — read and write of all properties for four classes, as on the domain root:

PS C:\> (Get-Acl 'AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=example,DC=com').Access | Where-Object IdentityReference -like '*MSOL_*' | Select-Object ActiveDirectoryRights, InheritedObjectType, InheritanceType

      ActiveDirectoryRights InheritedObjectType                  InheritanceType
      --------------------- -------------------                  ---------------
ReadProperty, WriteProperty bf967aba-0de6-11d0-a285-00aa003049e2     Descendents
ReadProperty, WriteProperty bf967a9c-0de6-11d0-a285-00aa003049e2     Descendents
ReadProperty, WriteProperty 4828cc14-1437-45bc-9b07-ad6f015e5f28     Descendents
ReadProperty, WriteProperty 5cb41ed0-0e4c-11d0-a286-00aa003049e2     Descendents

Descendents is an entry for child objects only (inherit-only): the module sets it the same way as on the domain root, where it's meant to apply to descendants. SDProp copies it onto a protected account as is, and there it remains an entry "for the user's child objects only" — and a user has none. It doesn't apply to the user itself. Compare how the same rights look on an ordinary user who inherited them from the root and on a protected one:

PS C:\> (Get-Acl "AD:\$((Get-ADUser bob).DistinguishedName)").Access | Where-Object IdentityReference -like '*MSOL_*' | Select-Object ActiveDirectoryRights, InheritedObjectType, InheritanceType, IsInherited

      ActiveDirectoryRights InheritedObjectType                  InheritanceType IsInherited
      --------------------- -------------------                  --------------- -----------
              ExtendedRight bf967aba-0de6-11d0-a285-00aa003049e2             All        True
              WriteProperty 5df2b673-6d41-4774-b3e8-d52e8ee9ff99     Descendents        True
               ReadProperty f0f8ffac-1191-11d0-a060-00aa006c33ed     Descendents        True
ReadProperty, WriteProperty 4828cc14-1437-45bc-9b07-ad6f015e5f28     Descendents        True
ReadProperty, WriteProperty bf967a9c-0de6-11d0-a285-00aa003049e2     Descendents        True
ReadProperty, WriteProperty bf967aba-0de6-11d0-a285-00aa003049e2             All        True
ReadProperty, WriteProperty 5cb41ed0-0e4c-11d0-a286-00aa003049e2     Descendents        True

PS C:\> (Get-Acl "AD:\$((Get-ADUser alice.admin).DistinguishedName)").Access | Where-Object IdentityReference -like '*MSOL_*' | Select-Object ActiveDirectoryRights, InheritedObjectType, InheritanceType, IsInherited

      ActiveDirectoryRights InheritedObjectType                  InheritanceType IsInherited
      --------------------- -------------------                  --------------- -----------
ReadProperty, WriteProperty bf967aba-0de6-11d0-a285-00aa003049e2     Descendents       False
ReadProperty, WriteProperty bf967a9c-0de6-11d0-a285-00aa003049e2     Descendents       False
ReadProperty, WriteProperty 4828cc14-1437-45bc-9b07-ad6f015e5f28     Descendents       False
ReadProperty, WriteProperty 5cb41ed0-0e4c-11d0-a286-00aa003049e2     Descendents       False

On bob, the entry for the user class (bf967aba…) that came from the root has become effective on the object itself — All. On alice.admin the same entry is an explicit copy from AdminSDHolder with Descendents: the MSOL_… account has no rights on her. For an entry in AdminSDHolder to apply to the protected objects themselves, it has to cover the object itself too — for example, the way dsacls sets it by default (/I:T — the object and its children):

PS C:\> dsacls 'CN=AdminSDHolder,CN=System,DC=corp,DC=example,DC=com' /G 'CORP\MSOL_a1b2c3d4e5f6:RPWP;mS-DS-ConsistencyGuid'

But that gives a service account the right to write to domain administrators' accounts — an account that is already guarded like a domain controller. The decision — grant rights on AdminSDHolder or don't synchronize administrators at all — is made once, and the second option is simpler.

A user removed from protected groups keeps adminCount = 1 and disabled inheritance (part 5) — and synchronization treats them as protected until both are reset by hand. A rough check by memberOf finds such users:

PS C:\> Get-ADUser -LDAPFilter '(adminCount=1)' -Properties MemberOf | Where-Object { -not ($_.MemberOf -match 'Domain Admins|Enterprise Admins|Schema Admins|Administrators|Account Operators|Server Operators|Backup Operators|Print Operators') } | Select-Object Name

Name
----
krbtgt

krbtgt is always protected, by itself rather than through a group — leave it alone. The check is rough: memberOf shows neither the primary group nor nested membership, so every account it finds is worth checking by eye. For a real "former administrator" the reset is:

PS C:\> Set-ADUser tfs-build -Clear adminCount
PS C:\> $dn = (Get-ADUser tfs-build).DistinguishedName
PS C:\> $acl = Get-Acl "AD:\$dn"; $acl.SetAccessRuleProtection($false, $true); Set-Acl "AD:\$dn" -AclObject $acl

Password writeback and password protection

Password writeback is the path by which the cloud writes a password into the domain: a user resets a forgotten password on Microsoft's page (self-service password reset, SSPR, which needs an Entra ID P1 license), the cloud passes the new password to the sync server, and the sync server sets it in the domain with the rights from Set-ADSyncPasswordWritebackPermissions: Reset Password and write access to lockoutTime and pwdLastSet. The domain password policy applies: a password that fails it is rejected by the cloud with a message about the organization's policy. The sync server accepts no inbound connections for this: it keeps an outbound HTTPS connection to an Azure Service Bus relay (*.servicebus.windows.net) and to *.passwordreset.microsoftonline.com, and receives requests through it. The log is Application on the sync server, source PasswordResetService: 31001 — a reset request received, 31002 — the password written, 31003 — not written (policy, permissions, a protected account); 31006, 31007, 31008 — the same for a password change. A failure because of permissions on a protected account is 33004 "ADPermissionsError".

Entra Password Protection solves the opposite problem: the cloud's rules for domain passwords. An agent is installed on every domain controller: its password filter library, registered with LSA, passes the new password to the agent service, which checks it against the banned lists — Microsoft's global one and your own (the company name, products, the city) — and rejects it before it reaches the directory. The agents get the list from the cloud through a proxy on any domain server and keep it in SYSVOL; the controllers themselves never go to the internet. The filter runs on every password change and reset on that controller, including Set-ADAccountPassword and a change through Ctrl+Alt+Del, whether or not the user is synchronized — but only where the agent is installed, so it goes on every controller. A controller's password filters are listed in the Notification Packages value:

PS C:\> Invoke-Command dc1 { (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa').'Notification Packages' }
rassfm
scecli

scecli is the security configuration subsystem's filter, rassfm the remote access service's filter; there is no Password Protection agent on this controller.

Hybrid device join

Users are synchronized; machines aren't yet. Microsoft Entra hybrid join registers a domain computer in the cloud: it gets a device certificate from Entra ID, and when a user signs in, Windows obtains a primary refresh token (PRT) from the cloud, which it then uses to sign in to every cloud application without a password and without Seamless SSO. Without device registration you can't have Conditional Access "managed devices only", hybrid Windows Hello for Business, or system-level single sign-on in Office.

What's needed. First, a service connection point (SCP) in the forest's configuration partition: the object that tells machines which tenant to join. It's created by the Entra Connect wizard, the Configure device options task, with Enterprise Admin credentials:

PS C:\> Get-ADObject -SearchBase 'CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com' -Filter 'objectClass -eq "serviceConnectionPoint"' -Properties keywords | Select-Object Name, keywords

Name                                 keywords
----                                 --------
62a0ff2e-97b9-4513-943f-0d221bd30080 {azureADName:example.onmicrosoft.com, azureADId:3a7b1c2d-4e5f-6071-8293-a4b5c6d7e8f9}

The object's name is fixed; keywords holds the tenant's name and ID. Second, computers in the sync scope: in a managed domain (PHS or PTA) a machine registers with a key that Entra Connect uploads to the cloud along with the computer object (the userCertificate attribute), and without the object in the cloud registration won't complete. Third, machines need access to enterpriseregistration.windows.net, login.microsoftonline.com, device.login.microsoftonline.com and, with Seamless SSO, autologon.microsoftazuread-sso.com — including through a proxy as SYSTEM.

The registration itself is done by a scheduled task on every machine:

PS C:\> Get-ScheduledTask -TaskPath '\Microsoft\Windows\Workplace Join\' | Select-Object TaskName, State

TaskName                 State
--------                 -----
Automatic-Device-Join    Ready
Device-Sync           Disabled
Recovery-Check        Disabled

Automatic-Device-Join runs at sign-in and reads the SCP. dsregcmd /status shows the machine's state:

PS C:\> dsregcmd /status | Select-String 'AzureAdJoined|DomainJoined|WorkplaceJoined|AzureAdPrt |DeviceCertificateValidity|KeyProvider'

             AzureAdJoined : NO
              DomainJoined : YES
           WorkplaceJoined : YES
                AzureAdPrt : NO
 DeviceCertificateValidity : [ 2026-10-13 18:31:19.000 UTC -- 2036-10-13 19:01:19.000 UTC ]
               KeyProvider : Microsoft Platform Crypto Provider

This is a domain machine without hybrid join: AzureAdJoined : NO, no PRT. WorkplaceJoined : YES is something else: a user who signed in to Office with a work account registered the device in the cloud for themselves (Entra registered), and the certificate and the key in the TPM (Platform Crypto Provider) belong to that registration. On a hybrid-joined machine both AzureAdJoined and DomainJoined are YES, and after a user signs in, AzureAdPrt : YES.

Failures go to the Microsoft-Windows-User Device Registration/Admin log. Common causes: the machine can't reach the addresses above, the computer object is outside the sync scope, and — less obvious — an SCP left over from a previous tenant. Then every sign-in leaves a pair of errors:

PS C:\> $ids = 304, 420
PS C:\> Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-User Device Registration/Admin'; Id=$ids} -MaxEvents 2 | Format-List TimeCreated, Id, Message

TimeCreated : 15.10.2026 9:23:19
Id          : 304
Message     : Automatic registration failed at join phase.
              Exit code: Unknown HResult Error code: 0x801c03f3
              Server error: The device object by the given id (5f2c9a71-3e4d-4b8a-9c06-1d7e2a4b6c80) is not found.
              Tenant type: Managed
              Registration type: fallback_sync
              Debug Output:
              joinMode: Join
              drsInstance: azure
              registrationType: fallback_sync
              tenantType: Managed
              tenantId: 9d4e2f10-5a6b-4c7d-8e9f-0a1b2c3d4e5f
              configLocation: undefined
              errorPhase: join
              adalCorrelationId: 2c41e7a9-0b3d-4f58-9e6a-71d2c8b5f304
              adalLog:
              undefined
              adalResponseCode: 0x0

TimeCreated : 15.10.2026 9:23:10
Id          : 420
Message     : Automatic registration failed at authentication phase. Unable to acquire Kerberos ticket.
              Exit code: The specified target is unknown or unreachable
              Kerberos endpoint: https://login.microsoftonline.com/9d4e2f10-5a6b-4c7d-8e9f-0a1b2c3d4e5f/kerberos
              SPN: adrs/enterpriseregistration.windows.net

fallback_sync is registration through the synchronized computer object, and the tenant named in the SCP doesn't have it. You can compare the ID in the SCP with the real one using the tenant's public OpenID Connect document, without signing in:

PS C:\> (Invoke-RestMethod 'https://login.microsoftonline.com/example.com/v2.0/.well-known/openid-configuration').issuer
https://login.microsoftonline.com/3a7b1c2d-4e5f-6071-8293-a4b5c6d7e8f9/v2.0

If it doesn't match azureADId in the SCP, the domain's machines are knocking on the wrong tenant's door.

What not to do

With an object that has a twin in the cloud, some ordinary actions have unusual consequences.

Moving a user to an OU outside the sync scope. To synchronization this is a deletion: the object leaves the scope, the cloud is told "delete", and the cloud account goes to the recycle bin for 30 days, taking the mailbox, OneDrive and Teams with it. It can be restored (Restore-MgDirectoryDeletedItem), but the user will notice. The same goes for deleting the user in the domain, but there it's expected.

Bulk operations are protected by a threshold: if in one cycle the export to the cloud wants to delete more than 500 objects, it stops until an administrator allows it. The threshold is visible in the server's global settings (part 31), and every export cycle reports it to the cloud together with counters — event 116 from the Directory Synchronization source in the sync server's Application log:

Calling UpdateDirSyncConfiguration with: [CloudDirSyncConfiguration CustomerRequestedSyncInterval=, ApplicationVersion=, ClientVersion=2.6.92.0 AnchorAttribute= [PreventAccidentalDeletion DeletionPrevention=EnabledForCount, ThresholdCount=500, ThresholdPercentage=0], [CurrentExport DirSyncObjectAdds=0, DirSyncObjectDeletes=0, DirSyncObjectUpdates=0, DirSyncClientMachineName=SYNC1, TotalConnectorSpaceObjects=5], [Writeback UnifiedGroupContainer=, UserContainer=]]

Get-ADSyncExportDeletionThreshold, Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500 and Disable-ADSyncExportDeletionThreshold (temporarily, to let an expected mass deletion through) ask for a tenant administrator account: the threshold is stored in the cloud too. Moving an OU, changing the filter, removing a domain from synchronization — all of these hit the threshold, and that's as it should be.

Changing mS-DS-ConsistencyGuid. It's the anchor. The outbound rule Out to AAD - User Join compares the anchor with what the cloud already knows and raises an error on a mismatch:

IIF(IsPresent([cloudSourceAnchor]), IIF(Word([cloudAnchor],1,"_")=[sourceObjectType],IIF([cloudSourceAnchor] = [sourceAnchor],[sourceAnchor],Error("SourceAnchor attribute has changed.")),[sourceAnchor]),[sourceAnchor])

The object stops synchronizing until the old value is put back in the directory.

Changing a UPN without preparation. A UPN change is synchronized and changes the sign-in name in the cloud (the SynchronizeUpnForManagedUsersEnabled feature, on by default in new tenants); Teams, OneDrive and apps that remembered the old name will ask the user to sign in again, and OneDrive links that contain the UPN go stale. It can be done, but with a warning.

Fixing a cloud object in the cloud. While OnPremisesSyncEnabled = True, the attributes that come from the domain can't be edited in the cloud; everything is done in the domain.

Turning a synchronized object into a cloud one for a migration or to keep a mailbox after someone leaves. For groups Microsoft has a supported way to move the source of authority to the cloud (Group Source of Authority). For users what's left is taking the object out of scope (deletion and restore from the recycle bin as a cloud object) or turning off synchronization for the whole tenant, which takes up to 72 hours and affects everyone. Both paths are unpleasant, and it's better to leave the object disabled in the domain than to take it out.

Giving one person one account for everything. A domain administrator who is also the cloud's Global Administrator, with one password, is one leak for two environments. Separate accounts, separate passwords, multi-factor authentication in the cloud — and the domain doesn't drag the cloud down with it.

Looking at it by hand

An object in the cloud connector space. Objects in the cloud connector are named not by name but by anchor: the DN is CN={…} with the hexadecimal codes of the Base64 string's characters. You can get it from the domain object without going through the metaverse:

PS C:\> $anchor = [Convert]::ToBase64String((Get-ADUser carol).ObjectGUID.ToByteArray())
PS C:\> $dn = 'CN={' + (([Text.Encoding]::ASCII.GetBytes($anchor) | ForEach-Object { $_.ToString('X2') }) -join '') + '}'
PS C:\> Get-ADSyncCSObject -ConnectorName 'example.onmicrosoft.com - AAD' -DistinguishedName $dn | Format-List DistinguishedName, ObjectType, IsConnector, HasExportError, ExportError

DistinguishedName : CN={32522F75436B2F6C526B4B6E33764D574D6C7A467A513D3D}
ObjectType        : user
IsConnector       : True
HasExportError    : False
ExportError       :

3252…3D3D is 2R/uCk/lRkKn3vMWMlzFzQ==, one byte per character. IsConnector: True means the object is joined to the metaverse, and the export has no errors. For an object the cloud didn't accept there would be an ExportError here — for example AttributeValueMustBeUnique, when a new object with a different anchor tries to take the SID or the primary address of an existing one (duplicate attribute resiliency doesn't absorb that kind of conflict). How the cloud sees the same object is shown by Get-MgUser with OnPremisesImmutableId, OnPremisesSyncEnabled and OnPremisesProvisioningErrors — the commands above.

Protected accounts through synchronization's eyes — which of the synchronized users didn't get mS-DS-ConsistencyGuid:

PS C:\> Get-ADUser -SearchBase 'OU=Departments,DC=corp,DC=example,DC=com' -Filter * -Properties adminCount, mS-DS-ConsistencyGuid |
    Where-Object { -not $_.'mS-DS-ConsistencyGuid' } | Select-Object Name, adminCount

Name        adminCount
----        ----------
Alice Admin          1

alice.admin is in the sync scope, with adminCount = 1 and no anchor in the directory: synchronization couldn't write it, and writeback won't work for her either. The right fix isn't rights on AdminSDHolder but moving administrative accounts to an OU outside the scope, so they never reach the cloud. That move deletes the cloud twin, as described above, so first make sure the twin has no mailbox and no licenses.

Sources

Matching and conflicts:

Configure Microsoft Entra Connect for an existing tenant — hard and soft match, overwriting attributes and the password, administrative roles, hard match protections since July 2026;
Microsoft Entra Connect Sync service features — SoftMatchOnUpnEnabled, BlockSoftMatchEnabled, SynchronizeUpnForManagedUsersEnabled;
Identity synchronization and duplicate attribute resiliency — quarantining UPNs and addresses, the temporary UPN;
Troubleshoot errors during synchronization — AttributeValueMustBeUnique, InvalidHardMatch, permission errors;
Design concepts — the anchor, writing objectGUID into mS-DS-ConsistencyGuid and the permission it needs;
Update-MgUser and user resource type — onPremisesImmutableId, onPremisesProvisioningErrors.

Protected accounts and permissions:

Appendix C: Protected Accounts and Groups in Active Directory — AdminSDHolder, SDProp, adminCount, krbtgt;
Configure AD DS Connector Account Permissions — the AdSyncConfig module, rights per feature, -IncludeAdminSdHolders and why it isn't recommended;
ACE_HEADER — the INHERIT_ONLY_ACE flag: the entry doesn't apply to the object it's attached to;
dsacls — /G, /I:T, /I:S;
Manage emergency access admin accounts — emergency access accounts.

Passwords:

How does self-service password reset writeback work — password writeback, the domain password policy;
Troubleshoot self-service password reset writeback — Service Bus addresses, PasswordResetService events 31001, 31002, 31003, 31006, 31007, 31008 and 33004;
Microsoft Entra Password Protection — the agent on domain controllers, the proxy, the policy in SYSVOL;
Installing and Registering a Password Filter DLL — the Notification Packages value.

Devices:

Configure Microsoft Entra hybrid join — the Configure device options task, the SCP, required addresses;
Microsoft Entra hybrid joined devices — what hybrid join gives you;
Primary Refresh Token — the PRT and single sign-on;
Troubleshoot devices by using the dsregcmd command — the dsregcmd /status fields;
Troubleshoot Microsoft Entra hybrid joined devices — registration events and error codes.

Deletions and object management:

Prevent accidental deletes — the deletion threshold, Enable-ADSyncExportDeletionThreshold and Disable-ADSyncExportDeletionThreshold;
Restore-MgDirectoryDeletedItem — restoring from the recycle bin;
Group Source of Authority — moving groups under the cloud's management;
Turn off directory synchronization — turning off synchronization for a tenant.

That concludes the series. Thirty-two parts ago there was an empty server; now there is a forest with four domain controllers in two sites, DNS and DHCP for both address families, a trust with a partner forest, a certification authority, Wi-Fi and VPN authenticated against the directory, Linux servers you sign in to with a ticket, and a cloud the same accounts have moved to. All of it was configured with commands, and every one of them can be repeated — that was the whole point.

What was left outside the series and could get articles of its own: file services and DFS, Hyper-V and failover clusters, Remote Desktop Services, Windows Server Update Services, LAPS and Windows Hello for Business in detail, and monitoring everything described here. If one of these topics is needed before the others, say so in the comments.