Fix ERROR_DS_SAM_NEED_BOOTKEY_PASSWORD (0X00002151)

When This Error Shows Up

You reboot a domain controller running Windows Server 2008 R2 or 2012 R2 (and sometimes older builds), and the machine comes up, but Active Directory won't start. You check Event Viewer and find 0X00002151 with a message like "SAM needs to get the boot password". The Directory Service logs will say something close to "The SAM database is encrypted with a boot password that was not supplied."

This isn't random. The culprit here is almost always someone (or a group policy) that enabled the Syskey boot password — and then either forgot it, the password file got corrupted, or the registry key that stores the password hash got mangled during a recent update or power failure. I've also seen it after a failed third-party backup restore that partially overwrote the SAM hive.

What's Actually Happening

Syskey (SysKey.exe) is a legacy encryption tool from the NT 4.0 days. It encrypts the SAM database so password hashes aren't stored in plaintext. When you enable Syskey with a boot password, Windows stores an encrypted version of that password in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\SecureBoot. At boot, the SAM service reads this key, decrypts it with the local machine's startup key (also stored in the registry), and uses it to unlock the SAM database.

If any link in that chain breaks — the SecureBoot registry value vanishes, the startup key gets corrupted, or someone accidentally deleted the Syskey password file from the system drive — the SAM can't decrypt anything. The service refuses to start, and you get this error.

The Fix: Step by Step

I'm going to give you three levels of fix. Try them in order. Don't skip steps unless you know exactly what broke.

Step 1: Restore the Syskey Password from Backup

If you have the Syskey password file (usually named Startup.key on a floppy or USB stick), boot from a Windows PE environment, copy it back to C:\Windows\System32\config\, and reboot. The SAM will pick it up automatically.

If the file is missing but you know the password, you can re-run Syskey.exe from Safe Mode and re-enter the password. But Safe Mode won't load AD services, so you'll need to boot into Directory Services Restore Mode (DSRM).

Boot into DSRM: F8 at startup -> Directory Services Restore Mode

Once in DSRM, run:

Syskey.exe

Choose "Password Startup" and enter the known boot password. Save. Reboot normally.

Step 2: Edit the Registry to Remove the Boot Password Requirement

If you don't have the password or the key file, you can trick the SAM into not needing one. This is the fix I've used on more than a dozen servers.

1. Boot into DSRM (F8 → Directory Services Restore Mode).
2. Open Regedit. Load the SYSTEM hive from C:\Windows\System32\config\SYSTEM. Name it something like TempHive.
3. Navigate to TempHive\ControlSet001\Control\Lsa.
4. Delete the SecureBoot value (if it exists). If it's not there, look under ControlSet002 or CurrentControlSet.
5. Find the key TempHive\ControlSet001\Control\Lsa\JD — delete the entire JD key. This is the directory that stores the startup key.
6. Close Regedit. When asked to unload the hive, do it.
7. Reboot normally.

This effectively disables Syskey. The SAM will see no boot password requirement and start. Active Directory will load. You'll lose the extra encryption layer, but your domain will function. After AD is up, run ntdsutil to verify the database integrity.

Step 3: Rebuild the SAM and AD (Last Resort)

If the SAM hive itself is corrupt (not just the boot key), none of the above will work. You'll see additional errors like 0X0000214A or 0X0000216. In that case, restore the SAM and SYSTEM hives from a known good backup. Use a Windows PE boot disk to overwrite the files in C:\Windows\System32\config\.

If no backup exists, you're looking at rebuilding the DC. Authoritative restore from AD backup or promote a new DC from scratch.

If It Still Fails

Check three things:

• Disk corruption. Run chkdsk C: /f from DSRM. Bad sectors on the system volume can corrupt the registry hives.
• Boot configuration. Make sure you're actually booting into the correct OS entry (not an old boot.ini pointing at a different system partition). I've seen this error when the BCD points to a stale SYSTEM registry.
• Hardware change. If you swapped the motherboard or RAID controller, the startup key won't match. You'll need to perform a Syskey password reset from DSRM — boot into DSRM, run Syskey.exe, and either re-enter the boot password or switch to System Mode (stored locally).

One last dirty trick: if you're absolutely stuck and the server is a member of a multi-DC domain, seize the FSMO roles to another DC and nuke this one. It's faster than endless debugging.