UACBlog

Windows Vista Application Development Requirements for UAC Compatibility

Our updated guidance for ISVs is now available for you to download at the Microsoft Download Center. We'll have a "browesable" form on MSDN as part of the Windows Vista Developer Story shortly, as well. I'll post a link on the blog when it goes live.

The download page for the "Windows Vista Application Development Requirements for UAC Compatiblity" document is here: http://www.microsoft.com/downloads/details.aspx?FamilyID=ba73b169-a648-49af-bc5e-a2eebb74c16b&DisplayLang=en.

-Jenn Allen

ActiveX Installer Service Discussion and Video

This is Joel Yoker, Senior Consultant, and Rob Campbell, Technical Solutions Specialist, from the Microsoft Federal (Government) District. Many of the customers that we work with have locked-down desktop environments. One of the challenges that these customers face is how to deploy ActiveX controls in an environment where users are not administrators. ActiveX controls are designed to be installed interactively by the user, but standard users don’t have privileges to install ActiveX controls. The ActiveX Installer Service (AxIS) in Windows Vista is designed to solve this problem by giving IT a way to use Group Policy to determine which controls their users can install, even if they don’t have administrator privileges.

To illustrate AxIS in action, we have included a complete walkthrough of the installation and configuration of AxIS on Windows Vista RC1 in this video: Start video 100k | 300k

One of the biggest challenges with ActiveX controls is enabling the use of trusted objects while mitigating potential threats. In some customer segments, ActiveX and related technologies are labeled as “mobile code” and considered potential threats to the computing environment. The problem is that at the end of the day, depending on rights, the decision to install a particular ActiveX control (good or bad) is left up to an individual user. This means that in a 10,000-user environment, the decision to introduce spyware/malware into the environment could potentially be made by 10,000 different individuals within the organization. Let’s look at the problem for a moment, how previous versions of Windows mitigated this threat, and the innovative way Vista handles this with the ActiveX Installer Service (AxIS).

By default in Windows Vista (and in previous versions of Windows), only those with local Administrator rights have the ability to install ActiveX controls. Once installed, any user of the system can invoke a given ActiveX control. This is controlled by a series of registry and file system Access Control Lists (ACLs). While the default behavior is a good approach, it does not address the problem of allowing specific ActiveX controls that are in use with internal applications to be installed by end users. To address this gap, there are many different approaches, some of which are outlined below:

• Pre-installation of ActiveX controls

• Modifying URLActions (such as Install Signed ActiveX controls) on specific Internet Explorer Security Zones

• Designating an internal Internet Component Download Server (by manipulating the CodeBaseSearchPath registry value)

• Administrator Approved Controls (via Group Policy)

• Blocking at the perimeter

Without diving into details on each of these methods, it is safe to say that they each have certain flaws. Each of the solutions addresses areas such as blocking where ActiveX controls come from, where they can be invoked from, and so on; however, these solutions do not mitigate the fundamental problem that users without Administrator rights cannot install ActiveX controls. In addition, each of the solutions listed above comes with a large administrative burden, particularly with the frequent changes found within the landscape of internal applications. What we have witnessed in some customer organizations are solutions ranging from end users being granted temporary/permanent administrative access on their workstations to the extreme of the default permissions in the operating system being modified to allow end users the ability to install ActiveX controls.

