UAC in MSI Notes: Do I need to consider "this" when I’m designing for UAC in MSI? Generally, no.


This is the twenty-first in a series of notes about UAC in MSI. Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team. The previous entries



  1. Introduce...

    1. ...the UAC in MSI Notes series
    2. ...my view of the root problem
    3. ...the conflicting per-user definition
    4. ...it'll be just like Managed Installs
    5. ...the jagged edge to user
    6. ...my relief providing framework

  2. Architecture Insights

    1. The "Saw Tooth" Diagram
    2. Credential Prompt and Permissions

  3. Common Package Mistakes

    1. The AdminUser Mistake
    2. Modify System with InstallUISequence Custom Action
    3. Modify System with InstallExecuteSequence Custom Action Outside of Script
    4. The NoImpersonate Bit Mistake

  4. More Architectural Insights

    1. My "Four Square" Diagram
    2. Challenges for a Beautiful Custom Action
    3. O Whitepaper, Where Art Thou?
    4. Read the Friendly Manual

  5. Conversations with Customers

    1. Should I write my installer as a Standard User install? If yes, how?
    2. When General Custom Action Mitigation Fails
    3. How do I get the shield on the advertised shortcut?
    4. How do I troubleshoot UAC in MSI via the log?  

This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs.  For this entry the topic is: Do I need to consider "this" when I'm designing for UAC in MSI?


Do I need to consider "this" when I'm designing for UAC in MSI?  Generally, no.


As folks load context from Microsoft's documentation there is a point of synthesis at which they start to ask how does this relate to that.  Ideally we could say that 'we've not written anything about this relating to that so one does not relate to the other'.  Unfortunately there's history where we've either documentation being wrong or incomplete OR we'd didn't put those two components together to see if they relate. 


I like talking to customers about boundaries and relationships because it means they've done their homework.  Those customers that are asking because they are experiancing behavior that they are trying to understand are even better.  Customers that are already committed are the ones that have most invested and I like helping investors.


What follows is a set of questions that I get about customers "this" list to which I respond generally no.


If I sign my Windows Installer packages, can I register the certificate so that no credentials are required ever (similar to the way Credential Free Patching works)?


(note: "this" == certificates as handle for authorization model)


No. This feature is under consideration for future versions of Windows.


Customers are also asking for this type of feature for the rest of the UAC credential prompt situations. Today there is a technology called SAFER that is designed to allow a corporate authority (IT department via active directory) to deny rights to run programs.


The pre-Vista logic underlying SAFER was everything gets to run unless it's denied. The mindset of Vista inverts this polarity, nothing gets to run unless it's allowed. If Vista's inversion of polarity sticks in the market, it begs the question of whether SAFER's polarity should be inverted.


Is MSIExec manifested to requireAdministrator?


(note: "this" == manifesting of dependent system binaries)


No. MSIExec.exe runs asInvoker when run as a client, as Local System when run as a service, and per custom action attributes when run as a custom action server. Generally, system binaries are under the protection of Windows Resource Protection so there would be nothing a customer could to do a the manifested system binary was "wrongly" manifested.


Do I get a prompt for each custom action that runs elevated?


(note: "this" == heuristics behind credential prompts)


No. There is a single elevation dialog for an entire install. After receiving correct credentials, the msiexec service manages the elevation context per the attributes of the custom actions. If a custom action is marked NoImpersonate, which custom action is run in the elevated sandbox.


We have heard sproratic cases of EXE custom actions triggering a credential prompt. If an EXE custom action is causing a credential prompt, there are two cases 1) the Installer Detection heuristic thinks the binary is a setup bootstrapper that needs to be elevated or 2) the binary was manifested to requireAdministrator. To prevent either case, explicitly manifest the binary asInvoker.


Given Windows Installer runs as Local System, can the Windows Installer now install files and registry keys that are protected by Windows Resource Protection (WRP)?


(note: "this" == capacity to update WRP)


No, the files and registry keys under the jurisdiction of Windows Resource Protection (WRP) are only modifiable by the Trusted Installer. The Trusted Installer is a new service for Windows Vista which does not talk to the Windows Installer. Trusted Installer updates are controlled entirely by Windows so an update to those resources must be done through the Windows servicing system.


Does the UAC Virtualization Technology affect the install behavior from Windows Installer?


(note: "this" == UAC Virtualization Technology)


No, the UAC virtualization technology works during the execution of the applications to mitigate some of the application compatibility problems Windows has seen with pre-Vista applications. Please see the User Account Control documentation for further information on how the virtualization technology affects running applications.


I’ve noticed some shortcuts on the start menu enable a context menu item for Run As Administrator. Can I do this with an advertised shortcut from the Windows Installer?


(note: "this" == UAC user experiance mitigation RunAs)


No. The work in the shell to support Run As Administrator for an advertised shortcut was not performed for the Windows Vista release.


With all the focus on security for Windows Vista, has the Windows Installer made any improvements to the LockPermissions table?


(note: "this" == capacity to write ACLs during install events)

No. Many tools vendors provide their own library that is richer than the existing LockPermissions standard table and LockPermissions standard action. We recommending considering those solutions.


Can I alter the appearance UAC credential prompt dialog either from the native Windows Installer UI tables or from an External UI Handler?


(note: "this" == creating fully custom experiance using External UI Handler)


No. The UAC credential dialogs are from a low level system service and can not be modified or superseded.


Are there regressions to the behaviors of Group Policy, SMS, or non-Microsoft deployment technologies after the Windows Installer changes for User Account Control under Windows Vista?


(note: "this" == corporate deployment technologies)


No. Corporate deployment technologies use a service running as Local System on each client thus will be unaffected.


  • Group Policy software distribution dependency on Windows Installer is unchanged for Windows Vista.
  • SMS client runs as Local System so the context it provides for Windows Installer is no different

 


Can Windows Installer figure out when to add the shield automatically to my authored UI?


(note: "this" == shield ui construct)


No. We do not have enough data about what follows a UI control to know for certain what the last UI control is before switching to the service where the elevation prompt will occur.

Comments (2)
  1. Windows Vista introduces a security concept called User Account Control (UAC) which has multiple impacts

Comments are closed.

Skip to main content