UAC (also called Admin Approval Mode) is a new feature introduced with Windows Vista. The main goal of this
feature is to protect the operating system from malicious or accidental damage. This goal is achieved by
requesting consent from the user when an administrative action is attempted (installing an application, opening
UAC has been introduced as the eternal battle between security and functionality rages on. While on one hand we
would like to allow our users to have full access to their systems (which essentially are their tools of trade), on the
other hand we are well aware that allowing unlimited access will without any doubt lead to unintentional/intentional
damage to the local system and far worse to the whole network(virus/worm/adaware infection).
On the same note, an additional issue we must deal with are administrative users. The majority of system admins will use
their privileged accounts for daily tasks. If such an account is compromised by malicious software it is literally unstoppable.
Several options were introduced to limit the access of administrative accounts without hampering their ability to manage a
system. One such example is ‘Run as’. A system administrator can use a standard account for standard tasks, and use a
privileged account to invoke administrative tools (by using ‘Run as’). Note that when using this feature a different account
is used to invoke a process and a different token (more about these later) is attached to that process (until the process
In my opinion, unless enforced by company policy, most system administrators kept on using privileged accounts as
they saw the need of using ‘Run as’ as a nuisance(invoking a different account,entering the user name again and then
the password, too much finger travel). Most system administrators, found the benefit in using ‘Run as’ when
standard users had to be awarded elevated permissions to perform a task (in other words when it didn’t affect them…).
Enter UAC. UAC steps in and attempts to provide a type of a compromise between functionality and security by providing an
environment in which using an “elevated account” is less of a nuisance and not much of a choice…
Every time a standard user or an administrative user attempts to execute a command that requires elevated
privileges(not to be confused with permissions) he or she are queried if they are sure that they want to proceed (the exact
form of the query will be discussed later in this article).
So, how does(did) it work?
Privileges and permissions are different things:
- Privileges/User rights -can be defined as broad abilities that apply to a system as a whole. Changing
the time on a system is a privilege/user right,backing up a system is a privilege/user right.
- Permissions -what a user(process by proxy) can do to a specific object (be it a file or a printer, or an object in
When a user logs on to the system he is authenticated(user/password), then a token is built for him by the system. The token,
will include the users privileges and Security Identifiers (SIDs). A token is very similar to a security pass.
[A SID is a unique string that uniquely (obviously) identifies security principals (user accounts,groups)]
A users token is attached to every process that the user initiates. The first process the user initiates in Vista is explorer.exe
which in turn initiates all process, which inherit the token from it.
When a user attempts to perform an administrative task,such as change the time, his token is examined-if he “owns” the privilege,
he will succeed- otherwise he will fail.
A similar process is undertaken when trying to access an object-each object has an Access Control List(ACL) that has Access Control
Entries (ACE). Each ACE defines a specific SID and wether this SID is allowed or denied a specific action. When the user attempts
to take a specific action on an object his token is examined and his SIDs are compared to the ones on the ACL,if there is a match
then the action defined is examined and according to it the user will either succeed or fail. If no match is found,the user will fail.
[the process is very similar to a private club,each member has a card(token) and the bouncer has the list(ACL) of who is allowed to enter]
A users token is created during the log-on process,thus if he is added to a new group for it to be reflected in his token, he has
to logoff and on again so a new token can be created for him.
How does(now) it work
In Windows Vista there are two types of users, standard users and administrator accounts. Every user that is created and logs on
to a Vista system is classified as one or the other. The distinction is important due to the fact that the token creation process has
changed. Each user still gets a token,yet:
- Standard user -Receives one token that identifies the user to the system
- Administrator accounts -Receives two tokens,one that represents the user as a standard user and one that holds all of the elevated
privileges that the user has.
To facilitate the usage of two tokens a new service called ‘Application Information’ has been added to Vista. This service is responsible
to identify the attempted usage of an administrative privilege and to act upon it based on the policies configured.
Implementation and Experience
UAC is enabled by default.
When Vista is installed, the first user that is created is defined as an administrator account (with UAC enabled). The built-in Administrator
account is disabled (by default). If the Vista installation is an upgrade from XP, and the installation determines that the only administrative
account is the built-in administrator it will leave it enabled with UAC enabled.
You should also note, that the local built-in administrator account can not be used to log on to the system in Safe Mode. Only exception
is in the case of a non-domain joined system that has no other administrative accounts configured on it. If the system is joined to a domain
there are no exceptions(local built-in administrator can not be used to log-on),if there is no other administrative account to be used, and
no cached credentials, Safe Mode with Networking has to be used to enable logon.
When an administrator account attempts an administrative task the system will ask for consent. It does so by taking a “dark screenshot”
and imposing above it a window that asks for consent. Now this “dark screenshot”,except being very dramatic is actually a safe environment
that only Windows processes can access. It is possible for malware to imitate the visual appearance of this environment, yet it has to be
already installed on the system(in other words you are already in a bad place).
fig.1 Consent Window
By the way, the visual structure of the prompt will vary:
Red background and red shield icon: The application is from a blocked publisher or is blocked by Group Policy.
Blue/green background: The application is a Windows Vista administrative application, such as a control panel.
Gray background and gold shield icon: The application is Authenticode signed and trusted by the local computer.
Yellow background and red shield icon: The application is unsigned or signed but not yet trusted by the local computer.
In addition to that the details button will provide the exact name of the executable trying to run. Personally,I would also
like to see the name of the process that invoked the command.
When a standard user attempts to run a task that is of administrative nature he will be prompted to enter the credentials
of an administrator account.
The third visual cue is a small shield being placed next to menu options that warrant for administrative privileges.
UAC can be configured by using the Local Security Policy or by using GPO(Group Policy Object). There are nine settings:
In my opinion the two major settings that control the behavior of this feature are:
- Behavior of the elevation prompt for administrators in Admin Approval Mode:
- Elevate without prompting
- Prompt for credentials
- Prompt for consent (Default)
- Behavior of the elevation prompt for standard users:
- Automatically deny elevation request for users
- Prompt for credentials (Default)
An additional location that can be used to turn off UAC can be found on the ‘User Accounts’ applet in ‘Control Panel’. As you can see
in figure 4 the option is “prefixed” by a shield meaning that is a protected action.
Fig. 4 Turn UAC off
Considering UAC and past attempts to do something similar, leads me to the conclusion that UAC is a an upgraded ‘Run as’. What
I mean to say is that when analyzing how this works we can see that UAC saves the hassle of having to enter credentials for system
administrators by allowing them to use one account with two tokens.
UAC provides safety,it might prevent mistakes done by system administrators and it might prevent the installation/execution
of unwanted software by providing the user with a “second chance”.
A subject I have not mentioned here is the issue of application compatibility this is an important subject
since it enable us to use applications that have not been built with UAC in mind.
For that and more on UAC you can visit: