How to Allow or Deny Workstation Logons for AD Users

By default, when you create new Active Directory users, they are automatically added to the Domain Users group. In its turn, the Domain Users group is added to the local Users group on a domain workstation when it is joined to the AD domain. This means that any domain user can log on to any computer in the domain. In this article, we’ll look at how to allow or deny user logon to the domain computers.

Allow a User to Logon Only to Specific AD Computers

You can specify a list of computers that a user is allowed to logon locally in the properties (attributes) of an Active Directory user account. For example, you want to allow a specific user to log in only on their computers. To do it:

1. Open the ADUC snap-in (Active Directory Users and Computers) by running the dsa.msc command;
2. Use AD search to find the user account you want to restrict and open its properties;
3. Go to the Account tab and click on the “Log On To” button;
4. As you can see, the user is allowed to log on to all domain computers (The user can log on to: All computers). To allow a user to authenticate only on specific computers, select The following computers option and add the names of the computers a user can log on to;
   Note. You must specify the full NetBIOS or DNS computer name (you cannot use wildcards). The value is not case-sensitive.
5. You can add up to 64 computers to this list. If you try to add a 65^th computer, the following error message appears: This property is limited to 64 values. You must remove some of the existing values before you can add new ones;
6. Save the changes. Now the user is allowed to logon only to the specified computers.

Another interesting issue occurs if you restrict the user’s list of computers allowed to log on using the LogonWorkstation attribute. When you try to connect to a remote computer (or RDS farm) via RDP, you may get an error:

The system administrator has limited the computers you can log on with.

To solve this problem, you need to add the computer name from which (!!!) the RDP login is performed to the LogonWorkstation list.

How to Set the User LogonWorkstations Attribute with PowerShell?

It is rather tedious to manually add devices to the list of computers allowed to login to each user’s properties (wildcard is not supported). You can automate this task with PowerShell. The list of computers a user is allowed to logon is stored in the AD user attribute “LogonWorkstations”. For example, our task is to allow a specific user to log on only to the computers, whose names are listed in the text file computers.csv (in this example, the first line of the file should contain the column name – NetBIOSName).

The script can look like this:

Import-Module ActiveDirectory
$ADusername = ‘asmith’
$complist = Import-Csv -Path "C:\PS\computers.csv" | ForEach-Object {$_.NetBIOSName}
$comparray = $complist -join ","
Set-ADUser -Identity $ADusername -LogonWorkstations $comparray
Clear-Variable comparray

Using the Get-ADUser cmdlet, you can display a list of computers a user is allowed to log on to.

Get-ADUser $ADusername -Properties LogonWorkstations | Format-List Name, LogonWorkstations

Or, you can view the list of computers in the ADUC console.

To add a new computername to the list, use this command:

$Wks = (Get-ADUser asmith-Properties LogonWorkstations).LogonWorkstations
$Wks += ",man-b2-wks2"
Set-ADUser asmith -LogonWorkstations $Wks

Configuring Logon Hours for Active Directory Users

You can restrict the login time of the user in the user account properties. For example, you can allow a user to log on to domain computers only during business hours from 8:00 am to 7:00 pm.

1. Open the user properties in the ADUC snap-in, go to the Account tab, and click the Logon Hours button;
2. By default, user logon hours are not restricted (everything is highlighted in blue);
3. Highlight the time ranges where you want to prevent user from logging in and click the Logon Denied button (the color of the logon hours where users are not allowed to sign in will change to white).

If you need to apply the same Logon Hours restrictions to multiple users, the easiest way is to use PowerShell. First, manually configure restrictions for one user, and then use the value of its LogonHours attribute as a template for other users. For example, you want to restrict the logon hours for a group of VPN users:

$template_user='k.muller'
$template_hours= Get-ADUser -Identity $template_user -properties logonHours
Get-ADGroupmember "mun-VPNUsers" |foreach {Set-ADUSer $_.samaccountname -Replace @{logonHours = $template_hours.logonHours} }

If a user tries to logon to the computer outside the allowed hours, they will receive an error:

Account restrictions are preventing this user from signing in. For example: blank passwords aren't allowed, sign-in times are limited, or a policy restriction has been enforced.

There is no built-in functionality in Windows to force a user to logout when the logon hours expire. You can create a simple scheduler task and deploy it through a GPO to run a logoff command.

Also, note the two GPO options under Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.

• Network security: Force logoff when logon hours expire
• Microsoft network server: Disconnect clients when logon hours expire

When these Group Policy settings are enabled, SMB servers will disconnect users whose working hours have expired.

How to Deny or Allow Workstation Logons with Group Policy

In large domains, using the LogonWorkstations user attribute to restrict user access to computers is inconvenient because of limitations and lack of flexibility. You can use Group Policy to implement a more flexible way to allow or deny local logins.

You can restrict the list of users in the local Users group using the Restricted Groups policy (see the example of using Restricted Groups options from the Windows Settings -> Security Settings GPO section to add users to the local Administrators group). But we’ll consider another option.

There are two Group Policy options located in the GPO section Computer Configuration -> Policies -> Security Settings -> Local Policies -> User Rights Assignment:

• Deny log on locally – allows to disable local logon to computers for specific users or groups;
• Allow log on locally – contains a list of users that are allowed to log on to a computer locally.

For example, to prevent users of a security group from logging on to computers in the specific Active Directory Organizational Unit (OU), you can create a separate user group, add it to the Deny log on locally policy, and link the GPO to the OU containing the computers you want to restrict logon to.

In large Active Directory domains, you can use a combination of these policies. For example, you want to prevent users from logging on to computers in other OUs.  To do it, create a security group in each OU, and add all OU users to it.

Then enable the “Allow log on locally” Group Policy option, add this group to it (as well as different administrator groups: Domain Admins, workstation admins, etc.), and link the policy to the OU with the computers. Thus, you will allow only the specific OU users to log on to the computers.

If a user from a different OU (who is not allowed to log on locally) tries to logon to the computer, a window with the following message will appear:

Update the Group Policy settings on the client computers. If a user is not allowed to logon locally, an error message will appear:

You cannot log on because the logon method you are using is not allowed on this computer.  Please see your network administrator for more information.

Or:

The sign-in method you are trying to use isn’t allowed. For more info, contact your network administrator.

Here are some important notes regarding logon restriction policies:

• Don’t apply these policies to restrict access to the servers or AD domain controllers;
  How to allow non-admin users to access domain controllers over RDP.
• Don’t enable these Group Policies through built-in GPOs: Default Domain Policy or Default Domain Controllers Policy;
• A deny policy takes precedence;
• Don’t forget about service accounts (including gMSA), that can be used to run services on computers (servers);
• Don’t apply GPOs that restrict local logon to the entire domain. Link them only to the specific OUs;
• Users will be able to connect to computers using interactive RDP sessions even if the deny local logon policy is enabled. To do this, the RDP protocol must be enabled on the computer, and the user account must be a member of the Remote Desktop Users group.