Enter Windows Vista and AxIS -- the solution to the problems outlined above. AxIS provides corporate administrators the ability to identify trusted sources of ActiveX controls, and provides standard users the ability to install controls from those trusted sources. The key benefit of this solution is that a non-administrative security posture is maintained on user workstations. A short explanation of the ActiveX Installer Service is provided by our good friend Chris Corio here (http://blogs.msdn.com/uac/archive/2006/06/14/631416.aspx). As described by Chris, this is enabled by identifying trusted locations where ActiveX controls are being installed from and having a service on Windows Vista install the ActiveX control on the user’s behalf (since any user can invoke a control once installed). If a control isn’t previously identified by Group Policy, the standard behavior will occur requiring administrative rights. However, an event will be logged in the Application event log (EventID 4097 from Source Microsoft-Windows-AxInstallService) outlining the attempted ActiveX control installation, along with the specific download path to the control. The data from this event log entry can then be used by the corporate administrator to modify Group Policy, allowing the control to be installed by AxIS on subsequent visits to the site. Furthermore, the ability to attach tasks to events in Windows Vista provides an easy way for anyone to receive a notification from the AxIS service (such as when the installation of an ActiveX control is blocked).

What does this mean practically? This means that through a simple Group Policy change and a service that can be enabled on Windows Vista, you can take control of which ActiveX controls are installed by end users across your entire organization. This also eliminates a common justification that end users cite when they request administrative rights on their systems. AxIS provides organizations with another tool to take a least-privilege approach to end-user rights on desktop systems. The choice of which ActiveX controls are “trusted” within the corporate environment are determined the organization, not the end user.

If you have Windows Vista RC1, we encourage you to give this feature a try. The next step for those planning Windows Vista deployments is to start a dialog with the developer community within your organization and identify all of the trusted locations where ActiveX controls could possibly come from.

-- Joel and Rob

UAC Improvements in Release Candidate 1 (RC1) and Video

We’d like to thank all of the Windows Vista beta testers for using and giving us feedback on User Account Control. It’s definitely an area where we’ve received significant feedback, and an area where we’ve been able to make significant improvements in Windows Vista Release Candidate 1.

On June 1, Steve Hiskey, Lead Program Manager for the User Account Control, blogged about the team’s plan to reduce the prompts in RC1. We’ve created a video to show you some of the work the team has done since then.

> Watch video

Prompt reductions shown in the video:

• File operations, reducing the prompts caused by adding, deleting, or editing files in protected directories. For example, administrators can delete shortcuts from the public desktop without receiving a prompt. And the user should no longer receive a prompt when copying files to a newly formatted storage drive.

• Re-architecting several Control Panel applets so that they no longer prompt when opened. Examples include the Firewall applet, Scanners and Cameras applet, and the Software Explorer of Windows Defender.

• Reducing prompts when creating new network connections.

In addition to the prompts in the video, users can install high-priority updates without a prompt, and will receive fewer prompts caused from unknown devices and driver installation. Based on these changes, we are finding that, on average, users are not receiving any prompts most times that they use Windows Vista.

Other improvements besides prompt reduction that we’ve made to Windows Vista RC1 are:

• ActiveX installer service enables standard users to install approved ActiveX controls.

• UAC prompts will not “steal focus” from the user’s task. If the operating system cannot determine that the prompt was generated from the foreground window the current user is using, we will alert the user with a highlighted operation in the taskbar that an application is requesting elevated privileges. The user can select to elevate at his or her convenience and not be disrupted by an unplanned application elevation.

• Elevations are now blocked in the user's logon path. Applications improperly elevating during each and every logon were a significant source of feedback from the Beta 2 release, and based on that feedback, we are disallowing elevations during logon.

• The command prompt window will now read “Administrator” in the title bar if run with elevated permissions.

• Improved performance when switching to the secure (dimmed) desktop to display the prompts. We received significant feedback that the small delays during switching were disruptive, and we have worked with the video and display teams to enhance the user experience in this area.

If you’ve used an earlier version of Windows Vista, we are confident that you’ll notice the improvements in RC1. If RC1 is your first chance to use Windows Vista, you’ll probably wonder what all the fuss was about.

- Alex Heaton
Windows Vista Security

Built-in Administrator Account Disabled

Darren Canavor, Program Manager on the UAC team has made a post on the Windows Vista Security blog about changes to the behavior of the built-in Administrator account:

“In Windows Vista we made numerous changes to our user account model. Standard users are now the default user type for new accounts created after initial setup. The Power Users group is effectively deprecated. In addition, we’ve made it much easier to run as a standard user and even administrators run with limited Windows privileges and user rights by default. But people often ask us, “What about the built-in administrator account? Isn’t it a security risk to have an administrator account with no password?”  Yes, in some cases this administrator account could be used to circumvent other security mechanisms. For example, parental controls could not be effective if the child could simply login with the built-in administrator account and do whatever they want, including disabling the Parental Controls.

In Windows Vista RC1 we will have completed a series of changes to disable the built in administrator account under most circumstances. These changes apply to the default administrator account named Administrator, which is created during setup.”

See full post at http://blogs.msdn.com/windowsvistasecurity.

Elevations Are Now Blocked in the User's Logon Path

Hi, Jim Hong, Program Manager on UAC, here again to tell you about a new change in the UAC user experience coming in RC1. Applications that start when the user logs on and that require elevation are now blocked in the logon path.

Without blocking applications from prompting for elevation in the user's logon path, both standard users and administrators would have to respond to a User Account Control dialog box on every log on. While this potentially becomes an annoyance for administrators, it is an unusable UI for standard users who cannot drive the UAC elevation prompt without having an administrator around to provide credentials. Furthermore, we advise users to be wary of prompts that appear without them taking an explicit action -- and prompts generated at startup go against that advice.

In RC1 and later, Windows Vista notifies the user if an application has been blocked by placing an icon in the system tray and providing a notification balloon during the startup sequence. See Fig. 1 for a visual of what this might look like:

<>

In many cases, users can operate their computers normally without the software that was skipped. However, in cases where the skipped application may be needed, users can then right-click this icon to run the applications that were blocked as they logged on. The user can elect to manage which startup applications are disabled or removed from this list by double-clicking the tray icon and bringing up the default application that controls Startup programs.

The areas where these applications are blocked from are:

• Per-user Startup Folder
• Per-user RUN Key
• Per-machine Startup Folder
• Per-machine RUN Key

Independent Software Vendors who wish to have part or all of their software suite run during the startup process are encouraged to architect their applications to run AsInvoker so that all users (that is, administrators and standard users) can run the software without the need for a UAC elevation.

A couple of exceptions to note: First, setup applications that need to complete their setup after a reboot should be putting their application in the RunOnce key. This key gets consumed by the next Administrator account that logs on, and the setup will continue without the need for an elevation. (This key can only be set by a program running with elevated privileges.) Second, applications that require UAC elevation that gets pushed out via the POLICY\RUN keys will not get blocked at logon. Therefore, they will run and will either result in the Secure Desktop prompt or appear in the taskbar as a blinking button that will require user input before the desktop switch occurs.

This feature will really help users with streamlining the logon path so that they can start using their Vista PCs quickly, with as little distraction as possible. Users maintain control of these UAC elevations. This reinforces the UAC theme of putting admin elevation under the user's control.

User Account Control Virtual Lab

The TechNet team has a released a virtual lab that lets you get some experience with User Account Control even if you haven’t installed it on any of your machines. And if you have Windows Vista installed, the tutorials can help you learn about User Account Control in a more structured way. My only caveat about these labs is that Windows Vista is much cooler in person. These desktops are running the Windows Standard theme, which looks like Windows 2000, and the performance is not 100% snappy. But it is a good primer on UAC basics.  There are also labs on the new firewall, group policy settings, and the User State Migration Tool.

http://www.microsoft.com/technet/traincert/virtuallab/vista.mspx

- Alex Heaton

Flash Swag: Windows Vista Build 5472 DVD

I have a few DVDs left that I want to share with UAC blog readers so that you can see the progress on the prompt reduction work we’ve been doing since Beta 2. This build also has the new ActiveX Installer Service.

The first 75 people who send e-mail to [deleted] with their mailing addresses can get a DVD and product registration key. These copies expire May 31, 2007. We will not use your contact information for any other purpose and will delete all e-mails as soon as the DVDs are distributed. If you already have access to this build through one of the beta programs, please don’t request one of these DVDs so that someone else can get one.

Thanks to everyone for reading and for your comments. We hope to do more giveaways in the future.

- Alex

Administrator Marking for Command Prompt

Besides reducing the number of prompts, one of the top requests we’ve gotten is a way to identify whether a window (particularly Command Prompt) is running with reduced privileges. If you asked for this, too, you’ll be happy to know that when Windows Vista Release Candidate 1 comes out you’ll be able to tell.

When you run cmd.exe as an administrator...

 
“Administrator” will be pre-pended to the title bar of the window...

 
This is designed for scenarios where you have multiple command windows open and you want to know which ones are elevated. You will also be able to tell which ones are elevated by looking at the taskbar...

This functionality is not enabled for all programs, but we got feedback that Command Prompt needed it most. Overall, our user experience goals with regards to UAC are:

(a) A user should be running as a standard user all the time.
(b) Elevation should be rare and for a very short duration.

As a result of these goals, a user should not have to keep track of what is running elevated and what is running normal, as in general, there should be nothing running elevated all the time.

In our research, we have not come across many applications that have valid scenarios where they should be running normal and elevated on a continuous basis for long durations. Command Prompt is one such application that people tend to run continuously as normal as well as elevated to perform mostly script- or batch-oriented tasks.

Therefore, based on feedback received, and just for Command Prompt, we have made changes such that if Command Prompt is running elevated, its title will be prefixed with “Administrator:” to help a user distinguish between a normal and elevated CMD.

Even though we provide this facility, from a security point of view, our recommendation remains that you keep the elevated CMD on your desktop for as short a duration as possible so as to avoid any inadvertent changes to your computer without further UAC prompts.

Webcast Recap

Thanks to everyone for joining the webcast on Tuesday and to Chris Corio for helping to answer questions. People asked a lot of good questions, so we wanted to share the transcript with others who may have similar ones.  For those who missed it, you can watch the replay here.

 

I always start my webcasts with a poll asking attendees what percentage of their users has admin rights today. Here is that data:

 

Then, at the end, I ask what percentage will be administrators on Windows Vista:

Not a scientific study, from just about 50 people or so, but we generally see that today about 80 percent of users have administrator rights, and on Windows Vista, customers are anticipating that will drop considerably.

 

 

On to the transcript…

 

Question: Can I ask technical questions while the presentation is going on?

Private Answer: Yes

 

Question: Will this be in the form of an on-demand webcast?

Answer: Yes. Watch your inbox tomorrow for an e-mail with information about viewing this webcast on demand and downloading a WMV file. The e-mail will also include a link to a downloadable PowerPoint presentation of today’s webcast.  [Anyone can watch it again here.]

 

Question: I connected some Windows Vista workstations to an SBS2003 server, and every logon, the default SBS2003 logon script runs a Client\Setup.exe, which kicks up the UAC screen. This does not seem to be a desirable feature of every logon.

Answer: This is something that we are working with the SBS team on right now. This logon script updates binaries and settings configured by SBS, but it is rarely updated. Currently, we recommend that you propagate an App Compat shim marking the client\setup.exe binary as not requiring Administrator privileges. The proper run level would be asInvoker.

 

Question: How can you run things as an admin that don't specifically have a Start menu icon? For instance, an applet in the taskbar that requires admin access (but right-click over doesn't allow for "Run as...").

