Understanding and Configuring User Account Control in Windows Vista (PART2)
 

این صفحه ادامه بخش اول می باشد برای دیدن بخش اول بر روی PART1 کلیک کنید .

UAC User Experience

در VISTA استفاده از UAC دو حالت متفاوت دارد برای Standard Users , Administrators در این بخش کمی بیشتربه UAC Interface می پردازیم .

در حالت Default در VISTA کلیه User ها هر دو نوع آن که در بالا معرفی شد بصورت Standard User فعالیت می کنند تا زمانی که نیاز به فعالیت

در حالت Full Access Token باشد که در آن زمان Windows VISTA برای هر یک از این دو نوع USER یک Interface متفاوت و جدا ظاهر می کند .

برای Administrator Account یک Interface همانند شکل 1 به نام Consent Prompt ظاهر می شود.

  

    Figure 1: UAC Consent Prompt (Administrator "Current User")

در این حالت دیگر از Administrator Account سوال نمی شود برای وارد کردن Password.

اما اگر همین برنامه را یک Standard User بخواهد اجرا کند برای وی یک Interface بنام

Credentials Prompt  ظاهر می شود همانند شکل 2 که باید نام PWD را وارد کند .

  

    Figure 2: UAC Credentials Prompt (Standard User "Current User")

شما می توانید کاری کنید که حالت بالا که Default می باشد تغییر کند و از Administrator Account نیز PWD سوال شود برای این کار باید Policy زیر

را تغییر دهید و در حالت Prompt for Credentials قرار دهید .

  • User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

Application Aware Elevation Prompts

استفاده از UAC می تواند Interface های دیگری را برای User ایجاد کند که در شکل 3 می توانید آنها را مشاهده کنید .

The following details the elevation prompt color-coding:
  1. Red background and red shield icon: The application is from a blocked publisher or is blocked by Group Policy.
  2. Blue/green background: The application is a Windows Vista administrative application, such as a control panel.
  3. Gray background and gold shield icon: The application is Authenticode signed and trusted by the local computer.
  4. Yellow background and red shield icon: The application is unsigned or signed but not yet trusted by the local computer.

The color-coded elevation prompts align with the color-coded dialog boxes in Microsoft Internet Explorer.

 

    Figure 3: Application aware elevation prompts

زمانی که یک Application برای اجرا نیاز به Full Access Token دارد Windows VISTA آن برنامه را Analyze می کند قبل از اجرا .

سپس یکی از چهار مرحله بالا برای User رخ می دهد .

Shield Icon

هر جا این Icon وجود داشته باشد یعنی اینکه سیستم نیاز به Full Access Token دارد برای ادامه کار خود در این حالت UAC وارد عمل می شود

و برای هر دو نوع Type های User ها بسته به Policy تنظیم شده UAC Interface خود را که یکی از دو شکل 1 و یا 2 می باشد را ظاهر می کند

برای User ها .شما در شکل 4 می توانید بر روی Button این Icon را مشاهده کنید .

 

    Figure 4: Shield Icon

 

Configuring UAC settings

Now that you understand how UAC works and some potential issues that may arise during your Windows Vista deployment in your environment, we can move on to discussing how to configure UAC to optimize security and ease of use.

This section details two main methods for configuring UAC:

Administering UAC with the local Security Policy Editor and Group Policy
Auditing Application Elevations and Process Creation

Administering UAC with the local Security Policy Editor and Group Policy

Prior to Windows Vista, standard users working on a personal computer or in a network setting often had the option of installing applications. The key difference then was that, although administrators could create Group Policy settings to limit application installations, they did not have access to limit application installations for standard users as a default setting. In a UAC environment, they do, and administrators can still use Group Policy to define an approved list of devices and deployment.

There are eight Group Policy Object (GPO) settings that can be configured for UAC. The following table lists the settings and their default values:

UAC settings
Setting Description Default Value

User Account Control: Admin Approval Mode for the Built-in Administrator account.

There are two possible settings:

Enabled - The built-in Administrator will be run as an administrator in Admin Approval Mode.

Disabled - The administrator runs with a full administrator access token.

Disabled for new installations and for upgrades where the built-in Administrator is NOT the only local active administrator on the computer. The built-in Administrator account is disabled by default for installations and upgrades on domain-joined computers.

