Introduction
I seem to get more and more questions about end user desktops these days. Don’t get me wrong, I love them! I just wish that the whole concept of the end user desktop, user rights, local group membership, and security of these desktops was easier to understand. However, based on the droves of emails I get, it is very complex! So, I want to take this article to define, describe, and solve a few of the security issues that seem to confuse desktop users. In this article we will tackle user rights, local group membership, protecting data, and least privilege.
Defining Terms
First, I must take a few minutes to give you a brief list of definitions. This will help as you read the article, as the terms are always jumbled in conversations and other articles. I try to stay honest with the “true” definitions, but I even sometimes waffle. So, here are some of the definitions that are most important:
User rights – these are “per computer” configurations that control what a user (or group of users preferably) can do to a computer. For example, if you have the user right to “Backup Files” on a desktop, it means that you can back ANY file stored on that desktop, even OS files, files for Administrators, or any other user based files. Basically, it is computer wide, not just individual files/folders.
Permissions – these are what you configure for resource access. A resource is a file, folder, Registry key, printer, or Active Directory object (if on a Domain Controller). Permissions are what you configure on the Access Control List (ACL). Permissions define “who” can do “what” to a resource. Examples might be Read, Modify, Delete, etc.
Local Group – these are groups that are stored in the local Security Accounts Manager (SAM) of a desktop (and member server). Local groups have a scope of only the computer where they reside. So, if a user has membership in a local group, the “power” of their abilities due to this membership only span the computer where the group exists.
Least privilege – this is a concept that was first introduced by the Department of Defense (DoD). The idea is that a user should have the least privilege granted to them for the task they are performing. If a user needs to run a key business application that requires them to be an Administrator, this should be granted to them. However, when they run Microsoft Word, they should still be a standard user.
Overall Desktop Security
For corporate environments, the overall goal is to allow users to run all applications, install key software and drivers, and run operating system features that make the company money, but to do this with the least privilege possible.
What I hear from many administrators is that they want to restrict which desktops a user can logon to, in order to promote this overall desktop security model. Although I can see the point with this method, the method is very laborious and makes the environment very difficult to manage and troubleshoot.
If security is correctly set up on each desktop, then allowing every user to logon to every desktop should not be an issue with regard to that local desktop security. What must be in place should be the correct user rights, permissions, local group membership, and least privilege configuration over applications, installations, and OS features.
User Rights
User rights are settings that control specific aspects of a desktop. In essence, user rights allow or deny higher level capabilities over a desktop. When I say higher level, I mean at the desktop level, not at a file or folder level. When a user right is defined for a desktop, it encompasses that activity on anything on that desktop.
There are some user rights that have a higher risk than others. For example, there is a user right “Shut down the System”. This is something that every user on the desktop should be able to do. So, this is not such a horrible user right for a user to have. However, when you look at the “Act as part of the operating system” user right, that has clear implications that should be restricted to a normal user.
The user rights that I always point out for administrators and auditors to analyze include:
- Act as part of the operating system
- Back up files and directories
- Change the system time
- Create a token object
- Force shutdown from a remote system
- Generate security audits
- Impersonate a client after authentication
- Log on as a batch job
- Log on as a service
- Manage auditing and security log
- Replace a process level token
- Take ownership of files and other objects
You can access these and all other user rights using Group Policy. Locally on a desktop you can access the Local Group Policy by typing gpedit.msc at the Run command, which will open up the local Group Policy editor. If you expand the Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment, you will see all of the user rights, as shown in Figure 1.
Figure 1: User rights within a Group Policy for a Windows 7 computer
Permissions
Permissions control access to resources. Resources include files, folders, Registry keys, and printers on a desktop. The default permissions for most of these resources are secured by default, but any folders and files that are created under the root, C:\, and opened up by the creator of the data is exposed to every user that logs on.
Let’s look at some examples on a default Windows 7 computer.
C:\
Authenticated users – have nearly full control over subfolders and files, but not the root drive itself.
Administrators – have full control over the root drive and all contents under this drive.
Users (Local) – have read only permissions to the root folder and all contents under the root.
C:\Windows
Administrators – have nearly full control over this folder, and have full control over all contents in this folder
Users – have only read and execute permissions
C:\Users\<username>
Administrators – have full control
<username> – has full control
In summary, as long as a user does not have any administrative privileges to the desktop, the files and folders that need to be protected are by default. It is only when a user is granted administrative privileges that inappropriate access is allowed.
To further this concept, it is a bad practice, both at the security level and at the data stability level, to allow users to store files locally. If some files are stored under the user profile, which is then redirected using Folder Redirection, that is adequate. However, to create a folder directly under the root C:\, which is then not secured, but users can store files there, is a very bad decision. These files are not protected (as we see above with the default permissions) and there is no default way to make sure the files are backed up.
Local Group Membership
Here the concept is easy. If a user is placed in the local Administrators group, that user has local administrative access. This means that the user can perform any task, on any resource, and install any application desired. There is no way to control a desktop where the user is local administrator! This is a horrible design and implementation of a corporate desktop.
Least Privilege
As you can see, all of these concepts and ideas lead to one thing. That is that a user should not have local administrative privileges, except for those tasks that are required.
The issue with this is HOW do you accomplish this with a Windows desktop? With the standard set of options, you can either grant access to business applications requiring administrative privileges by adding the user to the local Administrators group, or you can modify all of the permissions and user rights associated with the files, folders, and desktop so the user can ONLY elevate the specified application. With potentially hundreds of applications for a corporation, this is not a very efficient option.
Windows Vista and 7 come with User Account Control (UAC), which does control elevation of user privileges, but unfortunately, with the way this technology works, it does not come close to solving this issue. Rather, it solves other issues, which you can read about in this article.
With the standard operating system not being able to solve the least privilege dilemma, UAC not coming close to solving it, and modification of permissions and user rights causing so much overhead, what options are available to solve least privilege? One of the fastest growing solutions for least privilege today for corporate environments is to extend your existing Group Policy infrastructure. A solution like this allows you to utilize what you already have (with Active Directory and Group Policy), without having to alter domain controllers, Active Directory, install complex solutions, install additional servers, etc. You can check out these solutions here.
Summary
The Windows desktop is full of complexity when it comes to security. Breaking down the options into smaller chunks helps to understand what each option does, as well as how to protect the desktop correctly. Using user rights, permissions, UAC, and local groups correctly goes a long way. However, in the end, you still need to provide least privilege access, which is possible… just not with built-in Microsoft technologies!
