Developing Applications that Run at Logon on Windows Vista

Article
02/14/2007

This article details changes in Windows Vista™ that affect applications that launch when a user logs on. These changes impact both standard users and administrators on Windows Vista computers. Independent software vendors can use the information in this article to troubleshoot and develop Windows Vista applications that launch at logon.

User Account Control Background

Application developers have consistently created Microsoft Windows applications that require excessive user rights and Windows privileges, often requiring that the executing user be an administrator. As a result, few Windows users run with the least user rights and Windows privileges required. Many enterprises, seeking to balance ease of deployment and ease of use with security, have often resorted to deploying their desktops as administrator due to standard user application compatibility problems.

With User Account Control (UAC), Microsoft is providing a technology to simplify deploying standard user desktops in the enterprise and at home.

Building off of the Windows security architecture, as originally designed in the Microsoft Windows NT® 3.1 operating system, the UAC team sought to implement a standard user model that was both flexible and more secure. In previous versions of Windows, one access token was created for an administrator during the logon process. The administrator's access token includes most Windows privileges and most administrative security identifiers (SIDs). This access token ensures that an administrator can install applications, configure the operating system, and access any resource on the computer.

The UAC team took a drastically different approach to designing the access token creation process in Windows Vista. When an administrator user logs on to a Windows Vista computer, two access tokens are created: a filtered standard user access token and a full administrator access token. Instead of launching the desktop (the Explorer.exe process) with the administrator's full access token, the filtered standard user access token is used. All child processes inherit from this initial launch of the desktop, which helps limit Windows Vista's attack surface. By default, all users, including administrators, log on to Windows Vista as standard users.

Applications in the User Logon Path Background

In previous versions of Windows, independent software vendors (ISVs) may have elected to place programs in the user logon path to ensure that they run each time a user logs on. While this solution may be convenient, it often results in application compatibility problems when the user is not an administrator. In addition, research also shows that a growing number of enterprise customers want to deploy their desktops as standard user. This poses a growing problem for applications that require administrator privilege to run in the user logon path, not only on Windows Vista, but also on previous version of Windows. These applications will fail to run and make configuration and administration more difficult. When a user logs on, applications that require elevated privileges, and are in the user logon path, require a full administrator access token. As a result, the user is displayed a User Account Control dialog box either requesting approval or credentials. To compound the problem, the user has no way to tie the elevation request to a specific application. To avoid this poor user experience, Windows Vista blocks applications that require elevation in the user logon path. This functionality also helps thwart malicious software that may place itself in the user logon path.

User Logon Paths that are now Blocked

Applications that require administrator-level privileges to run are blocked when launched from the following locations:

Per-user startup folder
Per-machine startup folder
Per-user RUN key
Per-user machine RUN key

Per-User Startup Folder

The Per-User Startup folder is located in the registry at: %USERPROFILE%\Start Menu\Programs\Startup.

Per-Machine Startup Folder

The Per-Machine Startup folder is located in the registry at: %ALLUSERSPROFILE%\Start Menu\Programs\Startup.

Per-User RUN Key

The Per-User RUN key is located in the registry at:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.

Per-Machine RUN Key

The Per-Machine RUN key is located in the registry at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

How to Unblock Applications in the User Logon Path

This section details the process to diagnose and unblock applications in the user logon path. Please review each subsection to properly identify your application's needs and accompanying solution. The following diagram represents the process to diagnose a blocked application and determine the appropriate solution.

Figure 1 Troubleshooting a blocked application in the user logon path

Testing and Developing an Application for Standard User on Windows Vista

If your application is blocked in the user logon path, determine the cause by first running the application as standard user on Windows XP. If the application does not run successfully, this indicates that the application requires certain administrator-level privileges to run.

