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.