Enabled for upgrades when Windows Vista determines that the built-in Administrator account is the only active local administrator on the computer. If Windows Vista determines this, the built-in Administrator account is also kept enabled following the upgrade. The built-in Administrator account is disabled by default for installations and upgrades on domain-joined computers.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

There are three possible values:

No prompt – The elevation occurs automatically and silently. This option allows an administrator in Admin Approval Mode to perform an operation that requires elevation without consent or credentials. Note: this scenario should only be used in the most constrained environments and is NOT recommended.

Prompt for consent – An operation that requires a full administrator access token will prompt the administrator in Admin Approval Mode to select either Continue or Cancel. If the administrator clicks Continue, the operation will continue with their highest available privilege.

Prompt for credentials – An operation that requires a full administrator access token will prompt an administrator in Admin Approval Mode to enter an administrator user name and password. If the user enters valid credentials, the operation will continue with the applicable privilege.

Prompt for consent

User Account Control: Behavior of the elevation prompt for standard users

There are two possible values:

No prompt – No elevation prompt is presented and the user cannot perform administrative tasks without using Run as administrator or by logging on with an administrator account. Most enterprises running desktops as standard user will configure the “No prompt” policy to reduce help desk calls.

Prompt for credentials – An operation that requires a full administrator access token will prompt the user to enter an administrative user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.

Home: Prompt for credentials

Enterprise: No prompt

User Account Control: Detect application installations and prompt for elevation

There are two possible values:

Enabled - The user is prompted for consent or credentials when Windows Vista detects an installer.

Disabled - Application installations will silently fail or fail in a non-deterministic manner. Enterprises running standard users desktops that leverage delegated installation technologies like GPSI or SMS will disable this feature. In this case, installer detection is unnecessary and therefore not required.

Home: Enabled

Enterprise: Disabled

User Account Control: Only elevate executables that are signed and validated

There are two possible values:

Enabled - Only signed executable files will run. This policy will enforce PKI signature checks on any interactive application that requests elevation. Enterprise administrators can control the administrative application allowed list through the population of certificates in the local computers Trusted Publisher Store.

Disabled - Both signed and unsigned code will be run.

Disabled

User Account Control: Only elevate UIAccess applications that are installed in secure locations

There are two possible values:

Enabled - The system will only give UIAccess privileges and user rights to executables that are launched from under %ProgramFiles% or %windir%. The ACLs on these directories ensure that the executable is not user-modifiable (which would otherwise allow elevation of privilege). UIAccess executables launched from other locations will launch without additional privileges (i.e. they will run "asInvoker").

Disabled - The location checks are not done, so all UIAccess applications will be launched with the user's full access token upon user approval.

Enabled

User Account Control: Run all administrators in Admin Approval Mode

There are two possible values:

Enabled - Both administrators and standard users will be prompted when attempting to perform administrative operations. The prompt style is dependent on policy.

Disabled - UAC is essentially "turned off" and the AIS service is disabled from automatically starting. The Windows Security Center will also notify the logged on user that the overall security of the operating system has been reduced and will give the user the ability to self- enable UAC.

Note: Changing this setting will require a system reboot.

Enabled

User Account Control: Switch to the secure desktop when prompting for elevation

There are two possible values:

Enabled - Displays the UAC elevation prompt on the secure desktop. The secure desktop can only receive messages from Windows processes, which eliminates messages from malicious software.

Disabled - The UAC elevation prompt is displayed on the interactive (user) desktop.

Enabled

User Account Control: Virtualize file and registry write failures to per-user locations

There are two possible values:

Enabled - This policy enables the redirection of pre-Windows Vista application write failures to defined locations in both the registry and file system. This feature mitigates those applications that historically ran as administrator and wrote runtime application data back to %ProgramFiles%; %Windir%; %Windir%\system32; or HKLM\Software\.... This setting should be kept enabled in environments that utilize non-UAC compliant software. Applications that lack an application compatibility database entry or a requested execution level marking in the application manifest are not UAC compliant.

Disabled - Virtualization facilitates the running of pre-Windows Vista (legacy) applications that historically failed to run as a standard user. An administrator running only Windows Vista compliant applications may choose to disable this feature as it is unnecessary. Non-UAC compliant applications that attempt to write %ProgramFiles%; %Windir%; %Windir%\system32; or HKLM\Software\.... will silently fail if this setting is disabled.

Enabled

 

 

Perform the following procedure to configure the UAC Group Policy settings. You must be logged in as a member of the local administrator’s group to perform the procedure. You can also perform the procedure as a standard user if you are able to provide valid credentials for an administrator account at the User Account Control credential prompt.

