Implementing Principle of Least Privilege

by [Published on 18 Aug. 2005 / Last Updated on 18 Aug. 2005]

The Principle of Least Privilege is not a new concept, but the push to implement it on production networks has never been so important. This article will go over some of the most common configurations that you can make to implement these principles and reduce the possibility of an attack from a typical end user.

Whether you are a security officer, network administrator, manager, or executive, you are not only aware, but typically concerned about the damage that a typical end user can cause on the network. It has been proven over and over again that most attacks come from within the bounds of the firewall performed by employees. This is why the Principle of Least Privilege is so important. If typical end users can be limited with their abilities, then their scope of damage can be limited and hopefully halted.

Introduction

The concept of Principle of Least Privilege is becoming a common phrase as companies scramble to protect network assets and resources. The pressure is exacerbated by the security audits that are being performed due to Sarbanes-Oxley, HIPAA, and the like. With the Principle of Least Privilege the goal is to give users only the access and privileges they need to complete the task at hand. In most cases this will be for the entire logon session, from the time the logon in the morning till they leave for the night.

What is not desired by anyone is to give users too much access, especially administrative access. However, it is all too common for companies to give users this access. If you are one of these companies you are not alone. The following scenario might hit a little too close to home for you:

EmployeeA works in the Accounting department. EmployeeA works with accounts payable and does not have any administrative access to her computer. After a reorg of the Accounting department EmployeeA becomes responsible for running the end of month reports for the accounts payable application. When EmployeeA attempts to run the report for the first time, an error message shows up within the application indicating that EmployeeA does not have enough privilege to perform the task. The IT staff is called in to try and troubleshoot the problem and give EmployeeA access to run the reports. After hours of investigation, it is determined that the only way that EmployeeA can run the reports is to be given Administrative privileges on her computer. The administrator adds EmployeeA’s domain user account to the local Administrators group in the local Security Accounts Manager (SAM) on EmployeeA’s computer. After a quick logoff and logon, EmployeeA can now run the reports without a problem.

If you are cringing after reading this scenario, that is a good reaction. If you are saying “well, what else could be done?”, this article is perfect for you. Of course, EmployeeA now has full administrative capabilities over her computer and can perform almost any task, regardless of what the domain administrator wants to restrict. A few of these tasks include removing the Domain Admins group from the local Administrators group and removing the computer from the domain to eliminate any Group Policy settings from affecting the computer.

The ideal solution would be to somehow provide the Principle of Least Privilege to EmployeeA such that she can run the reports as an Administrator, but all other tasks are limited to a standard user. This is possible, but might take a bit of work. Here, we will go over some of the most common methods of providing the Principle of Least Privilege. We will also go over the pros and cons of each of the solutions.

Using Run As

First introduced in Windows 2000, the Run As feature was Microsoft’s solution to the Superuser feature in Unix. The concept of the Run As feature is very simple. If we use the example from above as our platform, you will quickly see the power of this feature.

EmployeeA logs in with her standard user account first thing in the morning. This account is named EmployeeA. The administrator creates a new domain user account for EmployeeA and names it EmployeeA_SU. The administrator also adds the EmployeeA_SU account to the local Administrators group on EmployeeAs’ computer. When EmployeeA needs to run the report from the accounts payable application, she starts the application using the Run As feature and logs on with the EmployeeA_SU account. Figure 1 illustrates what the Run As feature interface looks like. When she is done running the reports, she closes the application and continues on with her work as a standard user.


Figure 1: Using the Run As feature allows for different credentials to be input for specific applications

Again, you might be saying “yes” or “no” to this scenario. For those of you saying “yes,” consider the following problem. What is stopping the user from logging in first thing in the morning with the EmployeeA_SU account? Unless you prohibit this behavior, which is almost impossible to do without breaking the Run As feature for the user, they will be able to perform this task. For those of you saying “no,” what solution are you thinking of?

Using the Power Users Group

You might be considering using the Power Users group, which is available on clients and member servers. This group is stored in the local SAM of each computer, not in the Active Directory database. The idea of the group is to provide an intermediate level of privilege access that is between the standard end user and a local administrator. In the past the Power Users group has been used for providing users access to certain operating system features and routine resource access. However, the Power Users group does not solve the full range of application and operating system task needs. Many applications and operating system tasks require administrative access.

Microsoft has realized this and are moving toward the Principle of Least Privilege with future operating system releases. Since the Power Users group does not provide the desired access much of the time, Microsoft is depreciating the capabilities of the Power Users group in the next version of Windows, codenamed Longhorn. It is unclear how Microsoft will elevate the required privileges that the Power Users group currently has, but it is clear that the concept of least privilege is a hot topic and one to be considered for every situation.

Using User Rights for Least Privilege

A common method for configuring least privilege for users on their computer is to use user rights. User rights provide a systematic way to elevate privileges with Group Policy. Some examples of common user rights for least privilege access include:

  • Change system time
  • Install device drivers
  • Logon locally
  • Add workstations to the domain
  • Act as part of the operating system
  • Backup files and folders

Most of these are related to operating system features or functions, not really applications. If you need to provide elevated privileges for users to run engineering, accounting, administrative, etc applications, you might find that user rights are limited.

Least Privilege Application Access

As we saw in our example initially, application access is one of the most common problems with the concept of least privilege. If you only provide a user with standard user access, they can’t perform many of the duties required within enterprise and sophisticated applications. I will also throw in some of the common operating system functions as applications, which requires administrative access in many cases. As we have seen with the solutions that are provided within the operating system, they are either too strict or allow too much access.

To get a solution that meets all of your requirements, you might need to investigate a third party solution. There are many to choose from, but one that solves the concept of least privilege access to applications better than the others is PolicyMaker Application Security from DesktopStandard. A major benefit to this solution is that it fits perfectly with the native Group Policy implementation and deployment that is in every Active Directory installation.

The technology behind Application Security might seem complex, but it is really simple. The tool works by adding a new entry to the security token for the application that requires the elevated privilege. To get a grasp on how this works, let’s work with the initial example to see how Application Security works.

A new Group Policy is created for EmployeeA using PolicyMaker Application Security. The new policy specifies that the Administrators group will be added to the security token for the accounts payable application that the user needs to run reports for. The Group Policy automatically applies to EmployeeA in a background refresh. When EmployeeA starts the accounts payable application, the security token is created from the original security token created at logon, plus the additional information provided by the new policy. When EmployeeA attempts to run the report from the accounts payable application the task is allowed. When EmployeeA exits from the accounts payable application, the security token that was created is deleted, eliminating EmployeeA from having administrative access to any other operating system features or applications.

Summary

Every company needs to implement the Principle of Least Privilege before end users gain too much control over their computer and the network. The built-in capabilities of Run As, Power Users, and user rights can provide some relief, but they do have negative impacts that make them less than ideal solutions. If you go beyond the standard features in the Windows operating system, you can find solutions that fit seamlessly into what Active Directory provides, in an efficient and perfect way to provide least privilege access.

Advertisement

Featured Links