Blocking Remote Access for Local Accounts by Group Policy

It is all about security now, and no matter how restrictive we configure our firewall rules and filters, we still got the internal users. They are the ones that click in the wrong places and install the wrong software, and when the wrong stuff get’s into our network, it can do a lot of damage. I’m talking about those viruses and worms that once inside the local network, they can spread trough it by using the local Windows accounts.

We also have those Admins that create local users on servers or workstations and use them to map network drives or run service accounts. Some other issues in using local accounts is the difficulty to detect and audit them due to account logons are not logged centrally on the domain controllers; and let’s not get into the account lock outs and password strengths policies.

In order to block remote logons by local accounts and/or local accounts that are part of the BUILTINAdministrators group, Microsoft added a new feature starting with Windows 8.1 and Windows Server 2012 R2 by introducing two new security identifiers (SIDs).

S-1-5-113: NT AUTHORITYLocal account
S-1-5-114: NT AUTHORITYLocal account and member of Administrators group

Now, whenever a user is logging in or authenticating trough the network using a local account, one, or both of the SIDs mentioned above will be added to the user’s token. It all depends if the account is just a local user or the user is also part of the BUILTINAdministrators group.

For older systems like, Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012 we have to install KB 2871997 in order to make this feature available.

    

Making use of the two SIDs, we can grant or deny access to local users by just using a simple GPO.

 

Creating the GPO

Create a new GPO, right-click it and choose Edit.

Since this is a computer policy, go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignments. Here, we have four security policies that we can take advantage of:

• Deny log on through Remote Desktop Services
• Deny access to this computer from the network
• Deny log on as a batch job
• Deny log on as a service

Double click on any of the security policies listed above then check the Define these Policy settings check-box.

Click the Add User or Group button then Browse then Locations to select our local server from the list, which is actually our domain controller. By leaving the domain in the list it is not going to work, since a domain does not have a local user account.

Now we have a few choices to make: we can either deny remote access to all the local accounts on the servers or workstations where this GPO will be applied/linked or we can deny remote access to the local user accounts and local accounts that are part of the BUILTINAdministrators group. For the sake of this example I am going to choose both, since I want no local accounts or accounts part of the BUILTINAdministrators group the right to remotely access into the servers and workstations. That should be only possible using domain accounts.

After selecting the domain controller as the search location, click Advanced > Find Now. As you can see in the Search results list, we have the two local groups I mentioned at the begging of the article. Select the one for which you want to deny access to, then click OK a few times to close all the windows.

And OK again to save the changes for the security policy setting. Here I am denying remote access to all local user accounts and local accounts that are part of the BUILTIN\Administrators group.

 

The last thing into making this work is to link the GPO to the Computers OU where we want this security policy to apply. Right-click the OU and choose Link an Existing GPO then, from the window that pops-up, select the GPO we just created.

    

Now that we have our GPO configured and linked to the proper OU, let’s see these security policies in action so you can decide if you can implement all of them and which one is a good fit for your environment.

 

Deny log on through Remote Desktop Services

If you configured the Deny log on through Remote Desktop Services policy setting, when a user (even if it’s part of the BUILTIN\Administrators group) tries to connect using a local account to a server or workstation affected by the GPO he or she will be denied access with the bellow message.

To sign in remotely, you need the right to sign in through Remote Desktop Services. By default, members of the Remote Desktop Users group have this right. If the group you’re in doesn’t have this right, or if the right has been removed from the Remote Desktop Users group, you need to be granted this right manually.

The best thing is that using a domain user account, the connection succeeds, off course if the user has the proper rights to do so. What I’m trying to say here is that, a domain user account is not affected by the security policy we just created.

Deny access to this computer from the network

After we configure this security policy in our GPO, local users are restricted even more. Connection using RDP will be denied with the following error message:

The system administrator has restricted the types of logon (network or interactive) that you may use.For assistance, contact your system administrator or technical support.

If users are trying to map a drive using their local user accounts, the connection will also fail.

Logon failure: the user has not been granted the requested logon type at this computer.

    

In case the the mapped drive is already there before the GPO was applied, it will still work, until reboot. After that, the mapped drive will not be able to connect using the local user account credentials.

Deny log on as a batch job

In order to test this, we need to create a batch file and add it to a Task Scheduler job, making sure we create the task to run with a local user account. Also, in the Create Task window, select Run whether user is logged on or not and Run with highest privileges options.

Once we click OK and provide the password for the local user account, we get a message saying that the user has no rights to run this type of job, making our security policy implementation a success.

This task requires that the user account specified has Log on as batch job rights. For more information about setting this policy, see the Task Security Context topic in Help.

    

Deny log on as a service

As the name implies, this security policy setting allows us to deny local users to run as a service account because as you know, a lot of application owners when they install their software, they use the local user to run the service. Once we implement this security policy, no service will be able to run anymore using a local user account, and if they try, they will get an error message like the one bellow.

Windows could not start the <name of the service> service on Local Computer.
Error 1069: The service did not start due to a logon failure.

    

I know you know this, but just as a reminder, make sure you send an organizational announcement before you link the GPO with these security policies to the division/computers OU so application owners can prepare for the change. You might also need to create domain service accounts to replace the local user ones.

 

Summary

In my opinion, these are some great security options that every organization should have, but as I’ve mentioned, you need to prepare for the change. In small to medium businesses it’s easy, because you don’t have a large environment to take care of, but for enterprises…this is where it gets tricky. As always, test, communicate, then implement.