To configure the UAC Group Policy settings:

1. Click Start, click Run, type secpol.msc, and then click OK.
2. In Security Settings, expand Local Policies, and then select Security Options.
3. In the details pane (the right pane), right-click the relevant UAC setting and select Properties.
4. Use the drop-down list-box to choose the appropriate value for the setting.
  Note

Modifying the User Account control: Run all administrators in Admin Approval Mode setting will require a computer restart before the setting becomes effective. All other UAC Group Policy settings are dynamic and do not require a reboot.

Audit Application Elevations and Process Creation

The audit process tracking setting enables real-time monitoring of process elevations. For example, the IT department can enable audit process tracking with Group Policy and track each time an administrator in Admin Approval Mode or a standard user elevates a process to a full administrator process.

To audit process tracking

1. Click Start, click Run, type secpol.msc, and then click OK.
2. In the Console pane, expand Local Policies, and then select Audit Policy.
3. In the Details pane, right-click Audit process tracking and select Properties.
4. In Audit process tracking Properties, select Success.

The audit privilege use setting enables real-time monitoring of elevated process creations.

To audit privilege use

1. Click Start, click Run, type secpol.msc, and then click OK.
2. In the Console pane, expand Local Policies, and then select Audit Policy.
3. In the Details pane, right-click Audit privilege use and select Properties.
4. In Audit privilege use Properties, select Success, and then click OK.

UAC Services

The following service is associated with UAC.

 
Service Description

Application Information Service (AIS)

Facilitates the running of interactive applications with a full administrator access token in Windows Vista.

If this service is stopped, users will be unable to launch applications with the additional administrative privileges they may require to perform desired user tasks. As a result, applications that require a full administrator access token may not function correctly unless the Application Information service is running.

 
 

 

Configuring Pre-Windows Vista Applications for Compatibility with UAC

The final, but most important, step in configuring UAC is ensuring that your software was either designed to be UAC compliant or has been configured by the IT department to work properly with Windows Vista.

