If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Threaded View

Re: Managing multiple user accounts

Hi Michael,

most software products (99.99%) are installed "per-machine" (elevated) and not "per-user" (non-elevated).

Background information: in Windows XP, the first user created when installing the operating system was given administrative privileges by default. As such, most users used this account for everyday use. As a result, all software (including malware!) was also running with administrator privileges, giving it full access to the operating system. Not a good idea.

Windows Vista introduced the new Windows User Account Control (UAC) feature. UAC allows you to login as a Standard User, but still perform administrator tasks without having to switch users, log off, or use 'Run As'. This limits the risk of users making changes that could harm their computers. It also prevents malware from attempting to infect computers undetected. Administrators can run most applications with limited privileges, but can temporarily "elevate" their privileges when they need to perform an administrative task (e.g. installations). A "Standard User" account is synonymous with a "Limited User" account in Windows XP.

With UAC enabled, all processes execute with Standard User (token) privileges, unless specifically elevated by an administrator. UAC starts working when a user logs onto the Windows 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 check if it has "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.

That means, even administrative accounts don't use the full-access token by default! The goal of a normal "UAC-aware" application is to start with the access token of the running account, and only request promotion to full-access token when actually needed. This process of promotion is called "privilege elevation", and requires that user confirms the action, before it is actually executed. When "elevation" is 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 Administrator Approval Mode (AAM) user is called a "Consent elevation" because the user simply has to approve the assignment of his administrative rights.

In other words, we have two types of administrators on UAC-aware operating systems, with User Account Control in effect:

1.) a "non-elevated" administrator who is a member of the Administrators group. He has performed a normal logon to the Windows machine and is running with a special minimal set of privileges designed to approximate a normal non-Administrator user.

2.) an "elevated" administrator running an application using the "Run As Administrator" feature to run with elevated Administrator privileges.

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 double-clicking in a Windows Explorer window that doesn't require elevation will simply inherit this filtered token. By default, every application will be running with the Standard User token.

In Windows Vista or later, CSIDL_PERSONAL is the virtual folder representing the My Documents desktop item (this is equivalent to CSIDL_MYDOCUMENTS) The variables are recognized only in the user context!

Let us assume, you have a "MichaelB" administrator account and a "JoeUser" Standard User account. If "JoeUser" starts the per-machine setup.exe installation, UAC determines that the Current User does not have a token of sufficiently high Integrity Level and the Credentials Prompt asks the user to provide a username and password of someone who has sufficient rights (MichaelB). Windows will then create the necessary token for that user and uses it to elevate the process so you can now continue with the installation. Please note that you are on a completely different profile after the elevation process. You have switched from the "JoeUser" profile to the "MichaelB" administrator profile! In other words, you write to the per-user CSIDL_PERSONAL folder in the "MichaelB" and not the "JoeUser" profile!

The following is a very brief description of how to make an application "UAC-aware"

-- Standard Application:

1. Embed an UAC manifest into your main application (.EXE). A manifest basically tells Windows how aware the program is about the recent Windows versions (and disables "Virtualization"). You should include a manifest for Windows 10 or Windows 8.1 (it's fully backward compatible with all previous Windows versions).

4. Never write to per-user locations from the elevated running installer. That means, never write to the HKEY_CURRENT_USER registry key or to per-user file locations.

5. Launch applications non-elevated at the end of the installation process.

6. Code-sign the installer.

Note: if you have to install "per-user" data, install it to a common location and as a "first run" action of your main application, copy the data from the common location into a per-user location.

Respect the recommended (default) locations for applications and data files, but provide users with an option to select another installation location for both. A true "Mixed User Application" should work elevated and non-elevated.

That's it :-)

The Golden Rule of UAC-compliant software development: never ever write from an elevated running installer to per-user locations!