User Account Protection (UAP) : Windows Vista changes the traditional Windows privilege model to help prevent users from running programs that attempt to perform operations that the user doesn't really intend or authorize. To that end, User Account Protection (formerly called Least-privileged User Account, or LUA) enables users to run at low privilege most of the time, while being able to easily run applications requiring more privilege as necessary. There are two key things to consider when building applications to make use of User Account Protection (UAP): the privilege specification model and the standard UAP execution model.

Privilege Specification Model : UAP extends the access token system already in use for managing Windows logons with a new token mechanism that supplies each administrator logon with two security tokens, a UAP token and a full admin token.

Access tokens contain a logon session's security information, identifying a user and their groups and privileges. The operating system uses the token to control access to securable objects and controls the ability of the user to perform various system-related operations on the local computer. UAP tokens are a special kind of access token that define the minimum privileges needed to run-the default interactive logon privileges of a Windows Vista user on a system with UAP support enabled. The second, full admin token has the maximum privileges authorized for the admin account.

UAP Execution Model : Beyond tokens, the basic execution model for running applications under UAP uses existing process-creation functions (ShellExecute to call CreateProcess) augmented by UAP. There are four parts to the UAP execution model:

1. The Application Information Service (AIS) is a system service that launches applications requiring elevated privileges by first obtaining user consent (through the Consent User Interface) for privilege elevation, and then creating a new process for the application with the user's full token.
2. The Consent User Interface is launched by the AIS and runs with system privilege to get consent or credentials from the user in order to launch the application with a full token.
3. Requested Execution Level is a characteristic of an application that indicates which token (UAP or full) to use when it is launched. The system determines an application's Requested Execution Level by reading requestedExecutionLevel from the application's manifest, querying the Windows Vista AppCompat database entry, or by using the Windows Vista installer detection technology.
4. The AppCompat database supplied with Windows Vista contains information about the most common legacy applications that require privilege elevation.

Here's an example of the control flow of running an application under UAP:

• When a user tries to start an application, the Windows shell uses ShellExecute to call CreateProcess.
• CreateProcess determines whether the application requires elevated privilege by querying the application manifest, the Windows Vista AppCompat database, and the system installer detection technology in that order.
  • If the application does not require elevated privilege the process is created through NtCreateProcess.
  • If the application requires elevated privilege, CreateProcess, through a call to NtCreateProcess, returns a specified error to ShellExecute.
• On receipt of the error ShellExecute calls across to the Application Information Service (AIS) to attempt the elevated launch.
  • AIS then prompts the user for consent through the Consent User Interface.
  • ShellExecute then reissues CreateProcess for the user with the user full token to launch the application on the client's (UAP) desktop.
• NtCreateProcess launches the application with the specified full token.
  • NtCreateProcess prompts user for consent through the Consent User Interface.
  • NtCreateProcess reissues CreateProcess for the user with the user full token to launch the application on the client's (UAP) desktop.
  • NtCreateProcess launches the application with the specified full token.

Building UAP-Compliant Applications : Developers using Visual Studio tools can analyze their code for UAP compliance by using the AppVerifier tool. Both ClickOnce and the Windows Vista version of MSI (Windows Installer) technology are fully UAP compliant, and all application developers should try to make use of these technologies when working with installers.

Keep in mind that UAP compliance is all about least privilege. If your application runs properly under a nonadministrative account in Windows XP or Windows Server 2003, you won't run into any problems on Windows Vista.

To ensure that your application runs properly under Windows Vista, you should test your application as a USER.

• Identify and fix bugs to enable your UI to run as USER.
• If your UI does not require any administrator privileges to function, validate this by testing your UI as a USER and verify that all operations function correctly.
• If your UI only functions with administrator privileges, validate by testing your UI as a USER and verify that the UI requests elevation before launching.

For an application that provides different functions depending on whether the user is an Administrator or USER, there will be a way to allow for variable access to the application's administrative features.