For new applications that are Windows Vista Logo–complaint, the application must either run with a standard user account or, in the case of an administrative application, be marked with an application manifest entry. When a user attempts to launch an application with an application manifest entry, Windows Vista informs the user that he/she is trying to launch an administrative application and the user needs to provide approval. For more information about Microsoft’s Logo program, visit the Microsoft Windows Logo home page (http://go.microsoft.com/fwlink/?LinkId=71358).

IT departments may find during the rollout of Windows Vista that their existing line of business (LOB) applications no longer function properly. This problem is most likely due to application incompatibility with the enhancements incorporated in Windows Vista. Microsoft provides an Application Compatibility toolkit that will assist IT departments in identifying the compatibility problems and aid in the creation of application compatibility fixes--small amounts of code that are used to fix application compatibility problems.

IT departments may find that some programs need to be able to perform administrative operations in order to function correctly on Windows Vista. For this to occur, the program needs to be marked so that users will be prompted for approval before the application can run with a full administrator access token. The process of marking applications in this manner is called marking an application with a requested execution level. The Application Compatibility Toolkit 4.1 provides the means to build and install the application compatibility database entries, which facilitate the requested execution level marking mechanism.

Fore more information about application compatibility and the Application Compatibility Toolkit 4.1, visit TechNet (http://go.microsoft.com/fwlink/?LinkId=23302).

Marking Applications with Requested Execution Levels for Application Compatibility

The requested execution level selected for an application depends on what type of system-level operations the application is performing. The following are the three different available requested execution levels.

RunAsInvoker: The application should run with the same Windows privileges and user rights as the parent process. This setting is the equivalent as not having an application compatibility database for the application. The application launches with the same privileges as the parent process launching it, which reduces the application’s security exposure. This is because for most applications, the parent is Explorer.exe, which runs as a Standard User application. RunAsInvoker applications started from a cmd.exe shell running as full admin would “run as invoker” with a full administrator access token.

RunAsHighest:

The application should run with the highest Windows privileges and user rights the current user can obtain, but the application does not necessarily require the user to be an administrator. This marking is used for two classes of applications.
The application can be run by both administrators and standard users, and it adapts its behavior based on the user’s privileges and user rights.
The application requires privileges and user rights greater those of a standard user, but it does not require the user to be a member of the local Administrators group. A user that is a member of Backup Operators group is one example. This class of user cannot run applications that require a full administrator access token but can run backup applications. In this case, the pre-Windows Vista backup application should be marked as RunAsHighest.

RunAsAdmin: The application should run only for administrators, must be launched with a full administrator access token, and will not run correctly in a standard user context. This requested execution level marking is reserved for pre-Windows Vista applications that require the user to be a member of the local Administrators group. One difference between Windows Vista and previous versions of Windows, such as Windows XP, is that the operating system will take care of making sure that the application is run with a full administrator access token if it is marked RunAsAdmin in the application compatibility database. In the case where Windows Vista cannot get an administrator access token the application is never started.

Virtualization Marking

IT departments can use the following setting to control file and folder virtualization.

NoVirtualization: The application should run without file and folder virtualization. NoVirtualization would be set for two reasons:

1. Reduce Attack Surface: Applications that allow virtualization are attackable by other standard user applications. There is no mechanism in Windows Vista to differentiate between applications that are allowed to write to specific virtual locations. By turning off virtualization on applications that run well as a standard user, the risk of malware (running as a standard user) attacking the application is greatly reduced.
2. Reduce the time and cost of helpdesk debugging of virtualized data. If you know the application is working well as a standard user application, turning off virtualization will help your helpdesk personnel debug the application because they will not have to look in both the real and virtualized location to examine application configuration data.

Application Compatibility Database Marking and Application Launch Behavior

Whether an application can run and obtain a full administrator access token at runtime is dependent on the combination of the application’s requested execution level in the application compatibility database and the privileges and user rights available to the user account that launched the application. The following tables identify the possible run-time behavior based on such possible combinations.

An Administrator in Admin Approval Mode

 
Parent Process Access Token Consent Policy None or RunAsInvoker RunAsHighest RunAsAdmin

Standard user

No prompt

Application launches as a standard user

Application launches with a full administrative access token; no prompt

Application launches with a full administrative access token; no prompt

Standard user

Prompt for consent

Application launches as a standard user

Application launches with a full administrative access token; prompt for consent

Application launches with a full administrative access token; prompt for consent

Standard user

Prompt for credentials

Application launches as a standard user

Application launches with a full administrative access token; prompt for credentials

Application launches with a full administrative access token; prompt for credentials

Administrator (UAC is disabled)

NA

Application launches with a full administrative access token; no prompt

Application launches with a full administrative access token; no prompt

Application launches with a full administrative access token; no prompt

 

A Standard User Account

 
Parent Process Access Token Consent Policy RunAsInvoker RunAsHighest RunAsAdmin

Standard user

No prompt

Application launches as a standard user

Application launches as a standard user

Application fails to launch

Standard user

Prompt for credentials

Application launches as a standard user

Application launches as a standard user

Prompt for administrator credentials before running application

Standard user (UAC is disabled)

NA

Application launches as a standard user

Application launches as a standard user

Application fails to launch

 

A Standard User with Additional Privileges (E.G. Backup Operator)

 
Parent Process Access Token Consent Policy RunAsInvoker RunAsHighest RunAsAdmin

Standard user

No Prompt

Application launches as a standard user

Application launches as a standard user

Application fails to launch

Standard user

Prompt for credentials

Application launches as a standard user

Application launches as a standard user

Prompt for administrator credentials before running application

Standard user (UAC is disabled)

NA

Application launches as a standard user

Application launches as a standard user

Application fails to launch

 
 

Using the Application Compatibility Toolkit 4.1 and the Standard User Analyzer to Create Application Fixes

The Application Compatibility Toolkit 4.1 and the Standard User Analyzer are free applications from Microsoft that IT departments can use to create application compatibility fixes. The Application Compatibility Toolkit has been enhanced for Windows Vista with the ability to create application compatibility fix database entries, which are used to mark applications with a requested execution level.

The procedures in this section use the following two tools, which are included in the Application Compatibility Toolkit 4.1 download:

Compatibility Administrator: A graphical user interface tool that assists enterprise administrators in creating program compatibility fixes for pre-Windows Vista applications.
Sdbinst.exe: A command-line tool that assists administrators in installing application compatibility fixes for pre-Windows Vista applications.

The procedures in this section also utilize the Standard User Analyzer, a graphical user interface tool that assists enterprise administrators with identifying applications that have application compatibility problems.

Use the following workflow to identify administrative dependencies in applications and to mark applications with requested execution levels:

Step One: Install the Application Compatibility Toolkit 4.1.
Step Two: Install the Application Verifier.
Step Three: Install the Microsoft Standard User Analyzer.
Step Four: Use the Standard User Analyzer to identify pre-Windows Vista administrative applications that do not run correctly on Windows Vista.
Step Five: Determine the requested execution level for each administrative application.
Step Six: Run the Compatibility Administrator program to create an application compatibility fix database.
Step Seven: Install the application compatibility fix on a test computer with the sdbinst.exe command.
  Note

For more information about the appropriate marking for applications, see the Marking Applications with Requested Execution Levels for Application Compatibility section within this document.

Step One: Install the Application Compatibility Toolkit 4.1.

The Application Compatibility Toolkit 4.1 is a free download on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=23302).

Step Two: Install the Application Verifier.

The Application Verifier is a free download on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41326). The Application Verifier is a prerequisite for the Microsoft Standard User Analyzer installation.

