UACBlog https://docs.microsoft.com/archive/blogs/uac/feed.xml The User Account Control WebLog. Wed, 17 Apr 2019 03:27:23 GMT en-US hourly 1 Windows Vista RTM, Closure of Blog, Free SWAG! https://docs.microsoft.com/archive/blogs/uac/windows-vista-rtm-closure-of-blog-free-swag Wed, 08 Nov 2006 06:22:00 GMT https://blogs.msdn.microsoft.com/uac/2006/11/08/windows-vista-rtm-closure-of-blog-free-swag/ Thanks to everyone who wrote in. The 100 stickers are now all taken for. If you replied before 6:00 PM PST on Wednesday, November 10th with your mailing address you should receive one. Thanks again for reading everyone.

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.

Now that Windows Vista will be here soon for everyone, it’s time to make sure your applications and environments are ready for Windows Vista and User Account Control:

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 https://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

]]> Credential Prompt Change in RC2 https://docs.microsoft.com/archive/blogs/uac/credential-prompt-change-in-rc2 Thu, 12 Oct 2006 10:24:00 GMT https://blogs.msdn.microsoft.com/uac/2006/10/12/credential-prompt-change-in-rc2/ 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.

RC1 behavior

RC2 behavior

Is this a bug?

No, this is intentional. By default, when UAC prompts users for credentials, it should display the empty Password Provider tile. If you are able to validate your identity with additional (installed) credential providers, such as the Smart Card Provider, you will probably see additional tiles in the user list.

Is it possible to get the old default behavior back?

Yes, it is. The behavior is controlled by a Group Policy setting and can be configured using gpedit.msc. Once in the MMC snap-in, use the tree control to navigate to...

Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Credential User Interface -> Enumerate administrator accounts on elevation

Enable this Group Policy setting.

Why did the UAC team make this change?

During enumeration of local machine administrators, the system must contact a domain controller (DC). While this enumeration occurred, an indeterminate progress bar appeared within the user list region. We received a large amount of feedback regarding the long period of time this progress bar took to disappear. We analyzed the problem in detail and found users experiencing unusually slow performance when the DC was unavailable or slow to respond. In order to place the dialog box in front of users as fast as possible, we changed the default behavior. Speed.

How do I change the domain field?

By default, the Password Provider will pre-append the domain (or machine name in the workgroup case) to serialized credentials. The uneditable string below the password field indicates the domain (or machine name) that will be used. To specify a different domain, it must be entered in the user name field. The correct format is domain\username or username@domain. The domain field will update automatically. This is the same convention used during logon.

How does this Group Policy setting function on workgroup machines?

Enumerate administrator accounts on elevation has a slightly different meaning on workgroup machines. By default (that is, the setting has been neither enabled nor disabled), the Password Provider will list all local administrators on the machine. When enabled or disabled, this policy behaves exactly the same as in the domain-joined scenario.

How does this Group Policy setting affect other credential providers?

The Microsoft Smart Card Provider is not affected at all by this change. We recommended credential providers written by ISVs respect the settings in Group Policy.

-- Daniel Oliver

Windows Shell Team

]]> Windows Vista Application Development Requirements for UAC Compatibility https://docs.microsoft.com/archive/blogs/uac/windows-vista-application-development-requirements-for-uac-compatibility Wed, 20 Sep 2006 13:25:00 GMT https://blogs.msdn.microsoft.com/uac/2006/09/20/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: https://www.microsoft.com/downloads/details.aspx?FamilyID=ba73b169-a648-49af-bc5e-a2eebb74c16b&DisplayLang=en.

-Jenn Allen

]]> ActiveX Installer Service Discussion and Video https://docs.microsoft.com/archive/blogs/uac/activex-installer-service-discussion-and-video Wed, 13 Sep 2006 12:10:00 GMT https://blogs.msdn.microsoft.com/uac/2006/09/13/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 (https://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 https://docs.microsoft.com/archive/blogs/uac/uac-improvements-in-release-candidate-1-rc1-and-video Thu, 07 Sep 2006 10:26:00 GMT https://blogs.msdn.microsoft.com/uac/2006/09/07/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:

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

  • 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

]]> UAC Improvements in Release Candidate 1 (RC1) and Video https://docs.microsoft.com/archive/blogs/uac/uac-improvements-in-release-candidate-1-rc1-and-video-2 Tue, 05 Sep 2006 07:00:00 GMT https://blogs.msdn.microsoft.com/uac/2006/09/05/uac-improvements-in-release-candidate-1-rc1-and-video-2/ 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:

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

  • 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 https://docs.microsoft.com/archive/blogs/uac/built-in-administrator-account-disabled Sun, 27 Aug 2006 23:19:00 GMT https://blogs.msdn.microsoft.com/uac/2006/08/27/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 https://blogs.msdn.com/windowsvistasecurity.

]]> Elevations Are Now Blocked in the User's Logon Path https://docs.microsoft.com/archive/blogs/uac/elevations-are-now-blocked-in-the-users-logon-path Wed, 23 Aug 2006 16:16:00 GMT https://blogs.msdn.microsoft.com/uac/2006/08/23/elevations-are-now-blocked-in-the-users-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 https://docs.microsoft.com/archive/blogs/uac/user-account-control-virtual-lab Mon, 14 Aug 2006 18:27:00 GMT https://blogs.msdn.microsoft.com/uac/2006/08/14/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.

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

- Alex Heaton

]]> Flash Swag: Windows Vista Build 5472 DVD https://docs.microsoft.com/archive/blogs/uac/flash-swag-windows-vista-build-5472-dvd Tue, 08 Aug 2006 12:00:00 GMT https://blogs.msdn.microsoft.com/uac/2006/08/08/flash-swag-windows-vista-build-5472-dvd/ We have reached our limit. All the DVDs are gone. If you replied before 8:00 AM PST on Thursday, August 10th with your mailing address you should receive one. (Please do not send mail to the blog owner requesting a DVD, there are no more to give out.) We hope to do more giveaways in the future so stay tuned.

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

]]>