Fix 0X00000531: User Not Allowed to Log On to This Computer

This error pops up when Windows 10/11 or Server blocks a user account from logging on to a specific workstation. The fix is usually in the user account's Log On To settings in Active Directory.

When You'll See This Error

You walk up to a Windows 10 workstation at 8:45 AM, enter your domain credentials, and boom — instead of a desktop you get Logon failure: The user has not been granted the requested logon type at this computer with error code 0X00000531. This hits hardest in domain environments when someone moves a user to a new machine or a junior admin accidentally tweaks the user's Log On To settings. I've seen it most often after migrating user accounts from an old PC to a new one, or after a help desk tech limits a user to one workstation but forgets to update the list.

What's Actually Happening

The error means the user account has a restriction that says "you can only log on to these specific computers." When the domain controller checks the user's logon workstation list, your machine isn't in it. The system rejects the login before you even see a desktop. This is a security feature, but it's also a common footgun when you don't manage the list properly.

The Real Fix

You need to either add the current workstation to the user's allowed list, or remove all restrictions so the user can log on to any domain computer. Here's the step-by-step for a domain environment (Windows Server 2016/2019/2022).

Open Active Directory Users and Computers — On a domain controller or a machine with RSAT tools installed, run dsa.msc or find it under Administrative Tools.
Locate the user account — Drill down to the correct OU. If you're not sure, use the search box in the top-right corner of the MMC snap-in.
Open the user's properties — Right-click the account, choose Properties.
Go to the Account tab — It's the second tab from the left, with a key icon.
Find the Log On To button — It's near the bottom of the Account tab, labeled "Log On To...". Click it.
Check the current setting — You'll see either "All computers" (good) or "The following computers" (the restriction). If it shows "The following computers," that's your problem.
Add the current workstation — Click "Add," type the computer's NetBIOS name (just the name, not FQDN, e.g., WS-103), and click OK. If you're not sure of the exact name, check System properties on the workstation under "Computer name, domain, and workgroup settings."
Apply and close all dialogs — Click OK on the Logon Workstations dialog, then OK on the properties window.
Wait or force replication — Active Directory changes take a few minutes to replicate. If you're in a hurry, run repadmin /syncall on the DC to push the change immediately.
Test the login — Back on the workstation, press Ctrl+Alt+Del and log in again. Should work now.

If You Need to Remove All Restrictions

Instead of adding the machine one at a time, just select "All computers" in the Logon Workstations dialog. This removes the restriction entirely. I'd only do this for users who genuinely need to log on anywhere in the building — not for shared desks or lab machines.

What If You Don't Have AD?

On a standalone Windows 10/11 machine, go to Local Security Policy (secpol.msc), then Security Settings > Local Policies > User Rights Assignment. Look for "Deny log on locally" or "Allow log on locally." If the user (or a group they're in) appears in the deny list, that's the cause. Remove them.

Still Failing? Check These

DNS issues — If the workstation's name doesn't resolve correctly, the DC might reject the login. Run nslookup ws-103 from a DC and make sure it returns the right IP.
Time sync — If the workstation's clock is off by more than 5 minutes, Kerberos authentication fails. Sync with w32tm /resync.
Group Policy — A GPO might override the user's Log On To setting. Check with gpresult /r on the workstation. Look for any policy that restricts logon rights.
Account is disabled or locked — Seems obvious, but double-check. No amount of workstation tweaks will fix a locked account.

Quick tip: I always keep a small script that runs repadmin /syncall across all DCs after making Log On To changes. It saves the 15-minute wait and the user's patience.

That's it. The 0x531 error is almost always a workstation restriction hangup—either explicit or inherited via groups. Once you know where to look, the fix takes under two minutes.