locked
Running application as an administrator when user is administrator RRS feed

  • Question

  • Hello,

    I want that my application will run as administrator if user is of admin group otherwise it will run normally. I means to say in windows vista or 7 by default admin doesent have administrator rights until he run application as administrator. I want that if user is administrator but not have admin rights then UAC prompt open and ask for run as administrator and if user is normal user like limited user then it will executed normally.

    I hope u understand what I want to implement.
    Please help me it urgent.

    I am using Windows7 32 bit and .netframework 3.5 and c# as language.
    Thursday, June 16, 2011 8:12 PM

Answers

  • Hi,

    I strongly recommend you review Designing UAC Applications for Windows Vista (also for Windows 7). This article will provide you with all the details of correctly implementing a UAC enabled application.

    You need to create and embed an Application Manifest file to work with UAC. If you set the requestedExecutionLevel to highestAvailable, then your application will prompt for elevation if the user is an administrator and UAC is enabled. The previous link explains the other two options: asInvoker and requireAdministrator. In a nutshell, asInvoker will never attempt to elevate and requireAdministrator means the application will not run w/o administrator credentials.

    Here is a sample of the section you'll need to change if you add a new Application Manifest File to your project:

     <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
       <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <!-- UAC Manifest Options
          If you want to change the Windows User Account Control level replace the 
          requestedExecutionLevel node with one of the following.
    
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
        <requestedExecutionLevel level="highestAvailable" uiAccess="false" />
    
          Specifying requestedExecutionLevel node will disable file and registry virtualization.
          If you want to utilize File and Registry Virtualization for backward 
          compatibility then delete the requestedExecutionLevel node.
        -->
        <requestedExecutionLevel level="highestAvailable" uiAccess="false" />
       </requestedPrivileges>
      </security>
     </trustInfo>
    

     

    This sample will prompt for elevation if your user is an Administrator and starts your application, since the requestedExecutionLevel is "highestAvailable".


    The easiest way to get this file into your project in Visual studio, is to open the "Add New Item" dialog and choose the "General" template where you should choose the "Application Manifest File" item. This will also set your project's properties (in the application tab) to your newly added manifest file, which should be named app.manifest by default.

    HTH

     


    -Scosby
    Microsoft Community Contributor
    Friday, June 17, 2011 1:36 AM

