You're sitting at a domain-joined PC, you type your username and password, and instead of getting to the desktop, you get the cryptic error 0X000008C0 with the message "The user is not allowed to log on from this workstation." I've seen this pop up in the weirdest situations—like when a client's finance guy tried logging into the accounting server, or when a new laptop was cloned from another machine without re-joining the domain. It's not a password problem; it's a trust problem at the machine level.
What Actually Causes This Error
Windows is telling you that the workstation you're using isn't recognized as one of the allowed logon locations for your user account. That's the literal translation. The root cause is almost always one of two things:
- Stale computer account – The computer's domain account doesn't match what the domain controller expects. Happens after a restore from backup, a VM clone, or when the machine was offline for a long time and its password got out of sync.
- User account restrictions – Less common, but someone might have set the "Log On To" list on the user object in Active Directory to exclude this workstation. That's a manual admin thing, easy to miss.
The error code itself (NERR_InvalidWorkstation) is from the old NetBIOS error set. It's been around since Windows NT days. When you see it, the domain controller is saying, "I don't trust this machine to accept logons for this user."
I had a client last month whose entire print queue died because of this—their main file server was a VM that got rolled back to a snapshot from three weeks prior. The computer account password jumped backward, and suddenly every user got this error when trying to access the server's shares. It's sneaky because it only affects domain logons, not local ones.
Step-by-Step Fix
Start with the quickest checks, then move to the heavy stuff. Don't skip the first steps—they're cheap and often solve it.
Step 1: Check the User's Logon Workstations Setting
If you have admin rights on the domain, open Active Directory Users and Computers. Find the user account, right-click, go to Properties, then the Account tab. Look at the "Log On To" button. If it says "The following computers," and this PC isn't in the list, that's your problem. Add it or change to "All computers." That's a five-second fix.
Step 2: Reset the Computer Account
The most common cause is a stale computer account. You can fix it without taking the machine off the domain, but you'll need domain admin credentials. On the problematic workstation, open an elevated PowerShell or Command Prompt and run:
Reset-ComputerMachinePassword -Server <DC-Name> -Credential (Get-Credential)Replace <DC-Name> with your domain controller's hostname. This forces a password reset for the machine account. After it completes, reboot the workstation and try logging on again.
Step 3: Rejoin the Domain (The Nuclear Option)
If the reset doesn't work, the trust is too far gone. Unjoin and rejoin the domain. Here's the sequence:
- Log in with a local admin account (like
.\Administrator). - Go to Settings > Accounts > Access Work or School, or use System Properties (sysdm.cpl).
- Click "Disconnect" from the domain, then restart.
- After restart, rejoin the domain using the same process. Enter your domain credentials when prompted.
- Reboot once more. Your profile should still be intact, but it's a good idea to back up anything critical before doing this.
I've had to do this on machines that were cloned from a golden image without running Sysprep. The SID duplication alone can cause all sorts of trust weirdness, and a rejoin usually clears it up.
Step 4: Check Group Policy (Less Likely, But Possible)
If both the user and computer accounts are clean, there's a chance a GPO is enforcing the "Deny log on locally" or "Deny access to this computer from the network" policy. That's a stretch, but if you're still stuck, run gpresult /R on the workstation to see which policies apply, then look for those specific settings in the GPO editor.
What to Check If It Still Fails
If none of that worked, you're in deeper waters. First, verify that the workstation can actually reach the domain controller. Run nltest /dsgetdc:yourdomain.com and see if it returns a DC. If it doesn't, you've got DNS or connectivity issues, which is a whole different ballgame.
Second, check the event logs on the domain controller for logon failures. Look for Event ID 4625 in the Security log. The error details might give you a subclass code that points to a specific cause—like account disabled, expired password, or workstation restriction.
Finally, if you're dealing with a server that's been restored from snapshot, sometimes the only reliable fix is to restore a more recent snapshot or rebuild the machine. I've wasted hours trying to patch trust issues on a VM that kept reverting—sometimes it's faster to start fresh.
Remember, this error is almost never about the user's actual permissions. It's the machine that's not trusted. Keep that in mind, and you'll fix it faster than most folks.