Fix ERROR_DS_SOURCE_AUDITING_NOT_ENABLED (0X00002168) Fast

I know this error is infuriating

You're trying to replicate, query, or do a cross-domain operation in Active Directory, and Windows throws ERROR_DS_SOURCE_AUDITING_NOT_ENABLED (0X00002168) at you. It translates to: "The operation requires that source domain auditing be enabled." The fix is straightforward once you know where to look. I've seen this hit hardest when setting up cross-domain trusts or running repadmin /syncall across forests. Let's get it done.

Quick fix: Enable auditing on the source domain controller

This error fires because the source domain's domain controller doesn't have audit policy turned on for directory service access. You'll need to change that on the domain controller in the source domain (the one that's being queried or replicated from).

1. Open Group Policy Management Console on the source domain's DC. Run gpmc.msc.
2. Edit the Default Domain Controllers Policy (or a custom GPO linked to the Domain Controllers OU in that source domain).
3. Go to: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Audit Policy.
4. Find Audit directory service access. Set it to Success (or Success and Failure). Don't skip this – just 'Success' covers the operations that trigger the error.
5. Close the GPO, run gpupdate /force on the DC, then restart the Active Directory Domain Services service or reboot the DC. I prefer a reboot – it's faster than troubleshooting a stuck audit service.

In my experience, this single GPO change resolves 9 out of 10 cases. The error disappears immediately after the restart.

Why this works

The 0x00002168 error is Windows's way of saying: "I need to log an audit event for this operation, but the audit policy isn't turned on, so I can't proceed." Active Directory replication and cross-domain trust operations rely on audit logs to track security-sensitive actions. Without auditing enabled on the source domain's DC, the system bails. Enabling directory service access auditing tells the DC to write those events, which lets the operation complete.

Think of it like a bouncer at a club – the bouncer (audit log) needs to check IDs (events) before letting anyone in. If the bouncer is missing, the club (AD) locks the door.

Less common variations

Sometimes the GPO fix doesn't take. Here are the edge cases I've hit:

Variation 1: Advanced Audit Policy overrides

If your domain uses Advanced Audit Policy (the newer audit subcategories under Security Settings → Advanced Audit Policy Configuration), the old-style GPO setting might be ignored. Check these subcategories:

• Directory Service Access → Audit Directory Service Access – set to Success.
• Directory Service Replication → Audit Directory Service Replication – set to Success.

I've seen this trip up Windows Server 2019 and 2022 domain controllers that had migrated from older policies.

Variation 2: Registry override

If GPO changes aren't applying (maybe the source domain is a standalone DC without a proper OU structure), you can flip the audit policy directly in the registry:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

But honestly, I've never needed that. GPO is cleaner. The registry key is AuditDirectoryServiceAccess (DWORD, set to 1). Change that if you're desperate, but it's a last resort.

Variation 3: Firewall or network drops

In one case at a client running Windows Server 2016, the error appeared because a firewall was blocking RPC traffic between the DCs. The auditing was already on. The error message was misleading – the actual problem was a stale trust. I fixed it by running netdom trust <SourceDomain> /reset /d:<TargetDomain>. Always check the event logs (Event ID 1126 in Directory Service log) for the real story.

Prevention: Keep auditing enabled

The easiest way to avoid this error is to keep directory service access auditing enabled on all domain controllers in your forest. Set it via the Default Domain Controllers Policy, and forget it. If you ever disable auditing to reduce event log noise (some admins do this – I don't recommend it), remember to re-enable it before any cross-domain operations. Also, verify your audit logs aren't filling up – set a reasonable size like 512 MB per log file and let them overwrite as needed.

That's it. You should be back to work without the 0x00002168 headache. If you're still stuck, grab the exact operation you were trying to run and the event logs from the source DC – that'll tell us where the audit policy is missing.