Step Three: Install the Microsoft Standard User Analyzer

The Standard User Analyzer is a free download on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=71359).

Step Four: Use the Standard User Analyzer to identify pre-Windows Vista administrative applications that do not run correctly on Windows Vista.

The following procedure illustrates how to identify pre-Windows Vista administrative applications that do not run correctly on Windows Vista by using the Standard User Analyzer.

To identify application compatibility problems for pre-Windows Vista applications
1. Log on to a Windows Vista computer as a standard user.
2. Click Start, click All Programs, and then click Standard User Analyzer.
3. In the Standard User Analyzer, for Target Application, specify the full directory path for an application to test or click the Browse button to locate the program's executable file with Windows Explorer.
4. Click Launch and then provide administrator credentials at the User Account Control credential prompt.
5. After the test application launches, perform standard administrative tasks in the application, and close the application when you have completed.
6. In the Standard User Analyzer, examine the output on each tab. Use this data to identify the compatibility issues that the program might have.

You can also run Application Verifier tests as administrator in the case of a hard privilege failure. For example, if the application, while running as non-administrator, encounters an access violation, which results in the application exiting, you will have only tested the code paths only up to the access violation. If you run the same application as an administrator, you can, in some cases, pass the access violation and exercise the remaining code paths. The logs will still depict those operations that would have normally failed as a standard user.

Step Five: Determine the requested execution level for each application.

Use the data collected from step three to determine the correct requested execution level for the application.

  Note

To determine which requested execution level is appropriate for the application, see the section Marking an Application with a Requested Execution Level.

  Important

Only specify a requested execution level that will enable the application to run properly in Windows Vista and avoid requesting superfluous administrative access with a higher requested execution level.

After identifying an application's compatibility problems with the Application Verifier, use the following procedure to mark the application with a requested execution level.

Step Six: Run the Compatibility Administrator program to create an application compatibility fix database.

This procedure is written with the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode setting configured for Prompt for consent.

To mark an administrative application with the Compatibility Administrator
1. Log on to a Windows Vista computer as an administrator in Admin Approval Mode.
2. Click Start, click All Programs, click Accessories, right-click Command Prompt and select Run as administrator, and then click Continue at the User Account Control elevation prompt.
3. In the Command Prompt, type "C:\program files\Microsoft Application Compatibility Toolkit\Compatibility Administrator\Compatadmin.exe" and press Enter.
4. In Compatibility Administrator, click the Fix icon.
5. On the Create new Application Fix page, under Program information, enter the program name for Name of the program to be fixed, enter the vendor name for Name of the vendor for this program, and enter the program file location for Program file location, and then click Next.
6. In Compatibility Modes, select None and then click Next.
7. For Compatibility Fixes, select the desired requested execution level and click Next.
8. In Matching Information, select the matching information for the application, and click Finish.
9. Click File, and then click Save.
10. Enter a name for the Application Compatibility database and click OK.
11. In Save databaseName, select a name for the database file and click Save.
  Note

Selecting SIZE and PE_CHECKSUM on the Matching Information page of the Create New Application Fix wizard will ensure that the application fix is not inadvertently applied to other applications that may have the same name as the target application.

  Note

Choose a descriptive name to help identify the application compatibility fix. The name provided here will be displayed in Programs and Features in the Control Panel after the application compatibility fix is installed with the sdbinst.exe command-line tool.

  Note

Each application compatibility database created can contain one or more application compatibility fixes for targeted applications.

