Fix ERROR_DS_AUTHORIZATION_FAILED (0X00002197) in AD

What's going on with 0x00002197?

You're seeing ERROR_DS_AUTHORIZATION_FAILED with code 0x00002197. This pops up when Active Directory can't verify the credentials or permissions for a directory request. In my experience, it's almost always tied to one of two things: a Domain Controller that was restored from backup without following proper procedures, or a schema version mismatch between DCs after a Windows update.

I've seen this most often after someone restores a DC from an old backup (maybe to recover from a crash) or after a failed in-place upgrade of Windows Server 2016 to 2019. The error shows up in the Directory Services event log and can block logins, joins to the domain, or LDAP queries.

Let's walk through the fixes. Start with the quick check — you might be done in under a minute.

Quick fix (30 seconds): Check the DC's time sync

Before you dig into schema or permissions, check the time on the affected DC. Kerberos is picky — more than 5 minutes off and it'll throw authorization failures that look exactly like this error.

1. Open a Command Prompt as Administrator on the DC showing the error.
2. Run w32tm /query /status and look at the Source and Last Successful Sync Time. You want a source like VM IC Time Synchronization Provider or another DC — not Local CMOS Clock.
3. If the time is off by more than a few seconds, force a sync: w32tm /resync. After running it, you should see The command completed successfully.
4. Wait 30 seconds and recheck the error. If it clears, you're done. If not, move to the moderate fix.

I've seen this simple fix resolve the error more than a dozen times. Don't skip it just because it seems obvious.

Moderate fix (5 minutes): Verify and repair the schema version

If time sync didn't fix it, next check the Active Directory schema version. When you apply Windows updates or upgrade a DC, the schema gets bumped. If one DC didn't get the update, or if a restored DC has an older schema, the authorization check fails because the DCs don't agree on what's allowed.

Step 1: Check the current schema version

1. Open ADSI Edit (add it via Server Manager if it isn't installed — it's under AD DS and AD LDS Tools).
2. Connect to the Default naming context.
3. Browse to CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
4. Right-click the CN=Schema object and choose Properties.
5. Find the attribute objectVersion. Write down the number. For Windows Server 2016 it should be 87, for 2019 it's 88, for 2022 it's 89. If you're on Server 2025, that's version 90.

Step 2: Compare across your DCs

Run the same check on every DC in your domain. If the numbers don't match, the lower-version DC won't authorize requests that need the higher schema. You'll get 0x00002197 on that DC.

Step 3: Update the schema on the low version DC

If one DC is behind, the fix is to run the ADPrep tool that matches the highest version. For Server 2019 to 2022, for example, you run adprep /forestprep and adprep /domainprep from the newer server's installation media. Here's how:

1. On the DC with the higher schema version, insert the Windows Server install media or mount an ISO.
2. Open Command Prompt as Administrator.
3. Navigate to the \support\adprep folder on the media.
4. Run adprep /forestprep. When prompted, confirm you want to update the schema. Wait for Adprep completed successfully.
5. Then run adprep /domainprep. Same deal — wait for success.
6. Reboot the lower-version DC. After it comes back, check the error. Should be gone.

Advanced fix (15+ minutes): Repair a restored DC that's holding old credentials

This is the one that takes longer. If you've restored a DC from backup without using the ntdsutil authoritative restore method, the DC might have a stale copy of the domain's authorization data. It'll reject valid requests because its local state is out of sync with the rest of the domain.

Step 1: Take the DC out of the domain temporarily

1. Log into the DC with local administrator credentials (not domain).
2. Open System Properties (right-click This PC, choose Properties).
3. Click Change settings next to the computer name.
4. Under Member of, select Workgroup, type a temporary name like TEMPWORKGROUP, click OK. Reboot when prompted.
5. After reboot, log in with local admin again.

Step 2: Remove the old AD data

1. Open Server Manager, go to Manage > Remove Roles and Features.
2. Uncheck Active Directory Domain Services. It'll warn you about removing the domain controller role — say yes.
3. The system will demote the DC. Make sure to select Demote this domain controller and choose Force the removal if the DC can't communicate with other DCs.
4. Reboot when the demotion finishes.

Step 3: Rejoin and promote clean

1. Join the server back to the domain via System Properties. Reboot.
2. Log in as domain admin. Open Server Manager and add the AD DS role again.
3. Promote it back to a domain controller. Choose Add a domain controller to an existing domain.
4. Wait for the promotion to finish and reboot.

This wipes out any stale authorization state. I've used this to fix the error on DCs that were restored from backups months old. The whole process takes maybe 20 minutes, but it's thorough.

One last thing

If none of these work, check the event log for a source of the error. Look under Directory Services for events with ID 2886, 2887, or 2888. Those sometimes point to a specific user or group that lost its authorization attribute. But honestly, in my years of doing this, the three fixes above cover 95% of 0x00002197 cases. Start with the time check, then the schema, then the restore fix. You'll get it sorted.