Finding and removing DCSync rights in Active Directory

DCSync is not an exploit. It is the directory replication protocol (MS-DRSR) doing what it was designed to do, asked by someone who should not be asking. Any principal holding two extended rights on the domain naming context can request password data for every account, including krbtgt, from a DC over the network. Tools such as Mimikatz and Impacket's secretsdump make this a one-line operation, and it leaves no file on the DC.

So who holds those rights is one of the most important ACL questions in any domain, and one of the least checked. The ACL pillar guide shows the basic query. This guide covers the full audit: every right that is equivalent to DCSync, the defaults you should expect, how to remove the rest safely, and how to detect use of the rights that must stay.

The rights that add up to DCSync

Replication permissions are extended rights (control access rights) granted on the naming context head, which is the domain object itself (for example DC=corp,DC=example,DC=com):

DCSync of secrets needs Get-Changes plus Get-Changes-All. But you must also count rights that can grant or imply them:

• GenericAll on the domain object includes all extended rights.
• AllExtendedRights, an ExtendedRight ACE with an empty ObjectType, covers every control access right.
• WriteDACL or WriteOwner on the domain object lets the holder grant themselves the two rights at any time.
• Group membership in any group that holds the above, including nested membership.

An audit that only searches for the two GUIDs misses the last four. Attack path tools model all of them as a single DCSync edge.

Measure: enumerate every replication-capable principal

The rightsGuid values are identical in every forest, so they can be hard-coded. Flag every ACE that grants DCSync or can create it:

Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$acl      = Get-Acl -Path "AD:\$domainDN"

$getChanges    = [guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
$getChangesAll = [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
$filteredSet   = [guid]'89e95b76-444d-4c62-991a-0facbeda640c'
$empty         = [guid]::Empty

$findings = foreach ($ace in ($acl.Access | Where-Object { $_.AccessControlType -eq 'Allow' })) {
    $r = $ace.ActiveDirectoryRights
    $why = switch ($true) {
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::GenericAll) } { 'GenericAll'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteDacl) }  { 'WriteDACL'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteOwner) } { 'WriteOwner'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and $ace.ObjectType -eq $empty } { 'AllExtendedRights'; break }
        { $ace.ObjectType -eq $getChangesAll } { 'Get-Changes-All'; break }
        { $ace.ObjectType -eq $getChanges }    { 'Get-Changes'; break }
        { $ace.ObjectType -eq $filteredSet }   { 'Get-Changes-In-Filtered-Set'; break }
    }
    if ($why) { [PSCustomObject]@{ Principal = $ace.IdentityReference.Value; Right = $why; Inherited = $ace.IsInherited } }
}
$findings | Sort-Object Principal, Right | Format-Table -AutoSize

Then expand group principals to their effective members, because an ACE for "IT-Sync-Operators" is only as safe as that group's membership:

$findings.Principal | Sort-Object -Unique | Where-Object { $_ -notmatch '^(NT AUTHORITY|BUILTIN)\\' } |
    ForEach-Object {
        $name = $_.Split('\')[-1]
        $obj = Get-ADObject -Filter "sAMAccountName -eq '$name'" -Properties objectClass
        if ($obj.objectClass -eq 'group') {
            Get-ADGroupMember $obj -Recursive | Select-Object @{n='ViaGroup';e={$name}}, SamAccountName, objectClass
        }
    }

Run the same query against each domain in the forest. Every domain has its own naming context and its own ACL.

Audit: compare against the expected set

In a default domain, the principals that end up holding replication rights on the domain object are:

• Domain Controllers and Enterprise Domain Controllers: the DCs themselves.
• Enterprise Read-only Domain Controllers: Get-Changes only. RODCs do not receive Get-Changes-All.
• Administrators (built-in), which is how Domain Admins and Enterprise Admins get it, plus the broad default rights those groups hold on the domain object.
• SYSTEM.

Everything else needs an owner and a reason. Common findings, and what to do with them:

Other naming contexts, domains and forests

The domain naming context is where password secrets live, so it is where DCSync matters most. The Configuration and Schema partitions have their own replication ACLs too. Nothing there contains password hashes, but write rights on Configuration can affect every domain in the forest (sites, AD CS objects, Exchange configuration). Run the same query against (Get-ADRootDSE).configurationNamingContext and review anything that is not a built-in admin group or DC.

In a multi-domain forest, repeat the audit in every domain. A grant in a child domain exposes that domain's accounts, and Enterprise Admins from the root can reach everything anyway. Across forest trusts, replication rights do not cross the boundary unless someone explicitly granted a foreign principal an ACE. Such a grant shows up as an unresolved SID or a foreign security principal in your output, and it should always be investigated.

Check whenChanged on the domain object and your 5136 history for when an unexpected ACE appeared. A non-default replication grant with no change record is a classic persistence technique.

Enforce: remove what has no owner

Remove individual ACEs, not whole principals, so you do not strip other rights by accident. Back up the full security descriptor first:

$domainDN = (Get-ADDomain).DistinguishedName
(Get-Acl "AD:\$domainDN").Sddl | Out-File "C:\Tier0\Backup\domain-root-$(Get-Date -f yyyyMMdd).sddl"

$acl    = Get-Acl "AD:\$domainDN"
$target = 'CORP\svc-oldaudit'
$acl.Access | Where-Object {
    $_.IdentityReference.Value -eq $target -and -not $_.IsInherited -and
    $_.ObjectType -in @([guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')
} | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$domainDN" -AclObject $acl

If you find a grant that nobody can explain, especially one added recently or held by a low-privileged user, do not just delete it and move on. Treat it as a possible compromise. Preserve the evidence (the SDDL backup, 5136 and 4662 events, the account's logon history), assume every hash in the domain may have been copied, and plan credential resets from the top: krbtgt twice with replication in between, Tier 0 accounts, service accounts, then everyone else. Removing the ACE stops future use. It does nothing about hashes already taken.

For accounts that must keep the rights:

• Put them in the Tier 0 management model. They log on only to Tier 0 systems, have long random or managed passwords, and are excluded from delegation.
• If the product supports it, grant Get-Changes only and test whether the secrets-dependent feature is really in use.
• Prefer a dedicated group per product (for example T0-Repl-EntraConnect) holding the ACE, so membership changes show up in group-change auditing.

Verify and detect

Rerun the measurement script and diff it against your approved list. The output should now match the expected set exactly. Schedule the script weekly and alert on any difference.

For detection, enable Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access > Audit Directory Service Access (Success) on DCs, and confirm that the domain object has a SACL auditing Everyone for the replication control access rights. Then alert on:

• Event 4662 where the object is the domain object, the access mask is 0x100 (Control Access), the properties contain {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} or {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}, and the subject is not a DC computer account. Allowlist the Entra Connect account by name, and only from its server.
• Event 5136 on the domain object where nTSecurityDescriptor is modified. Anyone adding replication rights shows up here. The event IDs reference has field-level detail for both events.

Test the alert in a lab: grant the two replication rights to a dedicated test account, use it to request replication of a single lab user's secrets (for example with an authorized DCSync tool such as Impacket secretsdump), and confirm that a 4662 alert fires naming the test account. Normal DC-to-DC replication during the same window must not alert. Then remove the grant again.

What it breaks

• Password hash sync stops if you remove the rights from the Entra Connect connector account. Keep those rights and harden the account instead.
• Password-audit and ITDR tools that compare hashes against breached lists need Get-Changes-All. Removing it disables that feature. Decide deliberately whether the benefit is worth another Tier 0 credential.
• Legacy Exchange preparation may re-add WriteDACL if someone reruns an old /PrepareAD. Record the fix in your Exchange runbook.
• Custom sync scripts based on DirSync controls need Get-Changes. Removing it makes them fail with access denied. Move them to scoped LDAP reads where possible.

Related reading: the ACL pillar guide, AdminSDHolder and SDProp cleanup for the other ACL that controls privileged objects, and krbtgt rotation if an unexplained DCSync grant suggests the hashes have already left the building.