Aron Smetana: Easily Removing End Users from the Local Administrators Group

Easily Removing End Users from the Local Administrators Group: "

In many enterprises around the globe, the organization policy is to add end users to the local Administrators group on their assigned PC. The reason for that is most likely legacy applications which require administrative privileges in order to run correctly.

However, the greatest risk in setting the end users as local administrators is information security. Here is a little scenario that demonstrates how easy it is to get hold of sensitive information when users are set as local administrators:

Imagine yourself an employee that was 'planned' in your organization by a business competitor and was assigned the task of retrieving documents and Emails which belongs to the CFO. This employee has been accepted to work in a legitimate way and was given a user account and a workstation on which he is defined as local administrator.

Now, this employee performs the following simple tasks:

Creates a local account named 'Whatever'.

Make 'Whatever' a member of the local Administrators group.

Installs a Key-Logger application.

Deletes the account and empty the security log.

At this point, all he has to do is create some sort of problem in his workstation, open a support call, shut down the computer and go home.

Once the technician arrives to the workstation, he will log on using his account (which is probably defined as Administrator on all workstations). The key-logger will log his password and now our dear spy has Administrator privileges on all workstations in the organization.

From now on, the malicious user can install a key logger on any workstation he wants and retrieve the credentials of almost every user in the organization.

As you can see, there is no need for some master hacker that will break through your firewalls in order to perform this simple task.

The obvious cure to that weakness is to remove end users from the local Administrators group. It does sound pretty simple, but once you've done that you will discover that it is quite a challenge.

So what happens if I remove users from the Administrators group?

The most likely problems that will happen once you remove the users from the Administrators group are applications that stop function properly, login scripts that suddenly fail and angry users that will give you thousands of excuses why they must have administrative privileges.

Regarding the angry users, the solution is quite simple. Let the IT manager read the first part of this article and he will make sure he is backed up from the upper management.

Regarding the legacy applications that all of a sudden stop function properly, you can take the longest run, the long run and the easy way.

The longest run

The most proper way to deal with the described situation is to have the relevant software vendors upgrade their products and make them function properly for non-privileged users. However, this task can take a very long time to accomplish and might cost a great deal of money to the organization.

The long run

The most common way to overcome the described issue is to find exactly which permissions are required by the legacy applications (you can do it by using Microsoft's PROCMON - download). This process is quite frustrating and you'll probably find yourself spending long days on finding the exact permissions required. After you've done that, you would have to define it through Group Policy Security Settings and distribute the settings to users. Anyhow, assigning these privileges to end users might make those users too 'Strong'; allowing them to do stuff you wouldn't want them to do!

The easy way

MS Windows supports manual execution of processes using an alternative set of credentials. This means that you can take users out of the local Administrators group, let them log in to windows using their non-privileged account and then execute a specific application (or command) using a separate, privileged account. This can be done by right clicking a desktop shortcut and choosing 'Run As…'

You can also use the command line interface 'RunAs'. However, this is not very useful since you have to provide the password of the privileged user to all users (which takes you right back to square one…). If you are a bit more sophisticated, you can use the RunAs command to save the credentials of a privileged user, and then create a shortcut for the users that does not require them to enter the password.

This sounds like the perfect solution, BUT it does have some major disadvantages: First, there is no secure way to distribute the password to all users, meaning that you will have to enter the password yourself for each user (not very practical). Second, once you entered the password for each user, you pretty much stuck with this password and you probably won't be able to change it in the future.

Luckily for us, there are several tools that help us dealing with this situation. Some of the tools are simple CLI utilities that can pipe the password (but you would still have to expose it). Other tools are more advanced and allow you to create encrypted credentials file and use this file to execute the relevant software.

The most feature-rich tool available is a freeware tool I have recently come across called 'RunAsGUI' by Smart-X (www.smart-x.com)

RunAsGUI comes with a very intuitive wizard-like configuration form that walks you through the steps of setting the encrypted configuration file and creating a desktop shortcut that would run a specific application with a specific user account.

Using RunAsGUI you can store the credentials of a domain or local account which is configured as Administrator in encrypted credentials file and store this file on the network.

In order to support laptop computers which are sometime used offline, RunAsGUI has a build-in cache mechanism that caches the credentials and uses them when the machine is offline. This allows you to easily change the privileged account's password at any time.

Another nice feature is creating a desktop shortcut for an application which once launched the user is prompted to enter alternative credentials. This is most useful in domain migration situations when users might have two accounts for a temporary period of time.

You can also use RunAsGUI to run scripts using a privileged account. RunAsGUI allows you to execute processes in a synchronic or a-synchronic manner, define a timeout and let you choose what to do when the timeout elapses. Using this feature you can easily execute specific commands through login script and make sure they don't take too much time to run when the machine is offline.

On the client side, you can choose to install the client-side RunAsGUI locally on each workstation or simply execute it through a network share without any installation on the client side.

You can download RunAsGUI HERE.