The Essentials Series
by Greg Shields
Article 1: Understanding Least Privilege.........................................................................................1
Least Privilege Is More than Eliminating Admin Rights.....................................................2
Breaking Apart Least Privilege............................................................................................3
The User’s Role .......................................................................................................3
The Available Tasks ................................................................................................4
The Corporate Policy ...............................................................................................4
Least Privilege Inhibits Inappropriate Behaviors ................................................................5
Article 2: The Business Benefits of Eliminating Administrator Rights ..........................................6
Operational Benefits ............................................................................................................7
Not Just for Enterprises......................................................................................................10
Article 3: Limitations in Native Solutions for Privilege Management ..........................................11
User Account Control ........................................................................................................13
Capabilities to Resolve Least Privilege .............................................................................15
© 2008 Realtime Publishers, Inc. All rights reserved. This site contains materials that
have been created, developed, or commissioned by, and published with the permission
of, Realtime Publishers, Inc. (the “Materials”) and this site and any such Materials are
protected by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtime Publishers, Inc or its web site
sponsors. In no event shall Realtime Publishers, Inc. or its web site sponsors be held
liable for technical or editorial errors or omissions contained in the Materials, including
without limitation, for any direct, indirect, incidental, special, exemplary or consequential
damages whatsoever resulting from the use of any information contained in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, non-
commercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
Realtime Publishers and the Realtime Publishers logo are registered in the US Patent &
Trademark Office. All other product or service names are the property of their respective
If you have any questions about these terms, or if you would like information about
licensing materials from Realtime Publishers, please contact us via e-mail at
Article 1: Understanding Least Privilege
“We’re still using that ancient corporate application and it requires Administrator privileges on
every desktop to run…”
“The CIO told me he needed Admin rights on his laptop due to his travel schedule…”
“Without Administrator privileges, our Help desk is forced to do all the work for customizing
users’ desktops, and they’re just overloaded…”
The likelihood is great that you’ve experienced one or more of these situations at some point in
your IT career. Ancient and poorly coded applications require Administrator privileges at every
desktop for their correct functionality. Executives and individuals of power within organizations
pull rank to be exempted from company security policy. Strained Help desk personnel succumb
to peer pressure from employees to “just give me rights and I’ll take care of myself.” In all of
these situations in the world of IT, individual user privileges are inappropriately expanded due to
the operational needs of the day.
But each and every time those privileges are expanded unnecessarily as a global resolution to an
individual problem, the end result is a reduction in environment security. Every time elevated
privileges are handed out to solve today’s problem, this action invariably causes bigger issues
down the road.
All of these situations relate to and are resolved through the implementation of the concept of
“Least Privilege.” The Principle of Least Privilege was developed more than 30 years ago by the
US government’s Department of Defense (DoD). Looking at computer systems from the
perspective of complete security, the DoD defined Least Privilege in that day as:
[The Principle of Least Privilege] requires that each subject in a system be granted the
most restrictive set of privileges…needed for the performance of authorized tasks. The
application of this principle limits the damage that can result from accident, error, or
Today, the concept of Least Privilege is used to identify a state at which the lowest level of
privileges are assigned to computer system elements while still enabling needed activities to be
Least Privilege Is More than Eliminating Admin Rights
The previous definition effectively says that any action you attempt to accomplish with a
computer must be done with the absolute lowest level of privileges required to accomplish that
task. For many administrators, this equates to getting rid of administrative rights wherever
possible within the organization. But eliminating admin rights on servers and desktops only
accomplishes part of Least Privilege’s lofty goals. Accomplishing its goals means digging deeper
into the functionality of the operating system (OS) to enable those fewest privileges necessary to
perform authorized tasks. Succeeding requires a few additional steps beyond merely eliminating
admin rights on user desktops:
• First, think outside the “Administrator” box. Assigning a user to the Administrators
group grants that user complete power over the processing of his or her computer system.
Yet a user often needs elevated privileges for only a single or a few actions on that
system. Granting the user complete power over that system for the purposes of solving a
single need is unnecessarily excessive.
• All types of person-based privileges are too coarse. Many organizations initially attempt
to reduce user access by converting unnecessary Administrators to other access levels
such as Power User. Though this movement has the tendency to reduce that user’s overall
level of access, these “person-based” privileges are still exercised over an entire
computer. This process of changing the user’s assigned role still grants the user those
privileges over every aspect of the computer system. This result is still not granular
enough to truly fulfill the needs of Least Privilege.
• Control privileges at a per-process or a per-application level. When a user works with a
computer system, that user is launching various applications and processes on the system.
Those applications and processes enable the user to work with data and accomplish job
tasks. Controlling the level of privileges assigned to each process or application
eliminates the need for privilege assignment based on who the user is. Rather, privileges
can be assigned based on the combination of who the user is and what the user needs to
Breaking Apart Least Privilege
Ultimately, the goal of Least Privilege is in assigning privileges to users based on the intersection
of the role held by the user, the tasks the user needs to accomplish, and the policy of the
organization. Figure 1 provides an example of this intersection. This combination of who the
person is as defined by their assigned role within the organization, the actions required as a part
of their role, and when those actions are considered appropriate ensures the greatest level of
control over the user’s interactions with the organization’s computer systems. The next three
sections discuss each of these three elements in more detail.
Figure 1: Least Privilege is involved with the intersection of the three elements shown.
The User’s Role
Each user within an organization has a role to play in the operation of business. A user in the
accounting department may require access to financial documents. A salesperson needs the use
of the sales application and customer database. Users in IT require access to administrate
systems. Each user’s role is involved with completing one aspect of the needs of the business.
The role element of Least Privilege is used first in combination with the task element to be
discussed in the next section. Roles in an organization are mapped to logical roles within an OS
for the purpose of later identifying the activities allowed and not allowed by that role. Continuing
with the previous example, the accounting department user may be assigned to the Accounting
role within the OS.
The Available Tasks
Within an organization are also a number of tasks that must be accomplished in order to achieve
the goals of business. Mapping those tasks to the services available within the organization’s
computing environment illuminates a list of activities and applications. As examples, those
activities may relate to the ability to add printer drivers, change network settings, or customize a
user’s desktop. Within the realm of applications, tasks may be related to the ability to launch a
spreadsheet tool, connect to a database client, or make use of a customized line-of-business
Each of these activities and applications is identified by the OS process that drives its
functionality (for example, winword.exe is the process that drives Microsoft Word). Some of
these tasks operate natively within the context of a standard user account with little or no added
privileges necessary for their functionality. These tasks are configured by default to use the least
privileges necessary for their processing. Others may require elevated access within the
computer system to complete their actions. When necessary, those specific and identified
processes are selectively granted the rights necessary to accomplish their mission.
Through this process of selectively granting privileges based on the need of the process, users
can be given the exact level of permissions needed to accomplish their roles as a function of their
needed activities and applications. Effectively, instead of applying privileges based on who the
person is, privileges are assigned based on what users need to do.
The Corporate Policy
The third segment of Least Privilege relates to the period of use for both the user and the
application. This period of use is determined by the goals and standards set by corporate policy.
This third segment is necessary as a business changes over time. With that evolution comes
changes in the practices and processes of business. For example, consider a user who spends the
majority of their time away from the office and in the field. They may require more
administrative access to their laptop because they are far removed from the assistance of the
local Help desk. Later on, the business may acquire new technology that enables the Help desk to
assist remote users, negating the need for them to retain administrative rights. With this change
comes the end of the need for the user’s elevated privileges on their identified computer.
Individual activities and applications have life cycles as well. Although the organization might
desire its workforce to have the elevated rights necessary to accomplish a system task today, the
organization may later determine that centralized control is more desirable. Version one of a
custom line-of-business application may require elevated privileges due to faults in its code
architecture, while version two overcomes these faults and no longer requires the elevated
privileges. In all of these cases, the period of use of the user and the application must be
controlled in order for Least Privilege to be most appropriately used.
Least Privilege Inhibits Inappropriate Behaviors
Throughout this definition of Least Privilege, the end result is in reducing or eliminating system
behaviors that are considered inappropriate by the business. Behaviors—whether invalid
software download and installation, the inappropriate changing of system settings, or the
unintended introduction of malware and other unwanted software onto computers— can be
eliminated or reduced through the application of Least Privilege.
The next article in this series will discuss these behaviors in depth through its discussion of the
business benefits of implementing Least Privilege. The third article will continue the discussion
by looking at limitations in the native solutions available today within the Windows OS. It will
explore feature sets that are necessary to ensure that the goals discussed in this article can be
accomplished with success.
Article 2: The Business Benefits of Eliminating Administrator
The first article one of this series engaged in an extended definition of the Principle of Least
Privilege. Starting with a very high-level look at privilege assignment, that discussion showed
how Least Privilege requires the lowest set of privileges possible to be assigned in order to
accomplish any particular task. It further requires that privileges assigned for the purposes of
accomplishing one task are not leveraged to perform another unauthorized task. Because of these
requirements, the granular assignment of privileges requires the combination of three parts: the
role a user has in the organization, the activities the user needs to accomplish, and the corporate
policies of that organization. Aggregating these three elements results in a list of the processes
and applications each user role is approved to accomplish.
The third article will discuss how these high-level ideals are manifested within the Windows
operating system (OS). But know for now that the end goal is for processes and activities within
the OS to be assigned elevated privileges only when those privileges are specifically required.
This process ensures that an individual user is not granted wholesale Administrator privileges for
the purposes of solving a single issue. A much better approach is in distributing privileges to
individual applications and processes based on the needed activities of the user.
The end result of this approach in a Microsoft Windows environment is the significant reduction
of Administrator privileges across the board. Users who were previously granted Administrator
rights to resolve the privilege needs of a single application can now have those rights removed.
IT administrators themselves can be more specifically granted the privileges they need to
manage the computing environment. The rights formerly assigned to every action of a specific
person are now more granularly assigned to the specific activities and applications that require
Eliminating Administrator rights enables a set of benefits to the organization, which can be
broken into benefits related to operational improvements, security enhancements, and a greater
ability to fulfill compliance requirements. The business stands to gain from each related to this
right-sizing of security privileges.
The first set are those related to operational benefits. These benefits relate to improvements in
organizational workflow, the standardization of settings within the environment, and the ultimate
ability of IT and the business to get the job done:
• Standardized settings are assured. The Windows OS has thousands of potential settings
that can be standardized using various techniques. This standardization of settings
ensures that each desktop behaves in ways similar to others. It ensures greater uptime in
the environment by ensuring that known-bad configurations are avoided, while those that
enhance usability are enforced. The problem with standardization in environments with
widespread Administrator rights is the ability for the local user to reconfigure the desktop
at will. When individual users retain the ability to move away from standardized settings,
this increases the complexity of the overall IT environment and reduces the ability of IT
administrators to keep the environment up and operational.
• Users are prevented from installing unlicensed and unapproved applications. One of the
capabilities given to users with Administrator rights is the ability to install new software.
When a user is granted traditional Administrator rights, the user gains the ability to install
any software to their computer without requiring the normal workflow steps usually
required by IT. Although this setup means that the user can more quickly install the
software they need, it also means that IT no longer fully owns the software inventory
process. Inappropriate and/or unlicensed software can be installed to desktops without the
knowledge of IT or the business. This can introduce the potential for data compromise in
the case of known malware or can be a license violation in the case of legitimate
software. Thus, granting Administrator privileges to users gives them the authority for the
installation without the responsibility of security and proper licensing.
• More efficient use of hardware resources. Inappropriate software, especially software
downloaded from illegitimate Web sites, adds a resource burden to business hardware.
This resource burden is especially problematic in the case of malware code. By retaining
control over which software is installed to desktops across the environment, IT ensures
that available hardware is used with the best possible performance and the least possible
• Reduced cost of ownership for desktops. Related to the previous bullet point, the more
time IT is required to spend with each individual desktop, the more costly that desktop is
to maintain. The installation of inappropriate software along with the inappropriate
reconfiguration of standardized settings often results in an increased rate of problems as
well as an increased level of downtime for that desktop. By eliminating Administrator
rights and ensuring greater standardization, IT will reduce the costs associated with
maintaining each individual desktop.
• Fewer calls to the Service Desk. In the end, all of these benefits are associated with a
reduction in the number of support calls to the Service Desk. When desktops can
maintain a standardized configuration, users are more likely to accomplish their assigned
tasks through their required applications and processes.
Operational benefits are important to the business side of the IT organization. But the elimination
of Administrator rights also impacts the environment’s security posture. These benefits go far in
ensuring the safety and security of critical corporate data by preventing the installation of
malicious software and the configuration of known-insecure settings:
• Security configurations cannot be overwritten. Though many organizations may not
engage in a high level of desktop customization for visual purposes, nearly all enforce
configurations that are known to improve the security posture. These security settings
relate to the automated installation of security patches, enabling and configuration of the
firewall, and other desktop and application lockdowns that ensure the safety of the
environment. As with those discussed in the previous section, virtually all of these
settings grow suspect in environments in which local users with Administrator rights can
disable them at will. By eliminating traditional person-based Administrator rights,
organizations can ensure that users retain the ability to accomplish system tasks they
require—networking changes, printing, and so on—while being prevented from adjusting
settings related to system security.
• Malware infections are inhibited. Very little of a user’s daily processing requires the use
of Administrator privileges. Yet when users run with Administrator privileges during
their daily use, they unnecessarily expose themselves to the potential for malware
infection. Such is particularly the case when users browse the Internet. When the
browser’s process is launched without administrative privileges, it is very difficult for
accidentally downloaded malware to infect the system. This is the case because making
any changes to the protected areas of the Windows OS—those areas most desired by
malware—requires administrative privileges. Thus, browsing the Internet with the
lowest-possible set of privileges goes far in preventing most known forms of malware
• Enhanced data protections. The user-initiated download and installation of malware is
not the only mechanism by which computer systems can be compromised. When a user
elsewhere in the network accidentally infects their computer with malware that is
designed to replicate, its replication can be inhibited by ensuring it runs with the least
In addition to the operational and security benefits, eliminating Administrator rights assists with
an organization’s ability to maintain industry and regulatory compliance. Virtually all
organizations fall under some form of regulation—the Sarbanes-Oxley Act (SOX) for
corporations, the Health Insurance Portability and Accountability Act (HIPAA) for medical
organizations, the Gramm-Leach-Bliley Act (GLBA) for banking institutions, the Federal
Desktop Core Configuration mandate for federal entities, and others. Though each regulation is
unique in the text of its requirements, all require some form of technical control that ensures the
safety and security of sensitive data in the environment.
Without going into the individual requirements of each regulation, the following benefits relate
to the fulfillment of the spirit of each. By controlling and effectively logging user and
administrator activities, the fulfillment of compliance regulation requirements can be assured:
• Logging of user activities can be assured. The native logging systems within the
Windows OS suffer from the limitation that any administrative user can clear the logs at
will. This limitation means that a user with administrative access can clear any record of
their activities if desired. With the assurance of activity logging a primary requirement of
virtually all compliance regulations, preventing log erasure is a key necessity for the
secure and compliant IT environment.
• Data access can be protected. Virtually all corporate data must be accessed through some
form of application. When the access to that application has been elevated through the
assignment of Administrator privileges, the user may have the ability to leverage that
access for other unauthorized purposes. Conversely, when granular privileges are
assigned based on individual activities, the likelihood of data breech is reduced due to a
reduction in the count of potential activities that can be accomplished by the user.
• The power of IT administrators can be limited based on their responsibilities. Lastly,
with traditional privilege models, IT administrators must be given Administrator access if
they are to have the rights necessary to do their jobs. This all-or-nothing approach to
permissions enables rights for administrators that go above and beyond their individual
needs. Using the Least Privilege mode, privileges assigned to administrators can be
tailored specifically to only the activities required by the individual. This setup reduces
the spread of Administrator access to IT administrators, and is a key technical control
required by many compliance regulations.
Not Just for Enterprises
Though many of the benefits identified appear to relate to the enterprise large-scale organization,
they hold the same value to smaller businesses as well. In comparison with large-scale
organizations, which tend to have IT and security policies in place and a high level of process
maturity, smaller businesses are often forced to use an adhocracy model. Because of the “get the
job done” nature of small businesses, the potential tends to be higher for one-off system
configurations due to special needs. Because of the trends in this type of workflow, it can be
argued that the reduction of Administrator rights in smaller organizations is equally, if not more,
important to the security and operations of the environment. Eliminating traditional person-based
Administrator rights provides the same level of protection for small businesses as it does for
large, enterprise-scale organizations.
Article 3: Limitations in Native Solutions for Privilege
The first two articles in this series have taken a high-level approach to privilege management and
the need for a reduction in the assignment of administrative privileges. However, a technical
explanation is necessary to fully understand how Least Privilege impacts the operation of the IT
environment. The explanation in this article will relate to the Microsoft Windows environment
and focus on existing solutions that are natively available. Each solution attempts to manifest a
resolution to the problem of Least Privilege. As you’ll find, each also has limitations in its
efficacy and scalability as a holistic solution.
Before discussing each solution in-depth, a look at the limitations of the Windows operating
system (OS) itself is first necessary. When a user logs into a computer, the user’s interaction with
the computer is typically comprised of system configuration activities such as changing
networking information or connecting to printers as well as making use of applications that are
installed to the computer. Applications are typically installed to the location C:\Program Files or
C:\Program Files (x86) (in the case of 32-bit applications installed on x64 systems) with
computer-specific information stored in HKEY_LOCAL_MACHINE. These locations are
considered secure installation locations by the Windows OS. Standard users are prevented from
making changes to these locations. File-based user-specific information is typically stored in the
user’s profile with registry-based user information stored in HKEY_CURRENT_USER.
This separation between areas that are considered secure and available for users ensures that
application installations can be completed only by an assigned administrator. It also ensures that
for the protection of the application, its core installation cannot be modified by standard users.
Some applications, however, do not recognize the separation between these two areas. Others
may require access to drivers and other system-level components that are typically reserved for
administrative users only. When applications such as these are installed to a computer, their use
effectively requires that its user have Administrator-level access.
As discussed in the first article of this series, the problem is that the common solution for
providing this level of access is to add the user to the computer’s Administrators group. Doing so
results in every action by the user being completed with administrative privileges when the
desired result is merely to make one or more “bad” applications run.
Early attempts in the Microsoft Windows environment to limit the use of Administrator
privileges suggested that users log in using a non-administrative account. That account would
include the privileges necessary to accomplish the “regular” tasks of the day. In the case in
which a task requires the use of administrative privileges, early guidance suggested that the user
log out and log back in with a separate Administrator account.
This process incurs major administrative overhead to the user. If a user regularly needs to use the
“bad” application, the user will find themselves wasting time logging out and back in repeatedly.
With no enforcement mechanism in place to ensure proper behavior, many users ultimately
chose to log in with their Administrator privileges to the neglect of the lesser-privileged and
more secure “primary” account.
An early alternative solution to resolve this problem was the use of the Runas tool. This
command-line tool and shell extension allowed users to log into their computers with standard
credentials. When the use of an application required administrative elevation, the user would use
Runas to launch the application with alternate administrative credentials. Leveraging the use of
the Runas tool along with its Windows shell extensions eliminated the need to log out and back
in to enable credential elevations. Yet this solution suffered from many of the same limitations as
the double-login concept:
• Additional steps are required. In order to launch the process under the alternate
credentials, extra steps are still required. For non-technical users, these extra steps can be
challenging, forcing them to remember the extra steps each and every time the alternate
credentials are required to launch an application. Users must also be aware of which
applications require administrative credentials and ensure that they elevate only the
applications that need them.
• The user must manage separate credentials. There is an additional administrative
overhead on the part of the user as well as IT in managing two separate sets of
credentials. As examples, dual credentials include the typical processes of managing
password changes and remembering passwords. IT must also manage the storage of
double credentials for each user on the network, which adds a burden on their operational
• No enforcement. Leveraging the Runas tool is a purely client-based approach. Thus, no
policy-based enforcement is present to ensure that users are correctly elevating approved
applications and not using credentials for unapproved actions. The elevated credentials
are also equivalent in capability to standard credentials. So there is no technical control in
place to ensure that users don’t simply log in to the computer with the elevated
• Launched processes were created as a separate user. When processes and applications
are launched using the alternate set of credentials, they are launched under a different
user account entirely. This alternate account method does not work with some
applications and often causes problems with the correct logging of user actions.
Because of these limitations, the use of Runas as a tool for selective elevation is based on little
more than the “honor system.” Although this might have been moderately effective for use by
small groups of highly trusted administrators within IT, the spread of its use through the regular
user population was not controllable and did not meet the requirements of a technical control as
defined by many compliance regulations.
User Account Control
To combat the inadequacies of Runas, the Windows Vista and Windows Server 2008 OSs were
both updated to include a new service called User Account Control (UAC). This change affects
how Administrators interact with the OS. In short, when an Administrator logs into a UAC-
enabled system, they initially use a set of credentials that do not have administrative privileges.
When the administrator attempts to accomplish a task that requires administrative credentials, the
system then switches between the initial “regular” and the alternate “elevated” credentials for the
needed activity. To prevent an unwanted action or malware infection from automatically
elevating a user’s credentials, any occurrence of credential switching involves graying out the
desktop and prompting the user to approve the elevation.
Due to this added level of security, administrators that operate under UAC’s controls are referred to
as Protected Administrators.
UAC affects standard users as well. When a standard user attempts to perform a task that
requires elevation, a prompt appears for them as well. This prompt, called an Over the Shoulder
(OTS) Elevation Prompt, provides a place to enter credentials for an alternate administrative
account. Entering the username and password for an Administrator into the OTS prompt allows
the standard user to accomplish the task.
Yet there’s a problem with this implementation. The only way to complete an OTS elevation is
by handing over Administrator privileges to a user, an action that ultimately gives them the
username and password that could be used for future elevations. This implementation results in
the same type of person-based credentials assignment that Least Privilege specifically desires to
With UAC, for a standard user to accomplish a task or run an application that requires elevated
privileges, the user must have access to Administrator account credentials. With these credentials, a
standard user has what amounts to full control over the entire computer and is no longer operating in
a Least Privilege environment.
The implementation of UAC resolves one of the biggest problems with Runas: Namely, the
requirement for an Administrator to manually identify and elevate when administrative
privileges are necessary. The UAC service in many—though not all—cases automatically
recognizes when privilege elevation is required. UAC also resolves some of the issues associated
with Runas’ use of completely separated credentials for standard and administrative access.
When an Administrator elevates their credentials, they are effectively using the same user
account. However, UAC still suffers from significant limitations that make it challenging to use
in an enterprise environment:
• Complex. Much of UAC’s functionality lies “under the covers” of the desktop itself,
making it difficult to truly understand. Although UAC in consumer environments works
well for protecting individual users and their computers, understanding how to best use it
in a managed, corporate environment requires specialized skills.
• Annoying prompts. Without a core understanding of UAC’s protections, non-technical
users and IT generalists often see UAC and its prompting as an intrusion into their daily
workflow. With many actions requiring administrative access, especially considering the
reconfiguration of the Windows Vista and Windows Server 2008 file system, UAC
prompts are seen relatively frequently. The ever-present barrage of elevation requests
slows the ability of the privileged user to get their job done.
• Responsibility for elevation remains with the user. Because the decision whether to
accept or reject an elevation request remains with the individual user, that user retains the
ability to make the wrong decision. When users are not appropriately trained on how to
use UAC and when to approve or reject elevation requests, they may out of frustration
always choose to accept. This behavior ultimately reduces UAC’s effectiveness in
protecting the computer against malicious code.
• Little or no centralized mechanisms for control, management, or logging. UAC is a
purely client-based solution that includes no mechanism for the centralized logging of
elevation requests. It also includes only a coarse capability for centralized management
and tuning, having only ten configurations that can be controlled via local or Group
• Person-based credentials assignment. Last, and possibly most important, UAC’s
implementation retains the person-based credentials assignment architecture discussed in
the first article of this series. Administrative credentials are assigned to an individual and,
once assigned, grant the individual what amounts to full control over the entire computer.
Credentials with UAC cannot be granularly assigned to enable Administrator access to a
specified activity or application. This limits its utility as a solution for enabling a Least
Capabilities to Resolve Least Privilege
To this point, this series has discussed the definition of Least Privilege, the benefits it portends to
provide for the IT environment, and how native solutions have yet to truly align with its goals. In
order to achieve an environment that supports Least Privilege, there are a set of desired
capabilities that are necessary. These capabilities at present are not available through the native
Windows OS but in many cases are available through third-party add-on products. Although not
a comprehensive list, consider the following needed capabilities when looking for solutions that
enable Least Privilege:
• Granular privilege assignment. Considering the three separate elements that must
aggregate to identify the individual, the element, and the period of use, solutions that
support a more granular level of control are necessary. Solutions that support this
granularity will be able to elevate administrator-assigned actions and applications based
on a user and his or her role. Individual users and applications should have the ability to
be enabled or disabled as needed by IT administrators. This granular level of control
eliminates the need to assign entire-computer privileges for the resolution of point issues.
• Centralized control and policy-based assignment. With the move to granular control of
elevation comes the need for centralized control over which applications, actions, and
users can and should be elevated. Centralized control also includes centralized logging
support that fulfills security and compliance needs. Policy-based assignment ensures that
configured elevation settings at each client computer are enforced based on the policy
applied to that computer. It also enables entire classes of users, computers, and
applications to be managed as single units for enhanced management.
• Movement of elevation responsibility from individual users to IT. A chosen solution
should remove the onus of responsibility for elevation completely from individual users.
This movement of responsibility ensures that educated and trained IT personnel are
making decisions about elevations based on corporate policy and security experience. It
also eliminates the possibility that an uninformed user will automatically choose to
elevate when any prompt appears.
• Right-sizing of notifications. Although UAC’s excess of prompting has led many
administrators to desire a complete elimination of prompting, there may be situations
where users require a minimal level of notification. This level of notification may be
unobtrusive unless necessary for the protection of the OS.
Third-party applications are available today that augment the native OS as well as UAC by
enabling elevations while protecting the OS from attack. This additional software assists IT with
maintaining a secured and controlled desktop that supports the needs of the user while providing
the protections required by IT.