Step Seven: Install the application compatibility fix on a test computer with the sdbinst.exe command.

To install the application compatibility fix
1. Click Start, click All Programs, click Accessories, right-click Command Prompt and select Run as administrator and then click Continue at the User Account Control consent prompt.
2. In the Command Prompt, type "cd %windir%" and click Enter.
3. In the Command Prompt, type "sdbinst.exe databaseName.sdb" and click Enter.

Removing an Application Compatibility Database Fix

An administrator can remove previously installed application compatibility database entries through Programs and Features in the Control Panel. Uninstalling application compatibility database entries is useful if an application is no longer used in the environment but the fix is still present, or if the application compatibility fix itself requires modification.

To remove an application compatibility fix

1. Log on to a Windows Vista computer as an administrator in Admin Approval Mode.
2. In Control Panel Home, under Programs, select Uninstall a program, and then click Continue at the User Account Control consent prompt.
3. Right-click the application compatibility fix and select Remove.

Deploying Application Compatibility Fixes with Group Policy

This section describes how to deploy the application compatibility database fixes created in the Running compatAdmin.exe section using Group Policy. The IT department can perform the following steps:

1. Create a custom installer Microsoft Visual Basic script (VBScript).
2. Create a Windows Installer package for each .sdb database.
3. Authenticode sign the Windows Installer package.
4. Test the Windows Installer package.
5. Deploy the Windows Installer package with Group Policy.

Create a Custom Installer Microsoft Visual Basic Script (VBScript)

Before creating the Windows Installer package, the IT department must create a VBScript that will perform the custom installation. This process only has to be done once, and the same script file can be used for all other Windows Installer packages.

The following is an example script:

'--------------------------------------------------------------------------------------
'  Filename         : setsdb.vbs
'  Description      : Installs SDB entry in appcompat database
'  Version          : 1.0
'--------------------------------------------------------------------------------------
' History:
'   07-19-2005:  Created version 1.0

dim Ws
myCmdArgs = Session.Property("CustomActionData")
setDir = "%ComSpec% /C sdbinst.exe -q " & chr(34) & myCmdArgs & chr(34)
set Ws = CreateObject("WScript.Shell")
retval = Ws.Run( setDir, 2, true )

Create a Windows Installer Package for Each .sdb Database with Visual Studio 2005

The following example shows how to create a Windows Installer package to deploy the application compatibility fixes using Microsoft Visual Studio 2005.

To create the Windows Installer package
1. Click Start, click All Programs, and double-click Visual Studio 2005.
2. In Visual Studio, click File, and then click New Project.
3. On the New Project page, expand Other Projects, and select Setup and Deployment Project in the left-hand pane. Select Setup Project in the right-hand pane, enter a name for the application compatibility fix deployment, and then click OK.
4. In Solution Explorer in the right-hand pane, right-click the name of the deployment project, point to Add, and then click File….
5. In Add Files, browse to the location of the .sdb database file, and then click Open.
6. Repeat steps 4 and 5 and add the name of the custom action VBScript created previously.
7. In Solution Explorer in the right-hand pane, right-click the name of your deployment project, point to View, and then click Custom Actions.
8. On the Custom Actions tab, right-click the Commit folder, and then click Add Custom Action.
9. In Select Item in Project, double-click the Application folder, select the VBScript file, and then click OK.
10. Right-click the Commit action called setsdb.vbs in the left-hand pane, and then click the Properties window.
11. Add the following line to the CustomActionData property: [ProgramFilesFolder][Manufacturer]\[ProductName]\[FILENAME].sdb.
  Note

There is no backslash (\) between [ProgramFilesFolder] and [Manufacturer]

12. On the File menu, click Build, and then click BuildSolution. After the build completes, the Windows Installer package will be added to the debug folder.

Authenticode Sign the Windows Installer Package

