UAC in MSI Notes: Credential Prompt and Permissions
This is the eighth 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
- Introduce...
- Architecture Insights
This entry will talk about when the credential prompt occurs and how the permissions change for in the Windows Installer support for User Account Control using the earlier "Saw Tooth" diagram.
When is the Credential Prompt Triggered?
The first question architecture detail that trips up just about everyone is where the credential prompt occurs with the User Account Control support in Windows Installer. Below I've augmented the Saw Tooth diagram with a red circle to show where the elevation prompt occurs.
Remembering the earlier discussion, this location in the workflow is the beginning of the processing of the package inside the Windows Installer service.
Justification for this Location
The first justification for having the credential prompt happen here is that the maximum protection can be provided on the call between the Windows Installer service and the Vista service that will drive the credential experience. Due to the security specific behavior of this call, a high degree of trust needed to be established between the Windows Installer team and the User Account Control team. The pivot here was that "it's just like a Managed install under Group Policy". If you were one of the generations of corporate customers that field tested the behavior at this point in the service via Group Policy deployment, thank you.
The second justification for having the credential prompt happen here is that it is where we sort out elevation and impersonation context today. Impersonation is how Windows Installer is to figure out how to write to the right user specific locations even though the Windows Installer service runs as Local System. The pivot here as well was that "it's just like a Managed install".
The third justification for having the credential prompt here is that it reinforces the incentives design manageable software installation packages. One of the complaints we hear a lot from corporate customers is that it is not very often that package are designed for corporate deployment by management software. By choosing this location, those few package vendors that have invested in supporting deployment by management will get a leg up on the differentiated Vista experience without the additional work the majority software vendors that had not designed for corporate deployment.
The last justification is that this is the most logical location given the UAC UX and security guidelines. The first of those guidelines is that one should provide the "Shield" only when one needed to. Given the design of the Windows Installer is that the client (the Violet region) should not modify the box, none of the activities in the client required elevation. The second of those guidelines was that you should ask for privilege as late as possible to conform to the Principle of Least Privilege. Placing the credential prompt here conforms to that principle.
How do permissions change under UAC?
For packages providers that haven't been particularly diligent about doing the correct changes in the correct part of the workflow, the fact that UAC now enforces the conventions Windows Installer has had since it's origins is the most stunning to them. The dynamics of authoring and authoring tools is that they want to make it as easy as possible with entirely understanding the technology upon which you are working. Prior to UAC there was no enforcement so those blissfully in the dark and working outside the lines had no hint they were in violation (unless you were designing for deployment by manageability tools in which case you'd known of and solved for this problem).
Returning to the three regions of the drawing, generally
- the Violet region runs as Standard User
- the Orange region runs as Standard User
- the Teal region
- Standard Actions run as with the needed permissions
- Custom Actions run as Standard User unless the NoImpersonate bit is flipped.
The key here is that the intent of the Windows Installer architecture has been this all along. Up to Vista, the only instance this was enforced was under corporate lockdown scenarios. With UAC in Vista, enforcement of this scenario is now in the base experience from the platform.