Five steps for reducing unnecessary use of Administrator accounts

Not everyone needs elevated access privileges -- remove them and boost your security

Something like 95 percent of all business computer users run as Administrator or root on their computer all the time. I applaud the businesses who have successfully removed elevated privileges from non-admin employees. Although it isn't easy to do, making this one security change can significantly reduce the risk of malicious exploit.

[ Roger Grimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]

Removing admin rights (I'm going to ignore that rights, permissions, and privileges are different things for the purposes of this discussion) is difficult to do for different reasons. The most common issue is that end-users want to install and remove their own software and configure their own settings. Developers often need to debug programs and load and unload device drivers.

In thinking about this issue, I came up with seven common reasons why a user would need elevated privileges:

* Installing software

* Configuration changes

* Applications that require elevated rights to run correctly

* Debug Programs, load drivers, kernel modifications

* User management

* Computer management

* Network management

I'm sure there are lots of other issues that depend on whether users only have one-time needs for a particular procedure or continuous needs.

I then came up with many ways a company can either reduce the number of admin-level users or reduce the impact of running as a highly-privileged account. Some options only apply to Windows, while others apply to any platform.

* Add user to an elevated group (Power Users, Network Configuration Operators, Sudoers, etc.)

* Remote support/assistance from IT

* In-person action by IT field support

* Create an Application Compatibility Database for app

* Shim programs

* Custom scripting

* Packaged/managed Installs

* Custom solution (service, Runas app, etc.)

* Third-party solutions

* Run in a virtual machine

* Manifest file

* Redevelop application

* New application

* Remove application

* Training (to give the users another way of doing something so it doesn't require admin assistance)

* Policy/business requirement redesign

* Terminal Services, Citrix

* Assign elevated permissions, privileges, or rights to the user

* Delegation

In the Windows world, Windows Vista adds two new options:

* Vista UAC (User Account Control)

* Vista File and Registry Virtualization

There is no one way to get rid of all admin or root users, but this list should provide any administrator with a solid checklist of alternatives to start. 

Each alternative has its advantages and disadvantages -- some not as obvious as they might seem. For example, many clients have told me that they are considering (or already have) installed virtual machine instances that standard users have full control over. In the virtual machine, the user is administrator or root. Who cares if they mess up or infect the virtual environment?

At first, even I agreed with this solution. But as another client of mine determined, allowing a standard user to run as admin in a virtual environment is the same as allowing them to run as admin in the nonvirtual environment; the only difference is that you now have one more unmanaged desktop. As I've said before in this column, the virtual label doesn't mean the system shouldn't be treated the same as a real system. I should listen to my own advice.

Other options need to be more fully understood. For instance, I've heard a lot of people talking about how Windows Vista's (UAC) reduces the need for local administrators. Several other features in Vista do this (e.g. registry and file virtualization), but not UAC. UAC reduces the privileges of anyone logged in as an Administrator-level account until they separately elevate themselves. So UAC reduces the risk of someone being logged in as an admin all the time but doesn't reduce the need for an admin account. If software needs to be installed locally and can't be packaged or pushed down, the user installing it will probably need to be an administrator. UAC doesn't change that fact.

Sometimes the best solution to the admin account problem will be to replace the existing application with a new application. For example, many legacy applications like older versions of Intuit QuickBooks require that any users running it be part of the Administrators group. (I'm using Quickbooks as an example because my office uses the old version, and I frequently run across old versions in large enterprises.) You can give the user every right and permission in the world, but if they aren't part of the Administrators group, it doesn't work. It was lazy programming on Intuit's part. Finally, after years of complaining by security experts, Intuit fixed the issue.

I expect many applications will be rewritten, if they aren't already, as Web services. Although I'm not overly fond of Web interfaces for most applications, it seems to be the eventual path for all of them. But what I do like is that most Web applications don't require that the end-user be logged in as an admin or root to install -- It's just a browser interface with some AJAX coding. Admin rights are only needed if it installs an ActiveX control or some other client-side executable.

To reduce the need for elevated accounts in your network and to reduce the risk of users who must use elevated accounts, follow these steps:

1. Survey your environment's needs for elevated accounts -- who needs what?

2. Rank each need by the percentage of users who need it, and the relative risk. This is so you can concentrate on diminishing risk where it can do the most good for your organization.

3. Choose one or more solutions that would work to solve the issues uncovered in the previous step. Some companies can use this as a brainstorming session and fill in any solution that might possibly work, while others choose solutions that are more likely to be the final answer.

4. Choose one or more solutions for each risk category.

5. Present your remediation plan to management for approval, and develop a testing and implementation plan.

No matter how you go about it, you should audit your company's use of elevated accounts and seek to reduce their use wherever possible.

Copyright © 2007 IDG Communications, Inc.

How to choose a low-code development platform