Checklist: Lock down Joe User's administrator rights

If you firmly believe users need to be given administrator rights, it's critical that you limit what they can do. Prevent users from abusing their powers with this checklist.

I keep telling you that ordinary user Joe shouldn't be an administrator on his own machine. You keep telling me that's impossible. You say users need to be administrators in order to run software that require it or to configure their own computers when traveling.

Ok, I hear you now. So here's a compromise: If you must make someone an administrator, then limit what he can do. Taking this approach allows you to immediately allow Joe to get his work done while you begin to prevent him from abusing the power.

Here's how to get started:

You may download a printer-friendly version.

 Checklist: Lock down Joe User's administrator rights
Make Joe a member of the local Administrators group on his computer.
Do not make Joe a member of Domain Administrators. The Domain Administrators group has administrative powers throughout the domain. Making Joe a member gives him the
ability to administer servers, domain controllers (DC) and every workstation. Talk about creating havoc. Joe can add a new DC, add a new remote access server, add a
new DHCP server ... you name it, he can do it, including destroy your entire domain-wide infrastructure and get a leg up on doing the same to other domains in the forest.
To make Joe a member of his local Administrators group, open Start/Administrative Tools/Computer Management console. Expand Local Users and Groups/Groups node.
In the details pane, right click on the Administrators group and select "Add to Group." Click the Add button and use the object picker to locate and select Joe's domain user account.
Decide which rights Joe does not need.
This is where the fun begins. The administrator has powerful rights on the computer, and I'm sure there are many that Joe doesn't need. Before you remove them, you need to
know what they do and what can happen if you remove them. This week I'll fill you in on a very powerful one: Debug Programs. Whether you remove this right or not has to be
your call. I'll help you discover some other rights another time.
The Debug Program right enables the holder to access all areas of the operating system. It's meant to provide a programmer or administrator the ability to attach a debugger
(a program than helps them debug programs) to any process running on the system. You may think that Joe Programmer needs this right, but he only needs it on his own
computer if he will be debugging programs other than his own. Likewise, I doubt Joe User will need it to debug code on his own system. That's the job of a real administrator.
If the program doesn't work or throws errors, he needs to report it because it's likely to be a problem elsewhere.
However, there is another critical use of this right that may surprise you. Some versions of the Microsoft update.exe program, which is used to install patches, require the person
running this program to have the Debug Programs right. Otherwise, update.exe will fail and possibly crash the system. (See Knowledge Base article 830846.) Microsoft has created
a newer version of update.exe that does not require this right. If your patch maintenance program does not rely on Joe to apply his own patches, you may be able to avoid
this issue entirely. Microsoft does not recommend removing this right from the Administrators group, but I say do it if you're going to make Joe an administrator. (Test
the results, of course.)
Remove user rights from the local Administrator group.
User rights define what a user can do on a system. These privileges can be defined locally and overridden using Group Policy. I suggest you do so by creating a special Group
Policy for this purpose and testing it thoroughly. To start the process, configure Joe's computer and make sure you understand what he needs to be able to do. You could go
too far and keep him from getting his work done -- not exactly a career enhancing move for either of you.
To edit user rights for the local machine, open the Start/Administrative Tools/Local Security Policy console and select the Local Policies/User Rights Assignment node. In the
detail pane, double click on the right you want to modify and remove the Administrators group.
Audit Joe's use of administrative rights.
President Ronald Reagan said "Trust, but verify." He was referring to diplomatic relations with China, but the thought applies equally as well when Joe User has administrator
privileges. If you don't audit what Joe does, how do you know if he's doing the right thing? As a member of the Administrators group, he could give himself back the Debug Programs
right for example. This previous checklist will help you configure an audit policy. Make sure "Audit privilege use" is enabled for success and failure. That way you'll know what Joe can
and can't do.
One caveat: You can't audit use of Debug Programs unless you set the FullPrivilegeAuditing registry key. You can do that by enabling the Security Option "Audit the user of Backup and
Restore privilege." There are drawbacks to this option that we'll have to talk about another time.

Windows Security Checklists offer you step-by-step advice for planning, setting up and hardening your Windows security infrastructure.
E-mail the editor
to suggest additional checklist topics.

ABOUT THE AUTHOR:   Go back to Checklist
Roberta Bragg is author of "Hardening Windows systems" and a resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker.

Click to ask Roberta a question or purchase her book here. Also, if you have specific questions or comments about any of Roberta's checklists, click to e-mail her directly. Copyright 2004

Dig Deeper on Enterprise desktop management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.