Today we are proud to announce the RTM of Windows Vista! Releasing Windows Vista and User Account Control has been an incredible adventure, and we would like to thank all of our beta testers (and critics) who have given us invaluable feedback that drove many of the changes made since the early beta versions.

• For IT professionals: Test Windows Vista as a standard user in your environment. The key UAC IT resource is Understanding and Configuring User Account Control in Windows Vista. We’ve also created the Microsoft Solution Accelerator for Business Desktop Deployment 2007 to help you plan and manage your deployment.

• For developers: Test your application as a standard user on Windows Vista. The key UAC developer resource is Windows Vista Application Development Requirements for User Account Control Compatibility. Also, download Microsoft Standard User Analyzer. And get your applications certified for Windows Vista.

Today we are also announcing the closure of the UAC blog. We will still continue to blog about UAC—hopefully more than ever now that we should have more time—but going forward, we will post UAC info on the general Windows Vista Security blog at http://blogs.msdn.com/windowsvistasecurity, so please update your bookmarks and RSS feeds.

Back in January, we said we would give away free SWAG if we went for one month without posting a new message. Well, we are RTM, but we still wanted to give out some SWAG to our faithful readers, so here it is. The first 100 readers who send mail to uacswag at microsoft dot com with your physical mailing address will get one of these Windows Vista “I’m a Standard User” stickers. We hope it will help you spread the work of this important step everyone should take to improve the security of their PCs.

Thanks again for all of your feedback and ideas.

--The User Account Control Team

Hi, everyone. I'm Daniel Oliver, a program manager on the Windows Shell Team.

If you're running Windows Vista on a domain-joined machine, you may have noticed a small change between Windows Vista RC1 and RC2 when the UAC dialog box prompts for credentials in an OTS (over the shoulder) scenario. In RC2, only the empty Password Provider tile is enumerated by default. Some users thought this was a bug, and other users requested we revert to the previous behavior. In addition, many users wanted to know why we made this change. Please allow me to address these questions individually.

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

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

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

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.

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

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

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.

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

 

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

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

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