After the IT department creates the Windows Installer package, Microsoft recommends that it be Authenticode signed before being deployed by using Group Policy. This document is written with the assumption that the IT department has already created a signing key for the enterprise with which to sign their deployment Windows Installer packages. The signing and verification tools used in the following examples are included in the Microsoft .NET Framework SDK (http://go.microsoft.com/fwlink/?LinkId=32131).

The following is an example of how to sign the Windows Installer package with the enterprises' signing key:

signcode –v <path>yourkey.pvk –spc <path>yourkey.spc (deployment package).msi

To include a timestamp in the signature, include the following parameter on the command line:

–t http://timestamp.verisign.com/scripts/timstamp.dll 

The IT department can verify the signature with the following command:

ckhtrust (deployment package).msi

If the file validates and the signing certificate chains to a trusted publisher certificate in your environment, chktrust.exe will simply return with a success return code.

Additional information about Microsoft Authenticode Technology can be found at MSDN (http://go.microsoft.com/fwlink/?LinkId=71361).

Test the Windows Installer Package

After the IT department has created the Windows Installer package, it can test the package by copying the Windows Installer file to a target computer and double-clicking it to open the Microsoft Windows Setup Wizard. The following procedure provides an example of how to test a Windows Installer package.

To test the Windows Installer package
1. Locate the Windows Installer (.msi) file and double-click it to begin the setup.
2. On the [NameofWindowsInstallerPackage] Select Installation Folder page, select the installation folder and click Next.
3. On the Confirm Installation page, click Next.
4. On the Installation Complete page, click Close.
5. Click Start, click Control Panel, and then double click Programs and Features.
6. In the Programs and Features control panel, verify that the application compatibility fix installer and application compatibility fix entries are present.

Deploy the Windows Installer Package with Group Policy

By using Group Policy, the IT department can ensure that any application compatibility fixes they create can be deployed to all their client machines automatically. This section contains the basic steps that the IT department could use to set up this deployment. Additional information about staging Group Policy deployments can be found at TechNet (http://go.microsoft.com/fwlink/?LinkId=71349).

The first step is to place the Windows Installer deployment package on a file share that is available to all the computers that should receive the fix. This can be the entire domain, or restricted to organizational units (OUs). Microsoft recommends that the IT department ensure that the Windows Installer package has the proper Access Control List (ACL) entry on the file share to allow access only to appropriate computers.

Perform the following procedure once the Windows Installer file is in place. You must log in as a Domain Administrator to perform this procedure.

Add the Group Policy to Active Directory
1. Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
2. Right-click the domain name in the console (left-hand) pane, and then click Properties.
3. On the Properties page, click the Group Policy tab.
4. On the Group Policy tab, click New and then enter a name for the new Group Policy Object (GPO).
5. Highlight the newly created GPO and click Properties.
6. Because application compatibility fixes are being applied to the computers in the domain and not the users, select the Disable User Configuration settings check box. If a confirmation dialog box appears click Yes.
7. Click the Security tab and add any necessary ACLs to allow the domain computers access. Ensure that Read and Apply Group Policy is selected, and then click OK.
8. On the Properties page, click Edit.
9. In the Group Policy Object Editor, in the Console pane, expand Computer Configuration and then expand Software Settings.
10. In the Details pane, right-click Software Installation, click New, and then click Package.
11. Select the package to deploy in the Open dialog box, and then click Open.
12. In Deploy Software, select Assigned, and then click OK.
13. Close the Group Policy Object Editor.
14. Close the Properties page.
15. Exit Active Directory Users and Groups.
  Note

Step 12 in the preceding procedure causes the package to be installed on the target computers without any user interaction required. The Windows Installer package that was selected will then be displayed in the Group Policy Object Editor.

Testing and Verifying the Windows Installer Deployment

Use the following procedure to test the Windows Installer deployment.

To test the Windows Installer deployment
1. Reboot a computer a domain-joined computer.
2. Before the user login screen is displayed, Group Policy will automatically install the Windows Installer package onto the computer.

Use the following procedure to verify the Windows Installer deployment.

To verify the Windows Installer deployment
1. Log on to the computer from the previous procedure as an administrator in Admin Approval Mode.
2. Click Start, and click Control Panel.
3. In Control Panel Home, click Programs, and then click Installed Programs.
4. In change or remove a program, verify that the Windows Installer package and application compatibility database entry is installed.
 

Summary

UAC offers a new approach to improving computer security by fundamentally changing the way applications interact with an operating system and its files. Microsoft is working with developers to continue to innovate and create technology that minimizes the impact of malware. With UAC and using Windows as standard users, organizations and end-users are significantly less susceptible to security vulnerabilities that compromise the system. With the release of Windows Vista, Microsoft has developed a mechanism for running applications in standard user mode and for performing common operating system configuration tasks that would normally require a full administrator access token.

 

Last Updated: November 10, 2006

Winteacher.com
Expert Zone > Understanding and Configuring User Account Control in Windows Vista (PART2)

 © 2003-2006 Winteacher.com . All rights reserved