Fix 0XC0000070: User Restricted from Workstation

You're staring at this error and it's driving you nuts — I get it. Let's cut to the chase: the culprit here is almost always a workstation restriction set on the user account in Active Directory, or a local security policy that's blocking that user from logging on interactively. Don't bother rebooting the PC or re-entering credentials — that won't fix it. Here's what will.

Quick Fix: Check the User Account's Workstation List in AD

Open Active Directory Users and Computers (dsa.msc) on a domain controller or a machine with RSAT installed.
Find the user account that's getting the error. Right-click it and select Properties.
Go to the Account tab. Look for Log On To at the bottom.
If it says The following computers and the workstation name doesn't match the one the user is trying to log on from — that's your problem.
Change it to All computers or add the correct workstation name. Click OK.
Wait a few minutes for replication, or force it with repadmin /syncall if you're impatient.
Have the user lock and unlock their session or try logging on again.

Why This Works

Windows checks that restriction during NTLM or Kerberos authentication. The client sends its computer name, the domain controller compares it against the list you set in AD. If there's no match, the DC returns error 0XC0000070. Changing it to All computers lifts that restriction.

When AD Looks Clean: Local Security Policy or GPO

If the user account says All computers, the problem is somewhere else. Check these in order:

1. Local Security Policy on the Workstation

This one trips people up. The Deny log on locally or Deny log on through Remote Desktop Services settings can override AD permissions.

Run secpol.msc on the problematic workstation.
Go to Security Settings > Local Policies > User Rights Assignment.
Check Deny log on locally and Deny log on through Remote Desktop Services.
If that user or their group is listed, remove it. Save and run gpupdate /force.

2. Group Policy Overriding Local Settings

Same settings, but pushed from a domain GPO. Run rsop.msc on the workstation to see what's applied. Look under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. If you see a Deny log on locally entry, trace it back to the GPO that's setting it.

Less Common Scenarios

Scenario	What to Check
User is a local admin but still blocked	Check if Deny log on locally includes Administrators group — yes, that happens.
Workstation name was changed recently	AD still has the old name in the logon list. Update it or switch to All computers.
User has multiple accounts (e.g., admin + standard)	Verify you're editing the right account — this error can fire for the wrong one if Kerberos caches a bad ticket.
Smart card or certificate logon	Same AD restriction still applies. Smart card doesn't bypass workstation restrictions.

Prevention: Don't Let It Happen Again

Audit your AD user accounts for workstation restrictions yearly. Script it with PowerShell:

Get-ADUser -Filter * -Properties LogonWorkstations | Where-Object { $_.LogonWorkstations -ne $null } | Select-Object Name, LogonWorkstations

Document why a restriction was set. I've seen admins lock down a user to one PC and then forget about it when the user gets a new laptop. That's a 30-minute support call waiting to happen.
Use Group Policy to set logon rights rather than local policy — it's easier to audit and revert.
When you rename a computer, update AD or remove the workstation restriction at the same time. Add it to your change checklist.

That's it. Nine times out of ten, this error is a stale workstation list in AD. The other time is a deny logon policy hiding in local secpol or GPO. Now you know where to look.