Use the Microsoft Standard Analyzer Tool, a free download from Microsoft.com (https://go.microsoft.com/fwlink/?LinkID=71359), to troubleshoot the application and determine the specific administrator privileges and user rights required. Alternatively, you can manually debug the application to determine what administrator-level privileges are needed. The Standard User Analyzer identifies a number of common dependencies such as writing to HKLM and use of Windows privileges higher than that of a standard user, and will record all administrative operations encountered by an application, including registry/file system access and elevated application programming interface (API) calls. It does not however catch all instances that would block running as a standard user, and the application may sometimes require manual debugging. If the application can provide its functionality without administrator-level privileges, remove the administrator-level dependencies, rewrite, and re-deploy the application. Ensure that you review the Patching Applications in a UAC Environment section of this document to ensure that your application updates well for standard users. If the application must have administrative functionality, see the flowchart in Figure 1 for guidance.

Embedding an Application Manifest with a Windows Vista Application

Applications that run successfully on Windows XP as a standard user may require elevation on Windows Vista despite not needing any administrator-level privileges. This elevation may occur as a result of a false positive detection based on heuristics, which determine if an application should require elevation. Windows Vista will mark an application to require elevation if the word setup is in its executable name, or if the application is in the application compatibility database that has previously been known to require administrator operations. However, false positives do sometimes occur.

To explicitly specify that an application does not require elevation to run, you will need to update the application's application manifest. In the <requestedExecuteLevel> node, ensure that level=asInvoker is set. The following example illustrates the asInvoker requested execution level.

<requestedExecutionLevel

level="asInvoker”

uiAccess="true|false"/>

Applications marked asInvoker run with the access token of the parent process. In the case of a standard user, the standard user access token is used, and a standard user compatible application will execute without elevation and not be blocked in the user logon path. See Windows Vista Application Development Requirements for User Account Control Compatibility (https://go.microsoft.com/fwlink/?LinkID=73964) for more detailed information about embedding an application manifest.

Splitting an Application into Standard User and Administrator Components

Certain applications must have both standard user and administrative privileges to function. These applications are often called mixed-mode applications since they include both standard user mode and administrator mode functionality. For example, MSN Messenger needs to periodically update itself, which requires administrative privileges to modify its files in %ProgramFiles%. Another example of a mixed-mode application is a toolbar that must be available at logon and performs administrative functionality on-demand when invoked.

This type of mixed-mode application should be split into two programs: a standard user application that can be placed in the user logon path and not be blocked and an administrative application that performs the administrative functionality. The standard user application will call the administrative application when needed, and the user will be asked to elevate accordingly.

It is important to note that this solution is applicable only for applications that periodically or on-demand require administrator privileges. If an application requires administrative privileges virtually all of the time, such as a program used to detect and prevent the installation of malicious software (an anti-malware application) or a program that synchronizes the clock, a different solution is needed. This alternative solution is described in the next section.

Splitting an Application into a Standard User Application and a Service

Certain applications may need to run continually to perform administrative-level operations, but yet still have a standard user interface. An example of such a program is an anti-malware application. Anti-malware applications should have its engine run as an administrator to scan for malicious software and its user interface component run as a standard user. As a result, both standard users and administrators can schedule and run anti-malware scans on the computer without being prompted for elevation.

This type of application should be split into a standard user application and a service. The service runs on the local machine and communicates with the standard user application. In the case of anti-malware, this will ensure that the engine will not be blocked at logon and will also allow the user to configure the anti-malware application as appropriate.

Developing a Multi-Part Setup Application

Certain applications when executing setup may require a reboot to continue and complete the installation.

In such a case, the elevated application should write to the RunOnce registry key at: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce.

When the system reboots and a user in the Administrators group logs on, the application will launch, complete the installation and delete the entry from the RunOnce key without requiring the user to interact with a UAC elevation dialog box.

Important

The application must inform the user that a user that is a member of the Administrators group must log on after the reboot. If a user other than one in the Administrators group logs on, the installation will be either incomplete or corrupt since the RunOnce key will not execute for the standard user.

Patching Applications in a UAC Environment

To make deploying and servicing applications easier on Windows Vista, Microsoft has provided an updated Windows Installer through Microsoft Windows Installer 4.0. The latest Windows Installer makes patching Windows Vista applications with UAC easier by allowing patching of an application or the installation of a newer version without requiring administrator privileges. Windows Installer 4.0 is the ideal and recommended way to deploy or re-deploy applications on Windows Vista. For information about how to create and apply patches to applications, see Using Windows Installer with UAC (https://go.microsoft.com/fwlink/?LinkId=79711).

Share via