Answer: You can either browse to the binary and right-click it, or you can run a CMD window with Administrator privileges and run it there.

 

Question: What is Microsoft doing to educate vendors on how to write applications that don't require admin rights?

Answer: We've done our best to let all developers and ISVs know about this product by presenting at numerous conferences since PDC '05. We also have guidance available online. Check out the resources slide for those links.

 

Question: Is it possible for IT departments to update the app compat list using, say, GPO or SMS?

Answer: Yes. You can use GP to deploy the App Compat shims.

 

Question: I am asking about the domain users in the local machines. Does this apply to it?

Answer: UAC applies to both domain users and local users.

 

Question: You have mentioned App Compat shims several times in the replies. Is there some detailed documentation on App Compat Shims available?

Answer: Yes, take a look at: http://www.microsoft.com/technet/windowsvista/deploy/appcompat/acshims.mspx

 

Question: So you can drop a manifest in alongside an app that you did not produce (e.g., I have an app from a defunct ISV)?

Answer: Yes, as long at the app does not have an internal manifest, which would override the external one. You can also use the tool mt.exe (shipped with Visual Studio) to add an internal manifest to an existing .exe.

 

Question: My initial take on UAC is you are simply masking over the real problem of users with admin rights. If they have an admin password, they are only one step away from hacking their computer. Will we be able to identify and customize the ACLS on all system components based on application requirements to allow these applications to run without supplying an admin password?

