Fix 0x00000567 LSA Database Inconsistency Error

When This Error Shows Up

You're trying to join a machine to a domain, or maybe you're just logging into a Windows Server that was recently removed from a domain. Then boom — you get error 0x00000567. The exact message reads: "The local security authority database contains an internal inconsistency." This usually happens right after a failed domain unjoin, or when you've been bouncing a server between domains without cleaning up the local security database. I've seen it most often on Windows Server 2016 and 2019 after someone runs Remove-Computer and the process gets interrupted by a reboot or network drop.

What's Actually Going On

The Local Security Authority (LSA) keeps a database of security policies, cached credentials, and trust relationships. That database is stored in the Registry under HKEY_LOCAL_MACHINE\SECURITY and sometimes in %SystemRoot%\security\database\. When Windows tries to read that database and finds entries that don't match up — like a domain SID that points to a trust that doesn't exist, or a policy file with a corrupted header — it throws this error. It's not a hardware problem. It's a data problem. The database got out of sync, and LSA can't resolve the conflicts.

The Fix: Step by Step

You have two paths here. Path A is the cleaner one — it rebuilds the database from scratch. Path B is for when you can't get into Windows at all. I'm giving you Path A first because it works for most people.

Path A: Full LSA Database Reset (recommended)

Boot into Safe Mode with Networking. Restart the machine and spam the F8 key during boot. If you're on Windows 10/11 or Server 2016+, hold Shift while clicking Restart in the login screen. Select Troubleshoot > Advanced Options > Startup Settings > Restart, then press 5 for Safe Mode with Networking.
Open Registry Editor as Administrator. Press Win+R, type regedit, right-click it and pick "Run as administrator". You need admin rights for this.
Back up the SECURITY hive. In regedit, click on HKEY_LOCAL_MACHINE. Go to File > Load Hive... but don't load anything yet. Instead, right-click HKEY_LOCAL_MACHINE\SECURITY and select Export. Save it as security_backup.reg. This is your parachute — if something goes sideways, you can double-click that file to restore it.
Delete the SECURITY hive. Right-click HKEY_LOCAL_MACHINE\SECURITY and choose Delete. Yes, it will warn you. Click Yes. The entire security database goes away.
Create a fresh SECURITY hive. Go to File > Load Hive... Browse to C:\Windows\System32\config\SECURITY. This is the actual file on disk. Name it SECURITY when prompted. If it says "file in use", that means Safe Mode didn't fully release it. Reboot into Safe Mode again and try immediately after boot.
Close regedit and restart normally. Once the hive loads, Windows will rebuild the LSA database from scratch. After rebooting, you should see a message saying "Preparing Windows" on first boot — that's normal.
Rejoin the domain. If this machine was domain-joined, you'll need to rejoin it. Go to Settings > System > About > Rename this PC (Advanced) > Change... and enter your domain credentials. Or run this from PowerShell as admin:
```
Add-Computer -DomainName "yourdomain.com" -Restart
```

Path B: When You Can't Boot Even Safe Mode

If the error appears before you can even get to Safe Mode, grab a Windows installation USB. Boot from it, choose Repair your computer > Troubleshoot > Command Prompt. Then run these commands:

cd C:\Windows\System32\config
ren SECURITY SECURITY.old
copy C:\Windows\System32\config\RegBack\SECURITY .

The RegBack folder holds a backup of the registry hives (if your backup policy is turned on — check with reg query "HKLM\System\CurrentControlSet\Control\BackupRestore\FilesNotToBackup"). This restores the last good version of the SECURITY hive. After that, type exit and restart.

What to Check If It Still Fails

If the error comes back, you've got a deeper problem. First, check the System event log for events from source "LSA" with ID 40960 or 40961. Those tell you exactly which policy file is corrupted. Look in C:\Windows\security\database\ for files like seo0001.sdb. If you see one with a date that doesn't match the others, that's your culprit. Delete that file only (after backing it up).

Second, if you're on a domain controller, you can't just delete the SECURITY hive — that breaks Active Directory. In that case, you need to restore the system state from backup. That's a different guide, but the short version is: boot into Directory Services Restore Mode (DSRM), then use wbadmin start systemstaterecovery -version:<date> to roll back the LSA database to a known good state.

Third, check for third-party security software. I've seen McAfee and Symantec endpoint protection lock the LSA database and cause this error when they try to enforce policies that conflict with domain policies. Uninstall them temporarily, reboot, and see if the error goes away.

If none of that works, the real fix might be a clean OS install. I know that sounds drastic, but when the LSA database gets corrupted across multiple hives and backup copies, there's no magic command to fix it. Back up your data, wipe the drive, and start fresh. Then rejoin the domain cleanly.