ERROR_NO_SECRETS 0x000021AC: Fix Missing LSA Secret Material

You ran a service, a scheduled task, or a PowerShell cmdlet and Windows handed you back ERROR_NO_SECRETS (0x000021AC) with the message: The local account store does not contain secret material for the specified account. What's actually happening here is that Windows asked the Local Security Authority (LSA) for the encrypted credential blob tied to an account — a password hash used to log the account on as a service, a gMSA managed password, a machine account secret — and the LSA came back empty-handed. The account exists. The secret attached to it doesn't.

This isn't a permissions problem in the usual sense. It's a missing-data problem. Something removed, corrupted, or never created the secret record under HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets, or the DPAPI layer that protects it can't decrypt it anymore.

The most reliable place to see it fire in the wild is a service logon failure. You change a service account's password in AD Users and Computers but forget to update it in Services.msc, then restart the box. On next boot, LSA tries to log the service on with a secret that no longer matches, and depending on the code path you either get logon failure 1069 or ERROR_NO_SECRETS. Group Managed Service Accounts (gMSAs) hitting a domain controller they can't reach throw it too, because the managed password lives in the directory and the local cached secret may have expired.

Cause 1: The service account password is out of sync with LSA

By far the most common trigger. A service is configured to log on as DOMAIN\svc_sql, the password on that account gets rotated (by policy, by a human, by an automated rotation tool), and the local LSA secret still holds the old value. Windows reboots, tries to start the service, can't authenticate, and the call into LSA to pull the secret returns STATUS_NO_SECRETS.

The fix is direct: re-enter the current password in the service's Log On tab, or reset the account and update the service at the same time.

1. Open services.msc, find the affected service, open Properties.
2. Switch to the Log On tab, re-type the account and password, click Apply.
3. Stop and start the service to confirm.

If it's a scheduled task instead, the same problem lives in Task Scheduler. Open the task, go to the General tab, and re-enter the credentials there too — changing one doesn't update the other. I've watched people fix the service and wonder why the 3 a.m. backup job still fails. Two separate secret stores.

sc config MyService obj= "DOMAIN\\svc_sql" password= "NewP@ssw0rd"

The reason step 3 matters is that the running service process holds the old token in memory until it stops. Restarting forces a fresh LSA lookup against the updated secret.

Cause 2: Corrupted or missing LSA secret entries in the registry

Sometimes the secret isn't out of sync — it's just gone. The SECURITY hive holds two matching pieces of data: the encrypted secret itself under Policy\Secrets\, and its pointer entry under Policy\Secrets\$MACHINE.ACC or a named service entry. If a restore from backup, a registry cleaner, or a botched sysprep touched one side and not the other, you'll see ERROR_NO_SECRETS even though everything looks normal in the UI.

You can't browse that hive as a normal admin. You need to load it offline, or use reg save and inspect the copy.

reg save HKLM\SECURITY C:\temp\security.hiv
reg save HKLM\SAM C:\temp\sam.hiv
reg save HKLM\SYSTEM C:\temp\system.hiv

Then load the saved hive on a bench machine with reg load HKLM\TmpSec C:\temp\security.hiv and look under TmpSec\Policy\Secrets. Any entry with a missing CurrVal value is dead — that's your smoking gun. Copy the hive back with the entries restored from a known-good backup, or if you don't have one, reset the affected account's secret by reassigning the service account.

Don't try to hand-edit the live SECURITY hive. You'll corrupt it and the box won't boot. Always work on the copy.

If you're dealing with the machine account secret specifically ($MACHINE.ACC), the honest fix is to re-join the domain. It's faster than trying to reconstruct the secret, and less likely to blow up later.

Cause 3: DPAPI master key can't decrypt the blob

Underneath all LSA secrets sits DPAPI. Each secret is encrypted with a master key protected by the account's credentials. If the master key is missing, or the user profile that owned it was deleted, or the machine key was reset (a common side effect of cloning a VM without sysprep), then the ciphertext is still sitting there but nothing can decrypt it. LSA reports the same ERROR_NO_SECRETS because from its point of view the secret may as well not exist.

This one shows up most often after cloning. You spin up a VM from a template, forget to run sysprep /generalize, and now two machines share the same DPAPI master key. The second one's secrets are effectively orphaned.

Diagnose by checking the DPAPI event log:

• Event ID 4693 in the Security log — DPAPI master key retrieval failure.
• Event ID 8193 or 8194 in the System log — Crypto/DPAPI errors.
• Look under %APPDATA%\Microsoft\Protect\ for the user master keys, or %WINDIR%\System32\Microsoft\Protect\ for machine-scope keys.

If the master key folder is empty or the keys won't decrypt, you can't recover the old secrets. Reset the affected accounts (service accounts, scheduled tasks, stored credentials in Credential Manager) and let Windows generate fresh master keys on next logon. Then sysprep the template properly so you don't repeat it.

# Check current stored credentials that may need re-creation
cmdkey /list
# Clear a user's DPAPI-protected credentials (do this carefully)
cmdkey /delete:TargetName

For gMSAs, the equivalent issue is the managed password becoming stale because the DC the machine talks to hasn't replicated the latest version. Run Test-ADServiceAccount -Identity gmsa_name from the target host. If it fails with a secrets-related error, force a KDC lookup against a DC in the same site, or reinstall the gMSA on the host with Install-ADServiceAccount.

Quick reference

One last thing: before you go registry-diving, check the timestamp on the last password change for the account. If it's within the last hour, you're probably looking at Cause 1 and the fix is thirty seconds of typing, not a restore. Match the symptom to the table above and work top to bottom. That order saves you the most time because the cheap fixes are first.