"Run as" with Vista RRS feed

  • Question

  • Hi
    Perhaps an easy question, but I haven't found an answer to it myself.
    In Windows XP I could hold down SHIFT and right-click an exe-file and choose "Run as" to run the executable as another user, a domain admin for instance. But I can't find this useful feature i Windows Vista, all I can do is to run an executable as a local administrator with the "Run as administrator". But that doesn't help if I need admin-access to other servers.

    How can I do this in Windows Vista?
    Thursday, May 31, 2007 6:38 AM


  • Elevation to Run your application as administrator only is more safe for you as most scenarios of worm, viruses, trojans and spyware to run the application as user (not administrator) as Run As Administrator needs high elevation and it's with strong encryption algorightm and hard to decode it.


    Good luck

    Sunday, June 3, 2007 7:46 PM

All replies

  • The runas.exe command line program is still available.


    Also, if you use "run as administrator" but are not an administrator with a standard user token, don't you get prompted for both a username and credentials?



    Friday, June 1, 2007 5:40 PM
  • Elevation to Run your application as administrator only is more safe for you as most scenarios of worm, viruses, trojans and spyware to run the application as user (not administrator) as Run As Administrator needs high elevation and it's with strong encryption algorightm and hard to decode it.


    Good luck

    Sunday, June 3, 2007 7:46 PM
  •  ahmhdy wrote:

    Elevation to Run your application as administrator only is more safe for you as most scenarios of worm, viruses, trojans and spyware to run the application as user (not administrator) as Run As Administrator needs high elevation and it's with strong encryption algorightm and hard to decode it.


    Good luck


    That does not answer the question and also is not a coherent sentance.  I log into my computer with a standard user account.  I then run admin applications with a seperate admin account using the Run As command. (Such as Active Directory, DHCP, DNS, SMS, Exchange) To me an Administrator should never log into their workstation with an account that has elevated priveleges.  In Vista the default value (Only Value) is to run the app as the local admin.  I have not found any way around this and it prevents me from running Vista.  I have asked numerous people how this can be fixed and no one has an answer.  Not once in my 10+ years in IT with MS Products have I ever wanted to run a program as the Local Administrator!  This may be fine for Home users in a Workgroup but should be disabled when part of an AD Domain.


    Vista will not be installed at my company (~250 nodes) until this question is answered.  It prevents my admins from being able to do their jobs according to our security policies.  I have searched and have yet to find an answer.


    To me Vista should work with Run As just as every OS before did.  Shift+Right Click = Run As Alternate User OF YOUR CHOICE!!!!!!! not Run As Local Admin.

    Monday, December 17, 2007 9:48 PM

    "Run as administrator" does not work as you describe in my experience. If you are an administrative user, you can log in to the workstation without worry - because you only get a standard user token for your shell. When you want to run n program that requires administrative rights, you right click and select "Run as administrator". You are then prompted to provide your consent to running that program with an elevated token. Read more about User Account Control to better understand this feature.


    Now, if you want to maintain this two-account setup you have, that should still work. A "standard user" does not get the same consent prompt when requesting token elevation. Instead, this user must provide a username and password at the Credential Provider prompt displayed by CredUI.


    At no time is the local "Administrator" account involved. It is disabled on the local machine by default. The domain administrator can log in to a Vista workstation - and then doesn't get bothered by UAC at all. That's by design. You wouldn't want to do that.

    Monday, December 17, 2007 9:59 PM

    Again, I am not certain that you understand the issue.  The problem does not relate to running programs on the local machine with elevated priveleges (Member of Local Admin Group).  It involves running programs on the local machine that need elevated network priveleges (Domain Administators Group).


    Example.  I am logged into my worksation with my standard user account.  It has no domain priveleges other than a standard user.  I want to connect to my DHCP server to create a Static Entry.  How the heck I am suppose to do that with Vista?


    1. RDP to the DHCP server and login with Admin --- NO!

    2. Make my standard user have rights to DHCP -- NO!

    3. Use an alternate account to Launch DHCP with Run As that has admin rights YES!!!!!!


    How do you propose I do this with the UAC?  It will not allow me to use Run As with any other account than Local Admin!  That does absolutely no good in an AD Domain Environment!


    If there is some other way to run a program as an alternate Domain user, please tell me.  I have searched and all I find are articles on how the "Run As" allows you to use elivated priveleges in Vista so you can log in as a normal user.



    Below, this is what I need to do.  How and the Hell is this accomplished in Vista.  How do you use the "Run As" to authenticate as an administrative Domain Account?  IT WILL NOT LET YOU!!!!


    Example:  domain\myuser.admin

    Not: localmachine\Administrator (Default and ONLY OPTION)


    "Administrative Tasks on Remote Computers

    A user that is a member of the domain administrators group, or another similarly privileged network group, should only use that administrator enabled account when the user is performing administrative tasks. The following scenario highlights this in more depth:

    Carol Philips, a help desk technician at Litware, Inc, has two domain user accounts: a domain administrator account and a standard domain user account. The domain administrator account is a member of her workstation’s local administrators group. Carol has been told by her supervisors to only use her domain administrator account when she is performing tasks that require a full administrator access token. As a result, Carol logs on to her workstation with her and either uses Run as or Terminal Services when she needs to perform administrative tasks. One day, Carol notes that her computer’s hard disk has not been backed up for some time. She uses Run as to open a command prompt, enters the credentials for her administrator account, types secedit at the command prompt, and presses Enter. At the same time, she is also browsing the Web as a standard user and accidentally downloads malware from the Web. However, the malware is unable to affect other computers on the network since Carol was browsing the Internet with a standard user account."





    Monday, December 17, 2007 11:00 PM
  • I think I understand your question better. In my limited testing, runas.exe from the command prompt still works the same way. It can run a program as any user. Unfortunately, I don't have access to a domain connected Vista system right now. But on my system, I was able to execute "runas.exe /user:test cmd.exe" which launched a cmd prompt as user test. From that command prompt, I ran an MMC snap-in, but it wasn't elevated with an administrative token nor did it prompt to do that - which I thought was weird.


    But I don't know whether the DHCP tool or any other needs the user rights associated with an elevated admin token on the client machine or if it is simply a matter of user identity triggering the right access control rules on the DHCP server. You've hit the limit of my knowledge around Windows security tokens.


    But I don't see why you can't use "runas /user:username@domain programname" to at least launch a program as the domain admin, even without elevation.

    Tuesday, December 18, 2007 1:54 PM

    Well, I either am a complete Jack Arse or something has changed in a later release.


    I loaded up a new copy of Vista Business in a VM and this functionality is there!  I doublechecked with my Admin to see if I was crazy and he clearly remembers not being able to ru n a program as an alternate user.  The last time I installed Vista was about 6 months or more ago.  Has then been an updated release of Vista on Volume Licensing?  I was not running a Beta.


    When I had the problem before it was a straight install not in VM on an HP workstation.  Joined a W2K3 Domain and was logged in as a Non admin user.  I could not run a program as an alternate user.


    Now it is working.  I am miffed and happy at the same time.  Now I can continue to test Vista.

    Tuesday, December 18, 2007 4:50 PM

    Ok, I have done some more testing and found out what is happening.


    If you are logged into Vista as a Domain User but not as a Local Admin the Run As option is available to run with alternate credentials.


    If you are logged into Vista as a Domain User that has Local Admin Credentials the Run As option will be displayed but not prompt you for alternate credentials.  Instead since you are already a local admin it will execute the program with your local admin priveleges.  To me that is a Huge Problem.


    That prevents a user that has Local Admin permissions from running a program that requires Domain Admin privileges unless they remove themselves from the local admin group or grant their normal domain user account Domain Admin privileges.


    Example.  I need to ruan AD Users and Computers to create a computer account.  I am a local admin on my computer logged in my domain account that is only a member of Authenticated Users.  That account has no permissions to run ADUC.  In XP I would execute MMC as my admin account that has Domain Admin Privileges.  Add ADUC to the MMC and connect to my DC's.  Performing that same function in Vista Is NOT POSSIBLE.  Because since I am logged in as a Local admin that is the ONLY context Vista will let the MMC run.


    I have verified this by removing myself from the local admin group.  Executed the Run As Command, provided my admin account credentials then opened Task Mangler to see what account is running that process.  It is the admin account I used to start the program.


    I added myself to the local admin group.  Executed the Run As command on the same executeable.  This time there is no prompt for alternate credentials.  The program opens and after checking Task Mangler it is running as my currently logged in user account.  The one that is a member of Local Admins but not Domain admins.


    Does nobody else find this to be a huge problem?


    As I believe I stated earlier I do not allow myself or my staff to authenticate to their workstation with an admin account.  They all have alternate user accounts that have admin privileges used to execute MMC and other applications required to connect to domain level resources.  I have also encountered issues with Vista requiring an Admin Account to run a program.  If they enter their admin account with domain level privileges that is the account context the program runs under.  In some cases it means that program now does not have access to the same network or local resources that their standard user account does (My Documents folder or other file shares on the network that Domain Admins cannot access through a file share).  It also means that if the program is storing user data it stores it in a local path that the non local admin cannot access. (Such as C:\Users\%UserAccount%\....)


    I hope this is fixed in SP1 but somehow I doubt it.


    I am currently Running Vista Business 64bit

    Friday, February 8, 2008 3:44 PM
  • I think you need to change the Local Security Policy for User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode. The explanation from the control:


    User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

    This security setting determines the behavior of the elevation prompt for administrators

    The options are:

    • Prompt for consent: An operation that requires elevation of privilege will prompt the Consent Admin to select either Permit or Deny.  If the Consent Admin selects Permit the operation will continue with their highest available privilege.  This option allows users to enter their name and password to perform a privileged task.

    • Prompt for credentials: An operation that requires elevation of privilege will prompt the Consent Admin to enter their user name and password.  If the user enters valid credentials the operation will continue with the applicable privilege.

    • Elevate without prompting: This option allows the Consent Admin to perform an operation that requires elevation without consent or credentials.  Note: this scenario should only be used in the most constrained environments.

    Default: Prompt for consent


    • Proposed as answer by KieSeyHow Monday, February 2, 2015 10:30 AM
    Friday, February 8, 2008 3:58 PM

    Thank You.   That resolved the issue.  I am still new to Vista and have alot to learn about it quirks.  When I first encountered the problem I searched on MS and could not find the answer in any KB article.  I asked Vista Experts, Vendors and Consultants and nobody could answer the question.


    I am not certain how well I like the UAC but do not want to turn it off until I know there is no workaround for the issues encountered.

    Friday, February 8, 2008 4:27 PM
  • I also had the same issue and would probably of rolled back to XP if I could not find a work around, should definitely be easier to find than message 10 in a forum topic...!


    Also virtually everyone I work with uses this feature...the default should definitely be request credentials if you are on a Domain (IMO)

    Friday, February 15, 2008 10:16 AM
    • Proposed as answer by BillJam Wednesday, June 9, 2010 4:54 PM
    Thursday, March 6, 2008 9:57 PM
  • This information has helped me with the same issue, however this presents the question. What is the difference then between the following two scenarios?

    Scenario 1
    User account domain\user.name who is a member of local administrators and domain users
    UAC behavior set to Prompt for credentials (modified)

    Scenario 2
    User account domain\user.name who is a member of domain users
    UAC behavior set to Prompt for credentials (default)

    It seems that both scenarios result in the same prompts. What would be the benefit of running as a local administrator when you have the same level of UAC prompts as a domain user? The whole point of running as a member of local administrators on XP for me was to take an acceptable security risk while eliminating the need to input elevated privileges on my local machine when doing local admin tasks. Only when I need to perform domain admin activities would I then invoke the Run As command.

    Please correct me if I am wrong, but In Vista it seems that in either scenario I would need to provide credentials for both local admin tasks, and for domain admin tasks. Is there a way to enable local admin tasks with Prompt for consent or Elevate without prompting, while allowing domain admin tasks to Prompt for credentials?
    Tuesday, March 24, 2009 8:29 PM
  • For those of us running Windows 7 and maybe even Vista (never liked Vista), this issue seems to be solved now. I would add that the SHIFT and right-click was nothing I ever had to do with XP (Group Policy ??) but I did wonder where "Run As" went in Windows 7 until I saw this post.


    Also worth noting is the comment Topper1 made which is really the underlying issue at discussion here - for me at least. I repeat the link below.




    Wednesday, June 9, 2010 5:02 PM
  • You do have a “Run” option on the “Start” menu. Right click the Start button and select properties. Click on the “Start menu” tab and select “customize”. Scroll down the list and make sure “run command” is checked.

    Monday, June 14, 2010 5:34 AM
  • This resolved the issue on Windows Vista Business, Windows 7 Professional, and Windows 8 Pro.

    I suggest selecting the "Prompt for credentials" choice as that avoids any other auto-applied credentials from your currently logged in account being passed on and causing annoyances; other than not knowing said credentials of course...

    • Edited by KieSeyHow Monday, February 2, 2015 10:39 AM typos
    Monday, February 2, 2015 10:32 AM