- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
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.
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 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
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
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
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
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.
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.