Fix ERROR_PRIVILEGE_NOT_HELD (0x00000522) on Windows

Quick Answer

Grant the SeImpersonatePrivilege to the account running the service or application. Use secpol.msc → Local Policies → User Rights Assignment → Impersonate a client after authentication.

Why This Happens

Error 0x00000522 means Windows denied a privilege the process needed. The culprit here is almost always the SeImpersonatePrivilege — the right to impersonate another user after authentication. This pops up in three common scenarios:

• A Windows service (like MSSQL or IIS) is configured to run under a domain account that doesn’t have impersonation rights.
• You’re running a scheduled task that tries to access network resources under a different user context.
• A COM+ application or DCOM object fails because the launching user lacks the “Impersonate” right.

I’ve seen this most often with SQL Server Reporting Services (SSRS) and IIS app pools that try to delegate to a remote SQL database. Don’t bother messing with service pack reinstalls or folder permissions — they rarely help here.

Fix Steps

1. Open Local Security Policy
   Press Win + R, type secpol.msc, hit Enter. If you get UAC prompt, click Yes.
2. Navigate to User Rights Assignment
   Go to Security Settings → Local Policies → User Rights Assignment.
3. Find the right privilege
   Scroll down to Impersonate a client after authentication. Double-click it.
4. Add the account
   Click Add User or Group and type the account name (e.g., NT AUTHORITY\NETWORK SERVICE for IIS, or your SQL service account). Click OK twice.
5. Apply and reboot
   Close secpol.msc. Open an admin Command Prompt and run gpupdate /force. Then restart the service that failed. A full reboot is safer — I’ve seen privilege changes not take effect until restart.

Pro tip: If you’re on Windows 10/11 Home edition, secpol.msc isn’t available. Jump straight to the registry fix below.

Alternative Fixes (When the Main One Fails)

Registry Method (Windows Home or Domain Lockdown)

If secpol.msc is blocked or missing, edit the registry directly. Be careful — one typo can break your security policy.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SePrivileges

Create a new DWORD (32-bit) value named SeImpersonatePrivilege and set it to 1. Then add the user SID as a multi-string value under SePrivilegeAssignments. This is tedious — I only do this when I absolutely have to.

Change the Service Account

If you can’t modify policies, switch the failing service to run under Local System or Network Service. These built-in accounts already have impersonation rights.

1. Open services.msc.
2. Right-click the service → Properties → Log On tab.
3. Select Local System account (or Network Service if it needs network access).
4. Apply and restart the service.

Warning: This might break any custom permissions tied to the original account. Test it first.

Check for Group Policy Overrides

On a domain-joined machine, your local policy might get overwritten by domain GPO. Run rsop.msc to see effective policy. If it shows the privilege is missing despite your changes, talk to your domain admin.

Prevention Tips

• Use built-in accounts when possible. They already have the right privileges. Custom service accounts are a pain to configure.
• Document privilege assignments. Write down which accounts have which rights. Saves hours when you migrate servers.
• Test in a non-production environment first. I’ve seen a privilege grant break other apps that relied on the old restriction.
• Keep a baseline. Use secedit /export /cfg C:\security_baseline.inf before any changes. You can revert if something goes wrong.

That’s it. Fix the privilege, restart the service, and you’re done. If you’re still hitting 0x00000522 after this, check the application logs under Windows Logs → Security for more details on exactly which privilege is missing.