Restricting logon to specific machines

The simple view—and why it’s incomplete

The familiar route is ADUC → user properties → Account tab → Log On To…. Behind that button sits the userWorkstations attribute, a comma-separated list of hostnames a user may log into. If it’s empty, the user can sign in to any machine. If it’s populated, Windows enforces the list.

But reality involves multiple logon types (local interactive vs remote interactive via RDP), precedence rules (deny beats allow), default group memberships (Domain Users ⇒ local Users), and scale limits. In particular, RDP sign-in is controlled by Remote Desktop Services logon rights, not by local interactive logon rights, and Deny variants override Allow. If you only flip one dial, you get surprising results.

Fundamentally,

1. Windows logon types are distinct.

   • Local interactive is console sign-in.
   • Remote interactive is RDP/Terminal Services.

   Policy knobs are separate: “Allow/Deny log on locally” vs. “Allow/Deny log on through Remote Desktop Services.” Don’t mix them.

2. Deny outranks allow. If a user is in both an Allow and a Deny, the Deny wins—applies to both local and RDP logon rights. This is by design in Windows user rights assignment.

3. Default sprawl exists. New domain users inherit Domain Users, which becomes a member of the local Users group on domain-joined endpoints—meaning “log on anywhere” unless you constrain it.

4. userWorkstations is legacy-leaning and bounded. It works, but policy-based device controls are far easier to manage. The GUI has practical limits (commonly cited around ~64 names), making lists unwieldy at scale.

5. RDP has extra gates. Even if “Deny log on locally” blocks console access, users may still RDP if they have the RDP logon right. You must manage both surfaces.

Two control families—and when to use each

User-side restriction (userWorkstations / “Log On To…”): Enforced on the user object. Good for a few named users mapped to a few hosts. Poor at “many users ↔ many machines” and brittle when devices churn.

Computer-side restriction (User Rights Assignment via GPO/Intune): Enforced on the device. You shape which identities may log on to a machine class, e.g., “Only members of Finance-Desktop-Users may sign in to finance PCs.” Works at scale and aligns with OU scoping, security filtering, and modern MDM.

Snippet-friendly contrast: Use userWorkstations for one-off, named allowlists; use User Rights Assignment to manage classes of devices at scale.

The hero section: production-ready patterns and steps

Below are the patterns that work reliably in real environments. Pick the one matching your scenario, or compose them.

Pattern A — “Just this user on just these few machines” (userWorkstations)

When to use: Handful of users, handful of hosts. You accept the attribute’s limits and want fast, explicit allowlists.

Steps (PowerShell):

# Example: restrict jdoe to PC-01 and PC-02
Import-Module ActiveDirectory

Set-ADUser -Identity 'jdoe' `
  -LogonWorkstations 'PC-01','PC-02'

# report which users are restricted
Get-ADUser -LDAPFilter '(userWorkstations=*)' -Properties userWorkstations |
  Select-Object SamAccountName, userWorkstations

• Delegate permission to write userWorkstations if helpdesk will manage it (“Read/Write LogonWorkstation”).
• RDP nuance: In some environments, admins report that for RDP to succeed from A to B, both A (client) and B (target) may need to appear in the user’s allowlist. If you see “credentials incorrect” with a correct password, test this angle.
• Auditing: Some tools don’t surface userWorkstations edits prominently. Ensure AD object auditing for attribute changes.

When not to use: If the list grows or changes frequently, or you need role-based targeting, move to Pattern B/C.

Pattern B — “These users to this pool of workstations” (computer-side: Allow/Deny log on locally)

Goal: Only members of Dept-A-Desktop-Users can sign in locally to Dept-A computers.

1. Create AD groups:
   • Dept-A-Desktop-Users (users allowed local console)
   • Keep Administrators in mind for break-glass access.
2. Create a GPO: Dept-A Local Logon Restriction.
   • Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
   • Configure Allow log on locally to include: Administrators, Dept-A-Desktop-Users.
   • Optionally configure Deny log on locally to include broad groups you never want at consoles (e.g., Domain Users)—but only if exceptions are handled, because Deny trumps Allow.
3. Scope the GPO to the Dept-A Workstations OU. Use security filtering judiciously and avoid over-using WMI filters for performance.
4. Verify with gpresult /r or RSoP.

Why this works: You’re defining which identities may sign in on the device side. It scales with OUs and deployment rings. It is the preferred path over userWorkstations for general use.

Pattern C — “RDP-only control” (computer-side: Allow/Deny log on through Remote Desktop Services)

Goal: Permit RDP access only to a specific group; block everyone else—including users who may be allowed to sign in locally.

1. On the target device class, enable RDP as needed and ensure NLA.
2. In a GPO linked to those computers, set:
   • Allow log on through Remote Desktop Services ⇒ include Administrators and your Approved-RDP-Users group.
   • Deny log on through Remote Desktop Services ⇒ include groups that must never RDP (e.g., Domain Users).
3. Ensure users who need RDP are either local Administrators or members of Remote Desktop Users, and that the Allow right above references the same groups.

Common pitfall: Setting Deny log on locally does not block RDP. Remote logon has its own rights—configure both.

Pattern D — “Tiered admin and PAWs” (authentication policy silos)

Goal: High-privilege identities must only sign in to hardened Privileged Access Workstations (PAWs) and specific servers—never to regular desktops.

Approach: Use Authentication Policies and Authentication Policy Silos to bind accounts to specific hosts and Kerberos conditions. Create a silo, place accounts and hosts, and apply an authentication policy to enforce host restrictions. Note the built-in domain Administrator account is exempt; use separate admin identities.

This is the gold standard for Tier-0/Tier-1 isolation and pairs well with PAWs, LAPS for local admin rotation, and selective admin memberships.

Pattern E — “MDM/Intune-managed endpoints without legacy GPO” (Policy CSP)

Goal: Cloud-managed devices where you still need precise local/RDP sign-in control.

Approach: Configure User Rights with the Policy CSP (e.g., UserRights/AllowLocalLogOn, UserRights/DenyLocalLogOn) via Intune Settings Catalog or OMA-URI. On policy conflicts, make MDM win over GPO using the ControlPolicyConflict knob. Remote Desktop enablement and behavior can also be managed via CSP (RemoteDesktopServices), complementing the user-rights entries.

Subtleties, biases, and silent dependencies

• Token math and group nesting: A user might gain a logon right through nested groups you didn’t expect. Keep the device’s effective rights tight. Prefer Deny for “never ever” groups.
• Local vs domain accounts: Local accounts behave differently and may bypass some domain-centric assumptions. If you allow local sign-ins broadly, remember that blank-password policies and other security options matter. See our note on blocking remote logon for local accounts with blank passwords.
• RDP is a special door: Blocking local logon doesn’t block RDP. Explicitly set RDP allow/deny rights, and align membership in Remote Desktop Users with those rights.
• userWorkstations is brittle at scale: Machines get reimaged/renamed; laptops move; VDI pools are dynamic. Static workstation lists decay—policy-based governance ages better.
• Change visibility: Some telemetry stacks don’t highlight userWorkstations edits. Audit attribute changes and review who can write the attribute.

Expert mental models to design it right

1. Scope by device class, not by user name. Think “which computers should accept which roles,” then enforce via computer-side rights. Use security filtering and OU design to keep blast radius small. See our guides on OU design and security filtering vs WMI filtering.
2. Treat RDP as another perimeter. Manage RDP rights as if they were firewall ACLs. Maintain explicit allowlists, explicit denylists, and continuous validation.
3. Deny for absolutes; allow for the rest. Use Deny sparingly for “this must never happen.” Build normal access around Allow groups. This reduces accidental lockouts while preserving safety barriers.
4. Keep tier boundaries sacred. Admins sign into PAWs; normal desktops reject them. Use authentication policy silos for Tier-0 identities.

Misunderstandings, risks, and the fixes

Misconception 1: “I set Deny log on locally; RDP is blocked.”

Reality: RDP uses remote interactive rights; it still works unless you also deny RDP logon or remove the allow. Fix: Configure Deny log on through Remote Desktop Services explicitly.

Misconception 2: “userWorkstations is the modern way.”

Reality: It’s a legacy control—fine for exceptions, not for scale. Fix: Prefer device-side User Rights Assignment (GPO/Intune) for broad governance.

Misconception 3: “Adding a user to Remote Desktop Users is enough.”

Reality: Membership is necessary but not sufficient—devices must grant the Allow log on through Remote Desktop Services right, and Deny overrides. Fix: Align group membership and rights.

Misconception 4: “We can audit userWorkstations changes easily everywhere.”

Reality: Some platforms don’t surface it well. Fix: Ensure AD object auditing and review of who can write the attribute.

Expert essentials (checklist)

• Define logon policy per device class (local vs RDP).
• Use Allow/Deny rights on computers; reserve userWorkstations for exceptions.
• Remember Deny outranks Allow.
• Verify effective rights with gpresult/RSoP and test both console and RDP.
• For privileged identities, use authentication policy silos + PAWs.

Applications, consequences, and what’s next

• Lateral movement containment: Constraining where credentials can be used makes token theft less profitable and slows attackers. Combine with Credential Guard, LAPS, and attack surface reduction rules.
• Compliance signals: Producing a policy map—who can sign in where, and why—proves least privilege at the endpoint layer.
• Cloud management dominance: As fleets move to Intune, Policy CSP – UserRights becomes the canonical path. The Settings Catalog now includes most user rights, reducing custom OMA-URIs.
• Zero trust endpoint posture: Pair logon restrictions with conditional access to on-prem apps (for example, via Azure AD Application Proxy) and identity isolation for admins.

Worked example: finance desktops with RDP analysts

Scenario: Finance users need local sign-in to finance PCs. A small analyst team needs RDP into a subset of those PCs. Everyone else is blocked.

1. Create groups: Finance-Desktop-Users, Finance-Analyst-RDP.
2. OU: Workstations\Finance. Place target PCs here.
3. GPO #1 “Finance Local Logon”:
   • Allow log on locally ⇒ Administrators, Finance-Desktop-Users.
   • Deny log on locally ⇒ Domain Users (only if this won’t hinder break-glass/local ops).
4. GPO #2 “Finance RDP”:
   • Allow log on through Remote Desktop Services ⇒ Administrators, Finance-Analyst-RDP.
   • Deny log on through Remote Desktop Services ⇒ Domain Users.
   • Ensure those PCs have “Remote Desktop Users” containing Finance-Analyst-RDP.
5. Validate with gpresult /r and attempt both console and RDP from a non-finance account.

Now you’ve precisely bound identities to endpoints with minimal moving parts.

Operations playbook (quick commands and artifacts)

# List restricted users (by attribute)
Get-ADUser -LDAPFilter '(userWorkstations=*)' -Properties userWorkstations |
  Select SamAccountName, userWorkstations

# Set a user's allowed machines
Set-ADUser -Identity 'jdoe' -LogonWorkstations 'PC-01','PC-02'

# Bulk apply from CSV (samAccountName,Workstations)
Import-Csv .\restrictions.csv | ForEach-Object {
  Set-ADUser -Identity $_.samAccountName -LogonWorkstations ($_.Workstations -split ';')
}

Intune Settings Catalog (UserRights): Configure AllowLocalLogOn/DenyLocalLogOn. If legacy GPO competes, enable MDM-over-GP via ControlPolicyConflict.

RDP allow/deny via GPO: Use the two RDP logon rights; remember Deny wins.

Related:

• Group Policy: where these rights live
• Group Policy overview and hygiene
• Security filtering vs WMI filtering
• OU design for clean scoping
• GPO inheritance basics
• Object permissions in AD (delegating safely)
• Local users and groups fundamentals
• Block risky remote logon cases (blank passwords)
• Azure AD Application Proxy for on-prem apps

External:

• User rights assignment – allow/deny log on locally (Microsoft Learn)
• Allow log on through Remote Desktop Services (Microsoft Learn)
• Windows logon scenarios overview (Microsoft Learn)
• Authentication policies & policy silos (Microsoft Learn)
• Policy CSP – UserRights (Intune)

Key takeaways

• Bind identities to device classes, not one-by-one workstations.
• Configure both local and RDP rights; they are separate.
• Reserve Deny for absolutes; keep Allow groups explicit.
• Treat userWorkstations as an exception tool, not your backbone.
• Isolate privileged accounts with authentication policy silos and PAWs.