Getting that pop-up right after you type your password is annoying as hell — I've been there. Let's get you back in.
The Fix: Check Workstation Restrictions in AD
The culprit here is almost always the Log On To setting on the user account in Active Directory. When someone (or a script) restricts a user to specific workstations, and you try to log on from a different one, Windows throws this exact error — even if the password is correct.
- On your domain controller (or a machine with RSAT), open Active Directory Users and Computers.
- Find the user account that's failing.
- Right-click it → Properties → Account tab.
- Look for the Log On To button — it's right below the account options.
- If it's set to "The following computers", you'll see a list of computer names. Either add the current workstation to that list, or (if it's a shared account) switch it to "All computers".
- Click OK, then Apply. Wait a few seconds for replication, then try logging on again.
That's the fix in 90% of cases. Don't bother restarting anything — AD replication picks it up within seconds on a healthy domain.
Why This Happens
This restriction is a security feature, but it's often misconfigured. Someone sets it thinking they're locking down a user, then forgets about it. Or the user gets a new laptop and nobody updates the list. The error message is deliberately vague — it doesn't say "you're not on the allowed list," it just says "not authorized to log on from this station." That's by design, to not leak info about the policy.
The check happens at logon time — the domain controller looks at the workstation name sending the request, compares it to the user's allowed list, and rejects if there's no match.
Less Common Variations
If the AD setting is clean, you're looking at one of these:
1. Local Security Policy on the Machine
Sometimes the restriction is set locally instead of in AD. On the machine you're logging into, run secpol.msc and check:
Security Settings → Local Policies → User Rights Assignment → "Allow log on locally"If your user or group isn't in that list, you're locked out of the console. Same deal for Remote Desktop — check "Allow log on through Remote Desktop Services" if you're connecting via RDP.
2. GPO Pushing a Workstation Restriction
If you're getting this on multiple machines or it keeps coming back after you fix AD, a Group Policy is probably overriding it. Run gpresult /h report.html on the affected machine and look for any policy that sets user logon restrictions. You'll often find it under Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
3. Trust Relationship Broken
Rare, but if the machine's secure channel to the domain is dead, you'll get weird logon errors — including this one. Check with nltest /sc_query:yourdomain.com. If it returns an error, the fix is to rejoin the domain or run Reset-ComputerMachinePassword from an elevated PowerShell.
4. Old Stale Sessions
If you've been switching between accounts or the machine was in a different domain before, a cached session can cause this. Reboot the machine — sounds dumb, but I've seen it clear logon issues that looked like policy problems.
Prevention
Honestly? Stop using workstation restrictions unless you really need them. They're a pain to manage and users change machines constantly. If you must restrict, use AD groups with GPOs instead of the per-user Log On To setting — that way you can add or remove machines by editing a group, not every user account.
Also, document it. If you set a restriction, put a note in the user's AD description or in your ticketing system. Future-you will thank present-you when a user calls at 2 PM on a Monday with this error.
And if you're the one getting locked out constantly — talk to your admin before trying to fix it yourself. I've seen users add themselves to "Allow log on locally" and then wonder why security is upset.
That's it. Check the AD Log On To setting first, then local policy, then think about GPOs. You'll be back in before your coffee gets cold.