Answer: Our goal is to reduce the privileges that applications are designed to run with. Unfortunately, because all of our users prior to Windows Vista were members of the Administrators group, applications often unnecessarily required that the user be an administrator. We are trying to help the industry understand that oftentimes they don't need administrator privileges to execute their applications, and we expect many users in enterprises to no longer run as administrators.

 

Question: Can the local store be relocated to better support roaming profiles?

Answer: Unfortunately, the location of the virtual store isn't configurable.

 

Question: That so it is of stability? (Sorry for my English) will be able to use the old standard user or not?

Answer: You can still run your users as member of the users group. If you want exact parity between XP, you should disable the UAC installer detection feature and file virtualization.

 

Question: I referred to me that in spite of being a beta, if Windows Vista is stable in its totality or still it has things to correct.

Answer: We continue to refine Windows Vista as we move toward release. We feel that the beta version is quite stable.

Question: I'm still confused. Applications don't "require" admin rights. Applications perform tasks on a computer that accesses system components (directories, registry, services, etc.) that are locked down to admins only. Can we not identify these components in advance and adjust the ACLs on these components to give the standard user the ability to access?

Answer: You could do this, but then any malware running as the user could also change those settings. This would undermine any security model that an application or Windows has established for those resources.

 

Question: In what SKUs is the secpol available?

