Installing as Administrator vs User

Kari said:

~~~
When a user, either a standard user or an administrative user selects Run as administrator, the command will be executed with elevated rights using a so called built-in administrator account rights.
~~~

That is not my understanding of things...
...but i could easily be wrong :-(

Selecting "Run as administrator" from a context menu to launch an app with elevated privileges does not make use of the Built in Administrator account (most of the time*). It passes the request to consent.exe - which looks at the current user's account type:

If the user account type = standard, then the consent looks at the list of accounts to use in the prompt for an admin account password. Once a password for an admin account is supplied, I'm not positive that I can describe what access token is being used. But I'm pretty sure that only accounts that are enabled can be used. The built in Administrator account is disabled by default and yet "Run as administrator" still works for both standard and admin user accounts.

If the user account type = admin and UAC is turned on, then consent merely prompts for the user's approval.

*Certain OS upgrade situations might make the built in administrator account the only admin account.

This is old...
Getting Started with User Account Control in Windows Vista Beta 2
...but it mentions the upgrade situation and discusses access tokens. Maybe things have changed in W7.


To the OP,
I've only seen a hand full of applications that care which type of account was logged on during the install. Other users might have to manually setup desktop and Start Menu shortcuts. During installation, the registry keys should be created at the computer level and the current user's user level. Once another user logs on and starts the application in question, it should create the needed registry keys at that user's user level. I could be wrong about the registry stuff - I've not had to research it.

For the most part, yes, it's the same permissions-wise. If "user" is an administrator, what the "run as administrator" option does is just to switch the same user to an administrator context, since it normally starts in a dual token context, one with admin permissions, and other striped of admin rights, but always under the same "user". When you log on as the built-in administrator, you get the same privileges as you would do under "run as administrator" but under a different user name.

Now for the registry thing, HKEY_USERS is the key that hold data about each particular user account, where each one has full read/write permissions, and where often user-specific settings are stored. Each key you see under it belongs to one account in your computer, encoded with its SID. Now, HKEY_CURRENT_USER is nothing more than a sort of "shortcut" to the corresponding key in HKEY_USERS that belongs to the current user (really, to the user account that runs regedit). The data itself is always written there, and then only "reflected" in HKEY_CURRENT_USER as appropriate.

The reason you're seeing a difference between administrator and a admin normal user is because that redirection. The "current user" while installing is in one case the built-in administrator and in other case the regular user. Normally, most programs that save settings in the registry will, after installation, write settings to registry in HKEY_CURRENT_USER during normal usage, so in the long run it doesn't matters who installs.
It's normally recommended in Windows 7 to use a normal user account instead of switching, and rely on UAC elevation to get the required permissions. With UAC disabled, as well as in XP and earlier, the best security practice is effectively to logoff/logon as admin to perform admin-only tasks.

UsernameIssues said:

Selecting "Run as administrator" from a context menu to launch an app with elevated privileges does not make use of the Built in Administrator account (most of the time*). It passes the request to consent.exe - which looks at the current user's account type:

If the user account type = standard, then the consent looks at the list of accounts to use in the prompt for an admin account password. Once a password for an admin account is supplied, I'm not positive that I can describe what access token is being used. But I'm pretty sure that only accounts that are enabled can be used. The built in Administrator account is disabled by default and yet "Run as administrator" still works for both standard and admin user accounts.

That's true. "Run as administrator" under a standard user just ask to enter a user/password of a user that has admin privileges, and launch the elevated program under that account security context. For admin accounts, they run under a dual-context security, where one user token has full admin permissions, and the other is has limited permissions as it were outside the admin group, that is used to run every program by default. "Run as administrator" on those accounts just uses the full admin token to get the administative permissions, always under the same user account.

Kari said:

We can argue about the nuances but to put it very simply, an elevated command means it will be run with equal rights than the built-in administrator. That's why when you are logged in to this "super user" account you can run commands without elevating them because they are already elevated.

The built-in administrator has no "super user" power, it's just one more administrator account. What's special about it is that it cannot be deleted and has a fixed, predefined SID. But the important point is that it's by default immune to UAC, so it doesn't run with dual tokens, but every program launched from it always has full admin permissions, that's why it never gets any elevation prompt. There is a system policy that can change that, making the administrator account totally equal to any other account.

Sorry - I did not mean to start stuff. I was attempting to think about the registry question that the OP asked about. Running an app as a user (account type = admins) and using "Run as administrator" does not write install info to any other account's registry keys. That was my main point.

As a side bar:
I'm not sure how many tokens a user (account type = admin) gets when the UAC is off.