All replies

  • I don't have an answer for the best way to handle this. I'm not sure if it's possible using only one application, but before we even go down that route, I have to ask...

    Why?

    If your application needs admin access, then it should just always elevate, and normal users should not be able to run it.

    If it does not require admin access for something specific, then it should just run under limited rights all the time and never elevate.

    If it can run under limited access for most operations but needs admin access for a few specific operations, the operations which require administrative rights should be put in a separate process. Your main application should run with normal rights, then (when you need to do something which requires admin rights) you should launch your secondary process as an administrator. You can accomplish this using the ProcessStartInfo class:

    ProcessStartInfo info = new ProcessStartInfo("myAdminApp.exe");
    info.UseShellExecute = true;
    info.Verb = "runas";
    
    Process.Start(info);
    


    Thursday, June 16, 2011 8:45 PM
  • UAC does not work like that.  You can disable UAC.  This will disable the run as administrator prompt and everything will run with the respective rights of the logged in user.  But, there is no way to change the functionality to work in the way you suggest.
    BrianMackey.NET
    Thursday, June 16, 2011 9:00 PM
  • There are ways, just none that are very good. The easiest is to create a proxy application. When the user runs your application, you can try to guess (more or less) whether they are actually administrators or not (see here). Then you either launch your main application normally or as an administrator.

    Microsoft purposefully made this very difficult to get right, though. These approaches are always buggy. I'd highly recommend going with one of the 3 approaches above - those are the 3 ways Microsoft recommends handling it.

    Thursday, June 16, 2011 9:12 PM
  • Hi,

    I strongly recommend you review Designing UAC Applications for Windows Vista (also for Windows 7). This article will provide you with all the details of correctly implementing a UAC enabled application.

    You need to create and embed an Application Manifest file to work with UAC. If you set the requestedExecutionLevel to highestAvailable, then your application will prompt for elevation if the user is an administrator and UAC is enabled. The previous link explains the other two options: asInvoker and requireAdministrator. In a nutshell, asInvoker will never attempt to elevate and requireAdministrator means the application will not run w/o administrator credentials.

    Here is a sample of the section you'll need to change if you add a new Application Manifest File to your project:

     <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
       <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <!-- UAC Manifest Options
          If you want to change the Windows User Account Control level replace the 
          requestedExecutionLevel node with one of the following.
    
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
        <requestedExecutionLevel level="highestAvailable" uiAccess="false" />
    
          Specifying requestedExecutionLevel node will disable file and registry virtualization.
          If you want to utilize File and Registry Virtualization for backward 
          compatibility then delete the requestedExecutionLevel node.
        -->
        <requestedExecutionLevel level="highestAvailable" uiAccess="false" />
       </requestedPrivileges>
      </security>
     </trustInfo>
    

     

    This sample will prompt for elevation if your user is an Administrator and starts your application, since the requestedExecutionLevel is "highestAvailable".


    The easiest way to get this file into your project in Visual studio, is to open the "Add New Item" dialog and choose the "General" template where you should choose the "Application Manifest File" item. This will also set your project's properties (in the application tab) to your newly added manifest file, which should be named app.manifest by default.

    HTH

     


    -Scosby
    Microsoft Community Contributor
    Friday, June 17, 2011 1:36 AM
  • Thanks. This will work for me.
    Friday, June 17, 2011 5:00 AM
  • Maybe this site has small bugs.

    Please Inform developers of this site.

    Bug Details is as following.

    "When We click on reply link then editor is open and without replying when we click on mark as answer or unmark as answer then wditor is closed. And finally when we click on Reply then a message display like Reply is already open first close it while no reply box is open." I had tested it on Mozilla Firefox 4.0. Maybe it is bug am not sure. Please test it and inform developer of this site.

    Thanks

     

    Friday, June 17, 2011 5:04 AM
  • Keep in mind that the answer marked will always try to elevate - whether the current user is an administrator or not. If your current user is not an administrator, your application will not run. That's not what you described in your original post - is that an acceptable tradeoff?
    Friday, June 17, 2011 1:05 PM
  • Keep in mind that the answer marked will always try to elevate - whether the current user is an administrator or not. If your current user is not an administrator, your application will not run. That's not what you described in your original post - is that an acceptable tradeoff?


    Tim,

    You are incorrect saying it will always require elevatation & will not run for a standard user, that is not true. Additionally, I believe you are misunderstanding the OP scenario. Please provide a reference to the documentation that states the behavior you're claiming when using "highestAvailable". I am unable to reproduce that behavior, as one would expect, because it is not how UAC works with an Application Manifest File.

    The documentation I listed previously for creating and embedding an Application Manifest clearly explains all possible combinations of settings in 3 nice tables in the Application Manifest Marking and Application Launch Behavior section, but allow me to summarize: 

    If UAC is enabled and the requestedExecutionLevel is "highestAvailable" the application will run in a standard user process. The only time the application will require elevation is with "requireAdministrator". Finally, the "asInvoker" setting will never elevate, regardless of the user's membership (even for an Administrator).

    A test application is very insightful when trying to understand how UAC impacts the user experience.

    HTH


    -Scosby
    Microsoft Community Contributor
    Friday, June 17, 2011 1:56 PM
  • Maybe this site has small bugs.

    Please Inform developers of this site.

    Bug Details is as following.

    "When We click on reply link then editor is open and without replying when we click on mark as answer or unmark as answer then wditor is closed. And finally when we click on Reply then a message display like Reply is already open first close it while no reply box is open." I had tested it on Mozilla Firefox 4.0. Maybe it is bug am not sure. Please test it and inform developer of this site.

    Thanks

     


    Hi,

    You should report bugs in the Forums Issues forum. That is the official thread for forum bugs.

    HTH


    -Scosby
    Microsoft Community Contributor
    Friday, June 17, 2011 1:58 PM
  • Keep in mind that the answer marked will always try to elevate - whether the current user is an administrator or not. If your current user is not an administrator, your application will not run. That's not what you described in your original post - is that an acceptable tradeoff?


    Tim,

    You are incorrect saying it will always require elevatation & will not run for a standard user, that is not true. Additionally, I believe you are misunderstanding the OP scenario. Please provide a reference to the documentation that states the behavior you're claiming when using "highestAvailable". I am unable to reproduce that behavior, as one would expect, because it is not how UAC works with an Application Manifest File.

    The documentation I listed previously for creating and embedding an Application Manifest clearly explains all possible combinations of settings in 3 nice tables in the Application Manifest Marking and Application Launch Behavior section, but allow me to summarize: 

    If UAC is enabled and the requestedExecutionLevel is "highestAvailable" the application will run in a standard user process. The only time the application will require elevation is with "requireAdministrator". Finally, the "asInvoker" setting will never elevate, regardless of the user's membership (even for an Administrator).

    A test application is very insightful when trying to understand how UAC impacts the user experience.

    HTH


    -Scosby
    Microsoft Community Contributor

    I apologize for my misunderstanding of the "highestAvailable" option. I should have read up on it before commenting - I got it confused with "requireAdministrator".

    However, I will point out - from the same link you provided - that this option is not recommended by Microsoft. In that page they suggest that this option should be used if you plan to refactor your application later. 

    There is an added issue which needs to be addressed, and that is the fact that the application itself will have to detect and act differently depending on whether it is running in an elevated context or not. While I was incorrect in saying that the application would not launch, it is still correct (and very likely) that the application will fail later if you attempt to perform some action which the user account does not have rights to perform.

    Again, I apologize for the misinformation, my previous post was incorrect. However, that doesn't change that I (and Microsoft, from their documentation) strongly recommend against taking this approach. The better option is to redesign your application to elevate correctly as needed.


    Friday, June 17, 2011 2:25 PM