Answer: secpol.msc is available in all SKUs [Correction from live chat: secpol will only be available in the SKUs that support group policy: Business, Enterprise, and Ultimate.]

 

Question: Given that we'll be running in a mixed environment at first (Windows XP and Windows Vista), will any level of these controls be available for XP via a patch?

Answer: There are currently no plans to move UAC down-level. However, as you understand which applications can run as standard users on Windows Vista, you can move your Windows XP users into the Users group and get similar performance.

 

Question: How can I make a white list program by vendor or by location or what?

Answer: Check out the Software Restriction Policy white paper available here: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx

 

Question: What was that again? If I disable UAC, do I also lose the new security features of Internet Explorer?

Answer: Internet Explorer will not be running in Protected Mode if UAC is disabled.

 

Question: What is the URL for the compatibility tools?

Answer: http://www.microsoft.com/technet/desktopdeployment/appcompat/toolkit.mspx

 

Question: Can we see the vote results?

 - Alex

 

posted by UAC | 1 Comments

UAC Developer Screencasts

I’m Jeremy Mazner, Group Manager of the Windows Vista platform evangelism team (the same folks behind www.seewindowsvista.com),  we make sure early adopters of the Windows Vista platform have the information they need about UAC.  While we most often work 1:1 with partners, we recently asked Ian Griffiths to record some short screencasts to share this information with the dev community at large.  Check out How To: Tell Vista's UAC What Privilege Level Your App Requires (24 minutes, but worth it!) and How To: Use Vista's UAC Feature To Avoid Always Requiring Admin Rights (18 minutes) to see Ian walk through the code needed to embed a UAC manifest, and refactor an application so that the main executable runs as standard user, and calls an elevated COM object when it needs to do administrative tasks.

 

