STATUS_LOGIN_WKSTA_RESTRICTION: Fix 0xC0000248 Fast

Cause #1: Active Directory 'Log On To' List Is Too Restrictive

You see 0xC0000248 when a domain user tries to log on from a machine that isn't on their allowed list. The most common cause is the userWorkstations attribute in AD. Someone set it, and now the user can't get in from the new laptop they got last week.

Here's the thing: that attribute is a comma-separated list of computer names. If it's set to anything other than blank (which means allow all), the domain controller checks the workstation name against that list. No match, no logon. Simple.

How to check and fix it

1. Open Active Directory Users and Computers (dsa.msc).
2. Find the user account, right-click, and select Properties.
3. Go to the Account tab.
4. Look at Log On To. If it says The following computers, that's your problem.

The fastest fix is to select All computers — that clears the restriction entirely. If you need to keep it locked down, add the computer name the user is logging on from. Make sure you spell it exactly as the machine's NetBIOS name, not the FQDN.

Don't forget to wait for AD replication or force it with repadmin /syncall if users are in a hurry.

Cause #2: Registry Setting on the Client Blocking Logon

Less common but worth checking when the AD attribute is fine. There's a registry key that can also restrict which workstations an account can use. It's a leftover from older NT-era controls, but it still bites people.

Look at this key on the client machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Check the AllowWorkstationUsers value. If it's set to 0, it blocks users from logging on unless they're in a specific group. That's not your typical environment, but if you've checked AD and it's clear, this is the next place to look.

This usually shows up after someone tried to harden the machine with a security template. The fix is to delete the value or set it to 1. A reboot is required after the change.

Do not bother with Group Policy settings like Deny log on locally unless you've already ruled both of these out — those create different error codes.

Cause #3: Trust Relationship Issues (Less Common but Real)

If the machine's computer account is broken, sometimes you get 0xC0000248 instead of the usual trust error. The DC can't validate the workstation name properly, so it rejects the logon. It's a stretch, but I've seen it on stale computer accounts that were deleted and recreated.

The telltale sign is that the error only appears for domain users, not the local admin. And it happens on every account, not just one.

The fix

Reset the machine account. On the client, run PowerShell as admin:

Reset-ComputerMachinePassword -Server "DC01" -Credential (Get-Credential)

Or do the old-school method: disjoin and rejoin the domain. That always works but takes longer.

After you do that, restart the machine. The user should be able to log in.

Quick Reference Summary

That's it. Start with the AD attribute — it's the culprit in 90% of cases. The registry thing is worth a quick check if you're stuck. The trust issue is the outlier but happens more than you'd think.