Managing multiple user accounts

Hi.

We have run into a specific situation where we need to install our software on a user account that does not have administrative privileges. In this specific environment only the computer administrator may install software on the specific user account.

We then use the global variable for the current user: %_CSIDL_PERSONAL%\OurDataFiles to install some files into one of the user’s folders. In this specific situation, the files are installed in the administrator file directory. This is understandable as the exe was launched under account control by the administrator.

But what I would like to know is how to efficiently deal with this situation as we want the files to be stored in the currently active windows session user profile and not the administrator account profile.

In the above example, we just used a PC that was not connected to any domain account and the local Administrator account was used to install the software on the user account that did not have administrator privileges.
In the same sense, we are also concerned about the implications of installing software in a similar way but where the PC is connected to a domain where only the domain administrator has the right to install new software on a user’s domain account.

Any information you can provide us with, in terms of a correct method to use in the above cases, or any variables that would be better suited then the SP_Personal variable in situations like these were we need to install files into the currently active user file directory would be much appreciated.

Sincerely,

Michael

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).

2. Request "asInvoker" execution level privileges through the manifest for your application. "asInvoker" manifested applications run non-elevated by default.

3. Dual code-sign all your application files (e.g. .EXE, .DLL).

4. Your application should not depend on any administrative APIs.

5. Do not write per-user information or user-writable information to Program Files or Program directories.

6. Do not write to any other protected Windows area (e.g. the OS drive root folder, the "Windows" folder tree, etc.).

7. Do not write to the HKEY_LOCAL_MACHINE or any other protected registry key.


-- Standard Installation:

1. Use an UAC-aware installation system. By default, installations run elevated.

2. Install applications per-machine (all users) and store per-user data in different locations.

3. Do not install Quick Launch shortcuts.

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!

Does this help?

Friedrich

--
Friedrich Linder
Lindersoft | SetupBuilder | www.lindersoft.com
954.252.3910 (within US) | +1.954.252.3910 (outside US)

--SetupBuilder "point. click. ship"
--Helping You Build Better Installations
--Create Windows 10 ready installations in minutes
--Official COMODO Code Signing and SSL Certificate Partner