(And if you’re doing Windows Vista development, you might also enjoy How To: Use Vista's Power Management APIs to Be A Good Laptop Citizen and How-to: Query Vista Search From Your App)

 

-          Jeremy

(Comments disabled on this thread because it was getting deluged with spam.)

“Certified for Windows Vista” Software Logo Requirements

Critical to the success of User Account Control is having software that works well for standard users and administrators, without excess prompts. Since User Account Control is such a central part of Windows Vista, User Account Control compatibility is one of the key requirements to display the Certified for Windows Vista Logo on software.

v 1.0 of the Certified for Windows Vista Software Logo Technical Requirements is available now.  Our goal in sharing this information on our blog is to make sure that any ISV’s reading this are aware of the requirements so that they have ample time to make their product compliant and to give our customers confidence that there will be a great supply of software that works well for standard users and UAC.

Some of the key requirements that relate to User Account Control and running as a standard user:

·         Make sure the application works well for standard users, unless it is something truly designed to be run only by system administrators such as disk partitioning software.  If the program has admin and non-admin components the main application should still be run as a standard user and administrative features should be moved to a separate executable.

·         Every .exe file included with an application must have an embedded manifest that defines its execution level. Such as: 

<requestedExecutionLevel level="asInvoker|highestAvailable|requireAdministrator" uiAccess="true|false"/>

Note, including the manifest file will disable File and Registry Virtualization for the application. So the application has to work well for a standard user without relying on virtualization.

·         Executable files with .EXE, .DLL, .SYS, .DRV, .OCX, .CPL, or .SCR extensions must be signed with an Authenticode certificate.

·         Installers must not assume that the person who starts the installation is the one who finishes the installation. For example if your program allows per user and all user installations, a standard user should be able to start the install, but it should prompt for admin credentials if the user chooses the all users option.

·         If the installer uses a boostrapper/chainer, it must include an embedded manifest that designates the desired execution level for the installer. 

Another big change in the Certified for Windows Vista logo requirements is that applications must be independently tested by a Microsoft approved testing vendor before they are granted logo certification.  A draft of the test cases that will be used to verify compliance are posted here.

We’ve also provided a number of resources to help developers make their software Windows Vista and User Account Control compatible, including:

·         Developer Best Practices and Guidelines for Applications in a Least Privileged Environment

·         Microsoft Standard User Analyzer

·         Windows Vista Jumpstart Toolkit

Learn more about the Certified for Windows Vista Software Quality Logo program including how to enroll your company’s software at http://www.isvinnovationportal.com/windowsvista.

When developers release software that meets the Certified for Windows Vista requirements, users will experience even fewer User Account Control prompts than they are seeing on beta versions today. And the Windows Vista team will continue to minimize the number of OS-generated prompts and help make as many legacy programs as possible work without prompting to ensure a good User Account Control experience in the final release.

 - Alex Heaton
   User Account Control Product Manager

"How do I turn off that annoying User Account Control?"

Hi, Aaron Margosis here.  I'm not actually on the UAC team, but we're good friends and share a common passion about running Windows with least privilege.

Those of you who follow this blog are probably aware that there has been... well, let's say dissatisfaction ... (yes, that's putting it nicely)... with the current implementations of UAC.  One of the frequently asked questions about Vista today is "How do I turn UAC off?", and even some "experts" suggest turning it off.

There are two ways to answer the question.  There is the technically correct answer involving Local Security Settings, and then there is the better answer that Jesper Johansson recently posted on his blog that offers a compelling argument for leaving it on.  If you're thinking of turning off UAC, read what Jesper has to say.  Why?  Because he's right! :-)

TechNet Webcast: Limiting Administrator Privileges with User Account Control (UAC) in Windows Vista (Level 200)

Thanks to everyone who joined the chat last week, we hope you found it helpful. On Tuesday July 25th at 9:00 AM PST we will also host a live Web Cast on how User Account Control can help deploy desktops as a standard user. This Web cast is indented for IT pros and will cover the general capabilities of User Account Control. Hopefully, if LiveMeeting behaves on Windows Vista we will be able to show you some demos of the File and Registry Virtualization and the new ActiveX Installation Service.

Webcast description:

Companies today face a difficult trade-off: Is it better to deploy PC users as administrators and accept the high security risk, or to limit user privileges, which has implications for application compatibility and user productivity? User Account Control (UAC) in Microsoft Windows Vista helps solve this problem by allowing standard user accounts to perform common tasks like adding printers and changing the time zone, while also improving application compatibility. This webcast covers the benefits of UAC, UAC architecture, how to administer UAC policy settings, and how to control device installation for standard users. Join us to get the background you need to start planning your Vista deployment with standard user privileges.

 You can sign up at the Events and Webcasts site. We hope to see you there.

- Alex Heaton 
   User Account Control Product Manager

What's New in Beta 2? - Group Policy Updates

Since Beta 1, the UAC policies have adapted to address customer recommendations, enhance security, and to enhance usability. Beta 1 included 5 security policies (or Group Policy Objects (GPOs)) and Beta 2 includes 7. The rest of this post will detail each policy and provide background information about why we decided to change or add the policy in Beta 2.

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

This setting was formerly called “UAP: Behavior of the elevation prompt for administrators” in Beta 1. There have been no core changes to the implementation of this setting.

Configuration Options:

No prompt: 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 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: Default for home and enterprise. 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 in Admin Approval Mode selects Continue, the operation will continue with their highest available privilege. “Prompt for consent” removes the inconvenience of requiring that users enter their name and password to perform an administrative task.

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

This setting was formerly called “UAP: Behavior of the elevation prompt for standard users” in Beta 1. There have been no core changes to the implementation of this setting.

Configuration Options:

No prompt: Default for enterprise.This option results in an “access denied” error message being returned to the standard user when they try to perform an operation that requires a full administrator access token.  Most enterprises running desktops as standard user will configure the “No prompt” policy to reduce help desk calls.

Prompt for credentials: Default for home. 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.

3. User Account Control: Detect application installations and prompt for elevation

This settings was formerly called “UAP: Elevate on application installs” in Beta 1. There have been no core changes to the implementation of this setting.

Configuration Options:

Enabled: Default for home – computers in a workgroup. Application installation packages that require a full administrator access token to install will be heuristically detected and trigger the elevation prompt.

Disabled: Default for enterprise – domain joined computers. Enterprises running standard users desktops that leverage delegated installation technologies like Group Policy Software Install (GPSI) or SMS will disable this feature. In this case, installer detection is unnecessary and thus not required.

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

This is a new setting in Beta 2.

Configuration Options:

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

Disabled: Default for home and enterprise. This policy is disabled by default.

5. User Account Control: Run all administrators in Admin Approval Mode

This setting was formerly called “UAP: Run all users, including administrators, as standard users” in Beta 1. One core change has occurred to this setting since Beta 1 – the built-in Administrator account is now subject to the UAC functionality. By default, this account is disabled in the enterprise and for home computers where it is the only active local administrator.

Configuration Options:

Enabled:  Default in home and enterprise. This policy enables the “administrator in Admin Approval Mode” user type while also enabling all other UAC policies.   Changing this setting requires a system reboot.

Disabled: Disabling this policy disables the “administrator in Admin Approval Mode” user type.  Note: The Windows Security Center will also notify that the overall security of the operating system has been reduced and gives the user the ability to self enable.

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

This is a new setting for Beta 2.

Configuration Options:

Enabled: Default for home and enterprise. UAC elevation prompts appear on the secure desktop, which is only accessible to Windows processes.

Disabled: UAC elevation prompts appear on the interactive (user) desktop.

For more detail about the secure desktop UX, see Jim Hong’s secure desktop post.

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

This setting was formerly called “UAP: Virtualize file and registry write failures to per-user locations” in Beta 1. There have been no core changes to the implementation of this setting.

Configuration Options:

Enabled: Default for home and enterprise. This policy enables the redirection of legacy 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 either %ProgramFiles%, %Windir%; %Windir%\system32 or HKLM\Software\....

Disabled: Virtualization facilitates the running of pre-Vista (legacy) applications that historically failed to run as Standard User. An administrator running only Windows Vista compliant applications may choose to disable this feature as it is unnecessary.

What's New in Beta 2? - User Experience

