More on the "non-elevated administrator"

As the commentors on my earlier post surmised, the notion of a non-elevated administrator is tightly connected with the Windows concept of User Account Control, which was introduced with Windows Vista.

Here's a great first article to read about User Account Control, if you're a developer. And here's a great second article to read after that. I got these pointers from this excellent overview article.

As Corio describes,

UAC is the Microsoft answer to reducing the privileges users run with by default in Windows Vista. Strategically, Microsoft is moving to an environment where users do not have or need privileges that can affect the operating system and machine-wide configuration in order to perform day-to-day tasks.

So, the important part involves something called the "split token":

UAC starts working when a user logs onto a machine. During an interactive login, the Local Security Authority (LSA) takes the user's credentials and performs the initial logon, evaluating the user's token to see if it has what are defined as elevated privileges. If the LSA determines that the user has elevated privileges, it will filter this token and then perform a second logon with the filtered token.

The result is that:

The desktop session and explorer.exe will always be created with a token that approximates the token of a member of the Users group. Any process that is initiated from the Start Menu or by a user double-clicking in an Explorer window that doesn't require elevation will simply inherit this filtered token. Therefore, by default, every application will be running with the standard user token.

Thus, a "non-elevated administrator" is simply a user who is a member of the Administrators group, who has performed a normal logon to a Vista+ Windows machine, with User Account Control in effect, and thus is running with a special minimal set of privileges designed to approximate a normal non-Administrator user.

And an "elevated" administrator is such a user, running an application using the "Run As Administrator" feature to run with elevated Administrator privileges. When starting such an application, the user is made aware of the elevation, as Russinovich describes:

Granting a process administrative rights is called elevation. When it’s performed by a standard user account, it’s referred to as an Over the Shoulder (OTS) elevation because it requires the entry of credentials for an account that’s a member of the administrator’s group, something that’s usually completed by another user typing over the shoulder of the standard user. An elevation performed by an AAM user is called a Consent elevation because the user simply has to approve the assignment of his administrative rights.

This process is what gives rise to those dialog boxes that you've become so familiar with as part of using Vista or Windows 7:

Windows needs your permission to continue.

If you started this action, continue.

User Account Control helps stop unauthorized changes to your computer.

Another interesting part of User Account Control, which I think is perhaps not very well known, is that there are actually three types of application privilege configurations:

1. asInvoker


2. highestAvailable


3. requireAdministrator

asInvoker and requireAdministrator are the ones most people are familiar with, and they are fairly simple to understand. highestAvailable is more complex. Corio describes the run levels for us:

When a new process is created, the AIS will inspect the binary to determine whether it requires elevation. The first thing that gets checked is the application manifest that is embedded into the application's resources. This takes precedence over any other type of application marking including an application compatibility marking or UAC's Installer Detection, which is described later. The manifest defines a run level that tells Windows the privileges needed to run the binary. The three choices for run level are: asInvoker, highestAvailable, and requireAdministrator.

When AIS finds a binary that is marked with the "asInvoker" run level, it takes no action and the process inherits the process token of the parent process that created it. The "requireAdministrator" run level is pretty straightforward as well and defines that the process must be created by a user token that is a member of the administrator group. If the user who attempted to create this process is not an administrator, he will be presented with the Credential dialog to input his credentials.

The highestAvailable run level is a little more complicated. It denotes that if a user has a linked token, then the application should run with the higher privileged token. This is generally used for applications that have a UI designed for the Users and Administrators groups and it ensures that the application gets the user's full privileges.

I've now got a pile of new documentation to read, but at least the basic notion of being a non-elevated Administator is starting to make more sense now. After nearly a decade of using Windows XP, I've got a bit of un-learning to do, and a lot of new concepts and ideas to shove into those empty spaces in my brain...