This article explains how to deny logon and allow logon locally to Windows workstations.

One of the bigger challenges in some Active Directory environments is controlling who is allowed to log into workstations. By default, every user in AD automatically gets added to Domain Users. Domain Users is, once again by default, included in the local Users group on workstations when the workstations get added to AD. That means that unless you take action on either the user account or the computer configuration, any user account in your AD environment can log into any computer whether you want them to or not. If you’re in a smaller AD environment, this may not be a problem for you: you can go to the Account tab in Active Directory Users and Computers, click the “Log On To…” button and specify the computers the user is allowed to use.

Deny logon - ADUC Account tab Log On To

ADUC Account tab Log On To

However, in a larger environment, managing individual accounts can be very time consuming, especially if you have to manually specify computer names for every single user account that needs limited access. You can also run into other authentication problems using “Log On To…” if the account needs to access network resources.

The good news is that there is a Group Policy setting that works with every version of Windows that can be managed with Group Policy from Windows 2000 through Windows 8 that will solve this problem for you. These settings can be found in Computer Configuration > Policies > Security Settings > Local Policies > User Rights Assignment.

Deny logon - Setting in Group Policy Editor

Deny logon - Setting in Group Policy Editor

Deny log on locally

The “Deny log on locally” specifies the users or groups that are not allowed to log into the local computer. This policy can be found in Computer Configuration > Policies > Security Settings > Local Policies > User Rights Assignment > Deny log on locally.

Deny log on locally Properties

Deny log on locally Properties

In my example, I’ve created a special group just for user accounts that I don’t want logging into an OU of computers. However, you can use any AD group here. Just avoid default AD groups like Domain Users or any of the Admin groups if you don’t want to get locked out.

Allow log on locally

The “Allow log on locally” setting specifies the users or groups that are allowed to log into the local computer. This policy can be found in Computer Configuration > Policies > Security Settings > Local Policies > User Rights Assignment > Allow log on locally.

Allow log on locally Properties

Allow log on locally Properties

In my example, I’ve included the local workstation Administrators group, Domain Admins, and an AD group called “Allow Computer Logons.” With this configuration, only user accounts that are members of the local Admins group on the computer or one of the two AD groups are allowed to log in. Just as a reference, here is the default configuration for Windows 7:

Allow Log on locally Properties in Windows 7

Allow Log on locally Properties in Windows 7

If you happen to be a user that is not authorized to use a computer, here is the message the user will see on Windows XP:

The local policy of this system does not permit you to logon interactively

The local policy of this system does not permit you to logon interactively

And here is the error message they will see on Windows Vista or 7 (the message is the same for both except for the OS name):

You cannot log on because the logon method you are using is not allowed on this computer

You cannot log on because the logon method you are using is not allowed on this computer.

Tips

The Group Policy Management Console references Microsoft Knowledge Base article Q823659 for the Allow log on locally setting. Despite the old-style “Q” naming convention that is referenced, the article is fairly current and still applies to the newer versions of Windows. The KB article gives several examples of harmful configurations and a few more justifications for why you should consider using these two settings.

  • Here are a few things to keep in mind if you decide to implement these settings:
  • DO NOT apply them to Domain Controllers.
  • DO NOT put the settings into either of the default GPO’s for Default Domain Policy or Default Domain Controllers Policy.
  • Deny trumps allow. If a user is in both Allow log on locally and Deny log on locally, Deny always wins.
  • Be on the lookout for software that creates local service accounts that need to be included in Allow Log on Locally. For instance, VMware Workstation and VMware Player have functionality that will not work unless the service account they create is included in Allow Log on Locally.
  • Only apply these settings to sub-sets of computers and not the entire Domain.
52 Comments
  1. Duncan 6 years ago

    Good article. Here are a couple of suggestions in response to some of the comments.

    Scenario 1 – You want to prevent Domain Admins logging in to workstations and member servers.

    Use “Log On To” and list your Domain Controllers for each Domain Admin account. However this doesn’t scale well if you have more than 10 Domain Controllers or 10 Domain Admins. Domain Admins can obviously undo this, but it’s more about enforcing best practice on some of your most trusted IT staff.

    Scenario 2 – You want to restrict “Little Johnnie” to just a few computers.

    You could also use “Log On To”. Alternatively put “Little Johnnie” in Domain Guests and remove them from Domain Users. Then put “Little Johnnie” in a group, and add that group to the local Users group of the computers you want them to have access to.

  2. Ashkar 6 years ago

    Very Helpful Article.

    How could I restrict users logon to any other workstation of my Domain environment. I want to allow every user with a definite workstation. Is there any policy ? Please help me. It’s very urgent need of my organisation.

    Active Directory: Windows Sever 2012 R2

    Clients Machines: Windows 7 & 10

    Thanks in Advance

     

    • If you want that each user can only logon to their own computer, you have to configure this in the Account tab in Active Directory Users and Computers for every user as Kyle explained at the beginning of the article. There can’t be a policy for this because you obviously have to configure this somewhere for each user separately.

      If you have many users, you could name the computers after their users and then write a PowerShell script that modifies the corresponding user object attribute in AD.

      Yet another option is to explain to your management that if users only store files in their user profile, it is not really a problem if users can log on to other machines because Windows ensures that a user’s files are only accessible by the profile owner (and admins, of course).

  3. Cristhiano 5 years ago

    Great discussion in here.

    But how about Windows server 2016…

    This Deny Log on Locally will deny any type of auth for the member of the denied group. Is there a way we can deny log on desktops but still allow ldap auth?

  4. Abhijit Ashok Unawane 5 years ago

    Hello Team,

    I have a system with me which having same issue, i cam not able to login to that system through local account as well as from Domain account, can anyone please suggest on this.

  5. Jayesh Bhatt 5 years ago

    Is there a script to achieve this, as I need to add unique individual user ID in allow logon locally to each of their owned computer in the domain.

  6. Abdul Rahim 5 years ago

    We have blocked a user to “Deny Log on Locally” to his PC, and the same time user went to another user desktop and used the web application and logged in successfully. Is there any way to block all web application including workstation login.

     

  7. Magarsaa 3 years ago

    while i am joining local to domain computer  0"Domain"option is inactive.

    plz help me !

    workstation setting is correct

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account