Fix ERROR_INVALID_LOGON_TYPE (0x00000557) on Windows Server

Quick answer: Open Local Security Policy > User Rights Assignment and remove the user or group from any Deny log on policies, then check the registry key HKLM\SECURITY\Policy\PolAdtEv for corrupted data.

What's going on with error 0x00000557?

I've seen this error mostly on Windows Server 2019 and 2022, especially when someone tries to connect via Remote Desktop or schedule a task. It's infuriating because the user credentials look correct, the network is fine, but Windows just says "nope, invalid logon type."

The trigger is almost always a logon type mismatch. Windows has several logon types—interactive (2), network (3), batch (4), service (5), remote interactive (10), and a few others. Each one can be explicitly denied or allowed via User Rights Assignment in the security policy. When a logon request arrives with a type that's been denied for that user or group, you get 0x00000557.

Step-by-step fix

I'll walk you through the fix that works 90% of the time. Start here.

Step 1: Check User Rights Assignment

1. Press Win + R, type secpol.msc, hit Enter.
2. Go to Security Settings > Local Policies > User Rights Assignment.
3. Look for these policies and double-click each one:
   • Deny log on locally (denies interactive logon, logon type 2)
   • Deny log on through Remote Desktop Services (denies remote interactive, logon type 10)
   • Deny log on as a batch job (denies logon type 4)
   • Deny log on as a service (denies logon type 5)
4. If the user or a group they belong to is listed, remove them and click Apply.

Step 2: Check the logon type in the event

Open Event Viewer (eventvwr.msc), go to Windows Logs > Security. Look for a Logon/Logoff event (ID 4625) around the time of the error. The Logon Type field tells you exactly what type failed. For example:

• Type 2 = Interactive (local console)
• Type 3 = Network (file share, printer)
• Type 10 = Remote Interactive (RDP)

If the logon type is 10 and the user is denied via Deny log on through Remote Desktop Services, that's your culprit. Remove them from that policy.

Step 3: Reset the audit policy if corrupted

Sometimes the security policy registry gets borked. Here's the nuclear option that saved me twice:

1. Open an admin command prompt or PowerShell.
2. Run secedit /export /cfg C:\secpolicy.inf to export current policy.
3. Edit the exported file and remove any lines referencing the user or group from the SeDeny* entries.
4. Run secedit /configure /db C:\Windows\security\local.sdb /cfg C:\secpolicy.inf /areas USER_RIGHTS.

Alternative fix: Registry tweak (advanced)

If the above doesn't work, the registry key HKLM\SECURITY\Policy\PolAdtEv can hold corrupted audit event settings that break logon validation. You'll need PsExec to access the SECURITY hive because even as admin, Windows locks it.

psexec -i -s regedit

Navigate to HKLM\SECURITY\Policy\PolAdtEv and export it as backup. Then delete all values inside PolAdtEv. Reboot. After reboot, Windows recreates the default audit settings. This is extreme but it worked for a client whose entire RDP access was broken on Server 2019.

Prevention tip

Don't use Deny policies unless you absolutely have to. They override Allow policies, and it's easy to accidentally deny a logon type you didn't mean to. Instead, use Allow log on through Remote Desktop Services and add only the users who need RDP access. Keep group membership tidy—put users in groups and apply policies to groups, not individual accounts. That way, removing a user from a group cleans up the policy automatically.

Also, when you create scheduled tasks with the Run whether user is logged on or not option, remember that uses batch logon (type 4). If the user account is denied batch logon rights, the task fails with this error. I've tripped on that myself—always check the task's account against the batch logon policy.