Testing with UAC - Overview

  • Article

Hi, I am Wei Wang, a Lead Software Design Engineer in Test on the User Account Control (UAC) team within the Windows Security organization. As many of you experienced, User Account Control in Windows Vista fundamentally changes the way users interact with Windows, therefore , it has a great impact on how testing is performed on the Windows platform and the numerous supported applications. The Windows test organization went through a great deal of work to augment its test infrastructure to be UAC compliant. Many test teams spent a significant amount of time to redesign how their tests are structured in order to fully exercise their components in a UAC environment.

There are three major buckets of change with respect to the differences between XP and Win2K3 to Vista.

1) Moving away from testing as the built-in administrator account

2) Test executable separation (test setup/clean-up vs. runtime test cases)

3) Testing as user of different user groups (Users, Administrators, Network Operator, etc...)

Historically the majority of testing was performed as the built-in administrator account because it was a lot easier to test when you are running with full administrator privilege. Because most users run as a member of the local administrators group, it is effectively the same whether you test as the built-in administrator or a member of administrators group. However, in Windows Vista with UAC enabled (as it is by default), this is no longer true since all users run with standard user rights by default even when being a member of the local administrators group. Therefore, with this change, testing as the built-in administrator is not the same as testing as a member of the local administrators group. This is a dramatic change from both the user and test perspective. Instead, all tests should be executed under the default standard user account or in some cases as a user who is a member of local administrators group --user in Admin Approval Mode.

Throughout our internal and external test evangelism effort, we (the UAC team) encountered many cases where setup and clean - up code, which often perform administrative tasks , are compiled into the same executable with the code that exercises all the end user test cases. With the changes in UAC, a single test binary composed of setup/cleanup and runtime functionality no longer work --the setup and clean-up code will by default fail to run due to the lack of administrative rights. There are two workarounds to this issue. The first one is to move the setup and clean-up code into a separate executable and to mark this executable with a manifest defining a run level equal to “requiredAdministrator”. Please refer to the UAC developer whitepaper on how to mark applications with the applicable run level. This solution will closely match the end user experience. However, if for some reason, separating your test into separate binaries is not an acceptable solution; the second workaround is to mark the test executable as “requiredAdministrator” and run the setup and clean - up code with full administrator rights and to impersonate down to a standard user access token during the rest of the test case execution. The problem with this testing method is that your impersonating token will not be identical to the filtered token on the system; therefore you can potentially hit issues when running as standard user without impersonation. Additionally the impersonated token will not have the virtualized bit set, and thus registry and file virtualizations will not occur.

Another major test change is really not caused by UAC, but manifests with UAC. Some test teams continue to test as administrator as they did in the past. The standard user account is either not tested, or only tested in a few test scenarios. Historically this was understandable as most customers ran as administrators on XP and Win2K3. However, this is no longer the case as all users, irrespective of privilege, will logon as a standard user. It is essential to verify your APIs, components, and applications interact correctly and reasonably as standard user. The basic rule is to review your scenarios, define the standard user and administrative behavior both positive and negative, then exercise each scenario under both user accounts and verify the outcome. Following this simple methodology will give you complete functional test coverage. Additionally you can reference the UAC Shell Guidance <coming in Beta2> for our recommended best practices for UI components to verify if your user experiences are consistent with our designs.

User Account Control fundamentally changes how testing is performed. We understand that this is a significant shift in how we’ve tested in the past, but UAC is an important effort to reduce the default attack surface of the Windows operating system. We hope you will see the benefit of UAC and therefore invest in changing your test infrastructure to be UAC compliant. This is only an overview of UAC’s impact on testing and we will follow up with a series of more in-depth articles on tools, test design, implementation tips, and additional guidelines to facilitate testing with UAC.

Comments

  • Anonymous
    March 03, 2006
    Wei,

    Nice article.  

    Small typo - I believe "requiredAdministrator" should read "requireAdministrator".

    Marcus

  • Anonymous
    March 22, 2006
    兄弟是叫王伟(音译)吧?看名字好像是华人.
    i think you r chinese:-)
  • Anonymous
    March 23, 2006
    The comment has been removed
  • Anonymous
    March 25, 2006
    Hi Peter. Thanks for your question, I will track down an expert on the Program Compatibility Assistant to reply as soon as possible.

    - Alex
  • Anonymous
    March 29, 2006
    Hi Peter, please see the response posted about the Program Compatibility Assistant on the other UAC thread at http://blogs.msdn.com/uac/archive/2006/02/22/537129.aspx

    thanks,
    Sathish (Microsot)
  • Anonymous
    April 05, 2006
    What about standard users not being able to write to files created by admins, even if the location is defined as common machine data, for all users, like the ProgramData folder ?

    Is there any way around that ?
    What is the reasoning behind, this location is recommended in various articles as the place to store all users data ???

    Thanks!
  • Anonymous
    May 03, 2006
    Is there any reason that 'Alexandra's comment has not been answered?  I've noticed that polite questions on this blog tend not to get no response -- shall I reword the question to be rude, just so we get an answer?
  • Anonymous
    May 18, 2006
    What -- are the questions here too hard to answer?  Perhaps you have a future flipping burgers -- that might be easy enough for you.
  • Anonymous
    May 19, 2006
    Alexandra - actually, this has been the case for a long time.  In Windows XP, when a user (any user) creates a file in the shared locations, that user becomes the owner of the file and retains full control.  Other non-admin users have read-only access to those files.  Admins, of course, can do whatever they want on the machine.
  • Anonymous
    May 31, 2006
    The comment has been removed
  • Anonymous
    June 20, 2006
    The comment has been removed