Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Does Windows have a "automatically deny elevation request" list?

If a user is a "standard user", it is possible to have Windows automatically deny any elevation requests by changing the ConsentPromptBehaviorUser group policy setting to Automatically deny elevation requests:

  • Prompt for credentials on the secure desktop. (Default) When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege
  • Prompt for credentials When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege
  • Automatically deny elevation requests When an operation requires elevation of privilege, a configurable access denied error message is displayed. An enterprise that is running desktops as standard user may choose this setting to reduce help desk calls

This is useful in a situation where a program might prompt to elevate, but that would require the guy from helpdesk to run three buildings over (to enter their over the shoulder credentials). Only once they get there, they discover that the user shouldn't run that program.

We want the application to run as a standard user (possibly getting access denied errors), since that's the correct answer.

But that setting applies to all programs that elevate. Is it possible to

  • mark a program, or
  • add it to a list

so that it is automatically denied elevation requests, and runs as a standard user?

The problem happens when a program has been mistakenly:

  • marked as requestedExecutionLevel of requireAdministrator in it's embedded or external manifest
  • has had the "Run this program has an administrator" compatibility option checked
  • is being detected as a setup program (e.g. in named install or setup) through the EnableInstallerDetection heuristics

Note: Assuming the application had no manifest, one might suggest adding a manifest indicating requestedExecutionLevel: asInvoker. This solution would also disable file and registry virtualization for the application.

See also

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

A possible solution is to use two policies in concert:

  1. Configure the already mentioned ConsentPromptBehaviorUser group policy setting to Automatically deny elevation requests. As stated in the question, this will affect all programs that run.

  2. Next ENABLE the User Account Control: Only elevate executables that are signed and validated policy setting. (From Microsoft) This setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers.

  3. Sign any trusted programs with your organization's key and publish it to the Trusted Publishers certificate store on all computers in your organization. More info.

share|improve this answer
    
Accepted because there's almost certainly no answer; and these workarounds would be the best one can get. –  Ian Boyd Mar 10 '12 at 15:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.