How to Remove DCSync Permissions from Non-Admin Accounts

DCSync permissions are two extended rights on the Active Directory domain root, Replicating Directory Changes and Replicating Directory Changes All. An account holding both can make a domain controller hand over password hashes, including krbtgt. Fix it by removing them from every principal that is not a domain controller, built-in admin group or documented sync account.

The removal takes minutes. The work is in deciding which holders are legitimate, and in finding out why the others were ever granted.

What the scanner is actually detecting

This is a permissions finding, not a missing patch. The tool reads the access control list (ACL) on the domain root object (for example DC=contoso,DC=com) and flags principals that hold replication rights without being in the expected privileged set.

The rights involved are control access rights defined in the AD schema. The rights GUIDs matter because that is how they appear in raw ACLs and audit events:

Full Control or “All extended rights” on the domain root includes these rights too, so a principal can have DCSync capability without a named replication entry.

Real-world risk

DCSync (MITRE ATT&CK T1003.006) abuses the normal replication protocol that domain controllers use with each other. A holder of both Replicating Directory Changes and Replicating Directory Changes All can request password data for any account from a domain controller over the network, without running code on the DC. With the krbtgt hash an attacker can forge Kerberos tickets (Golden Ticket), and with other account hashes they can authenticate as those accounts.

The limits are worth stating. This is not an unauthenticated exploit: the attacker first needs the credentials or a session of a principal that holds the rights. What makes the finding serious is that such principals are often ordinary service accounts that are not watched like Domain Admins, and Tenable notes that dangerous root permissions are also a persistence technique after a compromise. Replicating Directory Changes alone, without the “All” right, does not include secret data.

How to confirm it on the host

Run these on a domain controller, or on a management host with the Active Directory PowerShell module. Replace the DN with your own.

dsacls "DC=contoso,DC=com" | findstr /i /c:"Replicating Directory Changes"
dsacls "CN=Configuration,DC=contoso,DC=com" | findstr /i /c:"Replicating Directory Changes"
dsacls "CN=Schema,CN=Configuration,DC=contoso,DC=com" | findstr /i /c:"Replicating Directory Changes"

Each matching line names a principal and the right it holds. The findstr filter relies on English display names; the PowerShell version below matches GUIDs, so it works on any language and also catches Full Control and all-extended-rights entries:

Import-Module ActiveDirectory
$dn = (Get-ADDomain).DistinguishedName
$rights = @{
  '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' = 'Replicating Directory Changes'
  '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' = 'Replicating Directory Changes All'
  '89e95b76-444d-4c62-991a-0facbeda640c' = 'Replicating Directory Changes In Filtered Set'
  '00000000-0000-0000-0000-000000000000' = 'All extended rights (or Full Control)'
}
(Get-Acl -Path "AD:$dn").Access | Where-Object {
    $_.AccessControlType -eq 'Allow' -and
    $_.ActiveDirectoryRights.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and
    -not $_.PropagationFlags.HasFlag([System.Security.AccessControl.PropagationFlags]::InheritOnly) -and
    $rights.ContainsKey($_.ObjectType.ToString())
} | Select-Object IdentityReference, @{n='Right';e={$rights[$_.ObjectType.ToString()]}}, ActiveDirectoryRights |
    Sort-Object IdentityReference | Format-Table -AutoSize

A principal that shows up as a group is only half the answer. Expand it, because every member inherits the right:

Get-ADGroupMember -Identity "Legacy-Sync-Admins" -Recursive | Select-Object Name, objectClass, distinguishedName

If Microsoft Entra Connect is installed, identify its connector account on the Entra Connect server so you do not remove it by mistake:

Import-Module "C:Program FilesMicrosoft Azure Active Directory ConnectAdSyncConfigAdSyncConfig.psm1"
Get-ADSyncADConnectorAccount

On newer builds the module may sit under C:Program FilesMicrosoft Entra ConnectAdSyncConfig instead; adjust the path if the import fails.

How to fix it

Decide who keeps the rights

Option 1: Active Directory Users and Computers

This is the procedure Microsoft documents for the Defender for Identity assessment:

1. Open Active Directory Users and Computers and turn on View > Advanced Features. Without it, the domain object has no Security tab.
2. Right-click the domain (for example contoso.local) and select Properties > Security.
3. Select the non-admin user, service account or group.
4. Clear Replicating Directory Changes and Replicating Directory Changes All (and Replicating Directory Changes In Filtered Set if it is checked).
5. Select Apply, then OK.

If the entry comes from Full Control rather than individual checkboxes, open Advanced and remove or edit that permission entry instead.

Option 2: PowerShell, targeted removal

This removes only the replication (and all-extended-rights) entries for one principal and leaves its other permissions alone. It saves the current descriptor first. Run it in the same session as the audit script above, so $dn and $rights are defined:

$path = "AD:$dn"
$acl  = Get-Acl -Path $path
$acl.Sddl | Out-File "C:Tempdomainroot-before-$(Get-Date -Format yyyyMMdd-HHmm).sddl"
dsacls "$dn" > "C:Tempdomainroot-before.txt"

$target = 'CONTOSOsvc-legacy'
$aces = $acl.Access | Where-Object {
    $_.IdentityReference.Value -eq $target -and
    $_.AccessControlType -eq 'Allow' -and
    $_.ActiveDirectoryRights.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and
    -not $_.PropagationFlags.HasFlag([System.Security.AccessControl.PropagationFlags]::InheritOnly) -and
    $rights.ContainsKey($_.ObjectType.ToString())
}
foreach ($ace in $aces) { $acl.RemoveAccessRuleSpecific($ace) }
Set-Acl -Path $path -AclObject $acl

Repeat the same check on the configuration and schema partitions if Tenable Identity Exposure flagged them.

Option 3: dsacls, remove every entry for a principal

When a principal should have no explicit permissions on the domain root at all, /R deletes all of its access control entries on that object:

dsacls "DC=contoso,DC=com" /R CONTOSOsvc-legacy

Do not use /R on the Entra Connect connector account or any group that also carries legitimate permissions on the root. Also avoid /S, which resets the whole object to the schema default.

Then investigate

An unexpected holder is a question, not just a setting. If directory service change auditing is enabled with a SACL on the domain root, event 5136 records modifications to its nTSecurityDescriptor, including who made them. Defender for Identity also raises a separate alert, “Suspected DCSync attack (replication of directory services)”, when a replication request comes from a computer that is not a domain controller. If you cannot rule out that the rights were used, treat the domain as exposed: reset the affected account and consider resetting the krbtgt password twice, which Microsoft recommends doing with at least 10 hours between resets.

For the wider DC baseline, see the Windows Server hardening checklist.

How to verify the fix and rescan

Run the dsacls or PowerShell audit again. Only the principals you decided to keep should remain. ACL changes on the domain root replicate to all DCs like any other directory change, and no reboot is needed.

In Defender for Identity, assessments update in near real time, but scores and statuses refresh every 24 hours, so the recommendation may show as open for a day after the fix. In Tenable Identity Exposure, confirm the principal no longer appears under the Root Objects Permissions Allowing DCSync-Like Attacks indicator.

What can break and how to roll back

• Entra Connect password hash sync stops obtaining hashes if the connector account loses either right.
• MIM/FIM ADMA and SharePoint profile synchronization imports fail without Replicating Directory Changes.
• Third-party identity, backup or password audit tools that read directory data through replication stop working.

To restore the Entra Connect connector account, load the ADSyncConfig module shown earlier and run the cmdlet below as an Enterprise Admin. It sets both rights on the domain root of each domain in the forest:

Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountDN "CN=MSOL_0123456789ab,CN=Users,DC=contoso,DC=com"

For another account, grant the specific right back:

dsacls "DC=contoso,DC=com" /G "CONTOSOsvc-app:CA;Replicating Directory Changes"

The saved dsacls text and SDDL files show exactly what existed before the change.

Common false positive reasons

• The Entra Connect connector account. It needs both rights for password hash sync. Tenable Identity Exposure has a “Keep MSOL_* accounts” option for this indicator; a connector account with a custom name will not match it, so document it as an accepted exception.
• Import-only sync accounts holding Replicating Directory Changes without “All”. They cannot pull secrets, but they may still be listed.
• Read-only domain controller groups, which hold replication rights by design.
• Orphaned SIDs from deleted accounts. The entry is harmless until the SID is reused, but clean it up anyway.

FAQ

What is the difference between Replicating Directory Changes and Replicating Directory Changes All?

The base right replicates ordinary directory data. The “All” right adds secret domain data such as password hashes. DCSync needs both.

Does the Entra Connect account really need DCSync rights?

Only when password hash synchronization is enabled. Without it, the connector account does not need Replicating Directory Changes All.

Can I just deny the rights instead of removing them?

Remove the allow entry. A deny entry is harder to audit later, and a deny on a group also applies to every member of that group, including legitimate ones.

Do I need to reset krbtgt after removing the rights?

Not automatically. Reset it when the account was unexpected and you cannot rule out that it was used to replicate secrets.

Tracking this finding across many hosts

Permission findings like this one can reappear whenever someone delegates rights on the domain root, so it helps to track them over time. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and merges duplicates within each scanner, not across scanners, so the same account reported by two tools stays as two records. Its AI triage can suggest that a finding is a false positive and shows its evidence, but a person makes the decision.

Sources

• Microsoft Learn: Accounts security posture assessments (Remove non-admin accounts with DCSync permissions)
• Tenable: Root Objects Permissions Allowing DCSync-Like Attacks
• Microsoft Learn: DS-Replication-Get-Changes-All extended right
• Microsoft Learn: Configure AD DS Connector account permissions (Entra Connect)
• Microsoft Learn: Dsacls