Hi, I am Jennifer Allen, a technical writer in the Windows Security Core team. I write technical documentation for UAC, including information for IT pros, developers, and end users. Why am I posting about UAC Beta 2 updates? Well, Windows Vista Beta 2 is hot of the press and ready for you to install, test, and enjoy. You can get the latest Windows Vista beta by registering in the Windows Vista Customer Preview Program. Please note that this is beta code and should not be used in a production environment or on a main machine in the home.

Okay, onto UAC and the Beta 2 “goodness,” as Darren Canavor says. This first post will focus on the user experience (UX) updates that have taken place in Windows Vista Beta 2 versus Beta 1 and the last CTP. I'll follow up this post shortly with a discussion of Group Policy updates in Windows Vista Beta 2.

Several elements of the UAC UX have changed since Windows Vista Beta 1. The first thing that you will notice about the variance in the Beta 2 UX to the Beta 1 UX is the fact that UAC is enabled by default.

This blog post is intended to summarize the main UX updates that occurred in Beta 2. If you would like to read more about the UX changes, you can check out the following two documents:

Getting Started with User Account Control on Windows Vista Beta 2 – Details the Beta 2 UX and basic configuration options. This document also provides information for deploying Windows Vista with UAC enabled in enterprise (managed) and home (unmanaged) environments.

Understanding and Configuring User Account Control in Windows Vista Beta 2 – Detailed information for IT Professionals, including conceptual information, configuration options, configuring and “fixing” legacy applications for Windows Vista and UAC compatibility, and deploying applications for standard users (enterprise).

Elevation Prompt Updates

New Elevation Prompt UI

Figure 1 is an example of a Beta 2 UAC consent prompt.

Figure 1 – Beta 2 UAC Consent Prompt

Figure 2 is an example of the Beta 2 UAC credential prompt.

Figure 2 – Beta 2 UAC Credential Prompt

Contextual UAC Elevation Prompts

The UAC elevation prompts now include contextual information about the programming requesting elevation, including the name of the program requesting elevation and the application’s publisher.

Application Aware Elevation Prompts

The UAC elevation prompts are also customized based on the type of executable that is requesting elevation. The following diagram (Figure 3) illustrates the different UAC prompts that are displayed based on the type and state of the requesting executable. This behavior is the default for Windows Vista and is not configurable, with one exception-- the ability to configure blocked applications with Group Policy and to block applications that are not signed and validated.

Figure 3 – Application Aware Elevation Prompts

The following details the elevation prompt color-coding:

• Red background and red shield icon: The application is from a blocked publisher or is blocked by Group Policy.
• Blue/green background: The application is a Windows Vista administrative application, such as a control panel.
• Gray background and gold shield icon: The application is Authenticode signed and trusted by the local computer.
• 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.

UAC elevation prompts on the secure desktop

Windows Vista displays UAC elevation prompts on the secure desktop by default in Beta 2. Jim Hong’s Secure Desktop blog posting details this Beta 2 feature.

Hello Shield Icon, Goodbye Lock

Because the shield icon has historically been used to represent security entry points in Windows, it is also now used in place of the Beta 1 “lock” icon to mark elevation entry points. Elevation entry points are places within the user interface (a button or link control) that require a user to access a full administrator access token to proceed.

Some control panels, such as the Date and Time Properties control panel, contain a mix of administrator and standard user operations. Standard users can view the clock and change the time zone, but a full administrator access token is required to change the local system time. Figure 4 is a screenshot of that control panel.

Figure 4 – Date and Time Properties control panel

The shield icon is also used in Beta 2 to mark elevation entry points on an executable’s icon. Figure 5 is an example of a shield icon overlay.

Figure 5 – Shield Icon Executable Overlay

This icon overlay marking is performed by Windows Vista by default. To see for yourself, drag an executable that requires an administrator access token onto your Beta 2 desktop. A shield icon will be placed over part of the executable’s icon.

That's all for now; I'll post about the updated Group Policy settings tomorrow.

JA Allen