Windows 7 : Understanding the User Account Control - INTERACTING WITH THE UAC

Microsoft made a second fatal mistake with the UAC in Vista. Not only was the UAC obnoxious in presenting constant requests for privilege elevation, but Microsoft provided only one option for dealing with the UAC — turning it off. In fact, you'll find a number of sites that describe four methods for turning the UAC off, such as the one at http://www.petri.co.il/disable_uac_in_windows_vista.htm. Most users opted for the first method listed on this site because MSConfig is friendly and relatively easy to fix should the user make a bad choice. In addition, MSConfig is one of the utilities that many administrators let users work with.

Windows 7 takes a completely different approach to the UAC. When you open MSConfig now, you'll see a different option, as shown in Figure 1. Instead of simply disabling or enabling the UAC (it used to be called User Account Protection or UAP), the user sees an option to change the UAC settings.

Figure 1. MSConfig used to contain settings to turn the UAC off, but now it launches a more measured approach.

When the user highlights Change UAC Settings and clicks Launch, Windows presents the window shown in Figure 2. The user now has four options from which to choose. The default setting is less obnoxious than in Vista, but still presents the UAC dialog box when necessary. You can still choose the Vista level of UAC interaction. A third setting presents UAC warnings, but does so without using the secure desktop. Only if the user is completely averse to any UAC interaction at all is it necessary to turn the feature completely off, but you shouldn't ever exercise this option because the UAC does provide a valuable service.

Figure 2. Windows 7 makes it possible to ease UAC restrictions.

The administrator still has a higher level of access to UAC functionality than the user does, through the User Account Control settings found in the Security Settings\Local Policies\Security Options folder of the Local Security Policy console shown in Figure 3. For example, the administrator can insist that only applications that are both signed and validated are candidates for privilege elevation. This setting is so restricted that it would tend to shut down most systems today — few third-party vendors currently sign their applications.

Figure 3. The administrator has the ultimate level of control over UAC configuration.

Of course, the important issue is to figure out what all this means to you as a developer. You normally want to develop your applications to support a Vista level of UAC interaction, unless you're absolutely certain that users will have Windows 7 installed on their systems. Make sure that your application actually supports the UAC fully, because new applications and application updates will run on systems that have the UAC on them, and you can't count on the user's disabling the UAC (in fact, the user is well advised not to disable the UAC).

If your application will run on mission-critical systems that have extra security requirements, then you'll also want to be sure that your application is signed before you send it anywhere. It may be that administrators will require signed and validated applications in the future as threats to current systems become more intense and widespread. In short, making your application UAC-friendly is going to be a requirement, so it's best to start planning for the support now. Use these steps in preparing your application for use with Vista and Windows 7:

1. Test your application for Windows compatibility using the Microsoft Application Compatibility Toolkit (http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971).

2. Classify your application and individual application elements as standard user, administrator, or mixed usage so that you can better define the security requirements.

3. Redesign the application functionality to provide UAC compatibility by reducing rights or requesting privilege elevation as needed.

4. Redesign the application interface to provide UAC-friendly tips and techniques to the end user.

5. If at all possible, redesign the application installer so it doesn't require administrator-level privileges.

6. Create a manifest for your application so that the application runs as planned.

7. Embed the manifest with the application if you don't expect the administrator to modify it at any point. External manifests can get lost or modified by the end user, resulting in undesirable side effects.

8. Test your application using precisely the same credentials and resource access as the end user. Otherwise, you can't be sure the application will work at all.

9. Authenticode signs your application so that it's easy to detect any modifications to it.

10. Get your application tested by Microsoft so it appears on the Windows 7 Compatibility Center (http://www.microsoft.com/windows/compatibility/windows-7/default.aspx).