Why doesn’t the RunAs program accept a password on the command line?

Date:November 29, 2004 / year-entry #405
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20041129-00/?p=37183
Comments:    57
Summary:The RunAs program demands that you type the password manually. Why doesn't it accept a password on the command line? This was a conscious decision. If it were possible to pass the password on the command line, people would start embedding passwords into batch files and logon scripts, which is laughably insecure. In other words,...

The RunAs program demands that you type the password manually. Why doesn't it accept a password on the command line?

This was a conscious decision. If it were possible to pass the password on the command line, people would start embedding passwords into batch files and logon scripts, which is laughably insecure.

In other words, the feature is missing to remove the temptation to use the feature insecurely.

If this offends you and you want to be insecure and pass the password on the command line anyway (for everyone to see in the command window title bar), you can write your own program that calls the CreateProcessWithLogonW function.

(I'm told that there is a tool available for download which domain administrators might find useful, though it solves a slightly different problem.)

Comments (57)
  1. Ben says:

    And what about the Runas /savecred switch ? You only need to type your password the first time you run your batch.

  2. Johan Ericsson says:


    IMO, that was a bad decision. Consider my problem. I’m setting up a family member’s computer environment to use limited-user mode. Everything works fine until I realize that Quickbooks won’t run in limited user mode.

    So, I create a special Admin account for runnin Quickbooks under, and I setup a batch file that launches it using "runas". I tried piping the password to the runas command, but it won’t take it. So, my batch file tells the user the password so that they can enter it. How is this more secure than simply allowing the password to be a parameter to the runas command? My solution is also a pain. I guess I need to break out my C++ compiler & MSDN documentation to use "CreateProcessWithLogonW" :(

    Also, why couldn’t the runas /? documentation been more forthcoming regarding this restriction.

    Don’t get me wrong, I love Microsoft’s new security focus. But there needs to be better ways to accomplish what I’m trying to do. Otherwise, we will never get people to use the "limited user" mode accounts at all. Its a chicken/egg problem. Software vendors won’t fix their "limited user mode" bugs until users start demanding it. And users won’t start demanding it until they start using the "limit user mode".

    I’m just sick and tired spending every holiday cleaning out my family’s computers of the latest spyware/adware. I see "limited user mode" as the ultimate solution.

    I haven’t look at EPAL(mentioned above). Perhaps that is a better solution.

    Another interesting approach is detailed here:


  3. Johan Ericsson says:

    Why is /savecred only available in XP Professional?

    It seems useful to home users who are using "limited user" mode.

  4. Christian says:


    Try Microsoft Windows Application Compatibility Toolkit!

    It has the features LuaredirectFs and something similar for the registry.

    This often (unfortunately not always) helps, because it redirects every write-access to c:Programme (that means if the permission fails) to the user-profile or All Users.

    This is really, really great stuff and exactly the right direction to solve this problem!

    Make that broken, stupid, idiotic software from idiot-vendors believe they would be admins and silently redirect stuff and make up a fake world.

    Does somebody know how LuaredirectFS works? Could I code something similar to play tricks to programms?

    Maybe even chroot?

  5. Gene Hamilton says:

    Whats to prevent a program from hooking that function to see if the user/password dialog will open and then steal the password?

    I know it’s already a problem if an univited program is executing, but what if the user is in a limited account? That should sort of limit what damage the program can do, but not if it can get the admin password.

  6. Gene Hamilton says:

    @Johan Ericsson

    http://weblogs.asp.net/aaron_margosis has some good info on running as non-admin.

    You could try two things.

    "You can avoid the right-click context menu and make “Run as…” the default action for a particular .exe or .msc shortcut by opening its Properties dialog, clicking Advanced, and checking “Run with different credentials”. When you invoke the shortcut, you’ll get the RunAs dialog, and the shortcut’s target will run under the account you specify."

    and then use a blank password. His reason for this is:

    "OK, I know you’re bursting already: “No password?!?! Are you insane?!?!” Cool down, now. Starting with Windows XP, a blank password is actually more secure for certain scenarios than a weak password. By default, an account with a blank password can be used only for logging on at the console. It cannot be used for network access, and it cannot be used with RunAs. The user experience of just clicking on your name to log on can’t be beat for simplicity. If you can trust everyone who has physical access to the computer not to log on as someone else or abuse the admin account, this is a great way to go. If not, you can always enable passwords"

  7. Depending on your final needs, you can also use TQCRunAs application.




  8. b100dian says:

    This sounds like a good idea, but the problem is that it cannot be accepted on a large scale: using a blank password and not mentioning it to anybody may work, but using a blank password and telling everyone to do the same.. will generate password.

    So, I am not using this:D

  9. b100dian says:

    sorry.. ‘will generate troubles’, not ‘password’

  10. Gene Hamilton says:

    But in the case of home users (ie. mom and dad) it works great. Very few people have physical access to there machines anyway.

  11. Carl Nettelblad says:

    runas /user:foo bar.exe < foo_password.txt

    Enter your password in that file. Not that I condone it or anything, I just state the obvious.

  12. Jerry Pisk says:

    Carl, the obvious would be "echo "password" | runas /user:Administrator win.exe", that way you don’t have to create another file with the password.

  13. Joseph Moore says:

    As I remember, trying to "|" or "<" the password into a RUNAS command from a source file doesn’t work.

    Personally, I’ve used and recommended TQCRUNAS as a solution for this problem, but I’m gonna look at this EPAL tool.

  14. (http://www.drml.net/runasnet/runasnet.zip)

    Ask and ye shall receive

    …actually I threw this together using pieces of other code I found on the web about two years ago and blogged it onto a now-extinct server.

    Anyway, this is a simple C# app (VS2002 solution source code anyway) that demonstrates using impersonation. I never login to my PC using an account with local or domain admin rights. I just use this little app to ‘promote’ the credentials on a per-process basis.

    [download source via the link above]

    FYI: Impersonation requires ‘ACT AS PART OF THE OPERATING SYSTEM’ privileges. This is the default for XP, but for Win2k you will need to run SECPOL.MSC (The policy configuration snapin), open up LOCAL POLICIES, then USER RIGHTS ASSIGNMENTS and its the second item in the list. You may need to reboot, or at least logout/login in order for the change to take effect.

  15. Pat Piccolo (dr.ml) says:

    oops… the code is right but its the version that uses CreateProcessWithLogonW, not impersonation…I have another version that uses LogonUser (also in advapi32.dll) and then uses the the .net WindowsIdentity to promote the running thread to the credentials of the new user. It works, but not as good as CreateProcessWithLogonW.

    Query: What are some other uses for runasnet, besides running admin tools (like srvmgr and usrmgr) from a domain admin account?

    One use I have for it is that I created different user accounts with different internet explorer settings (like disabled javascript, disallow cookies, or other higher-than-normal security settings) and then created shortcuts using runasnet to run iexplore.exe as those users. Great for testing .net web apps.

  16. Dave says:

    Speaking of feature wishes, I would really like to see the XP command line version of RunAs offer the "protect my computer" option that the GUI RunAs has. Aaron Margosis’ blog shows how useful it can be for IE alone. It would be useful to create a "restricted IE" icon that used that feature.

  17. Raymond Chen says:

    Actually "Protect my computer" isn’t very much protection since you’re still running on the same desktop which means that you can be attacked via messaging.

  18. Ian Baird says:

    4NT (http://jpsoft.com) has a nifty little utility called "keystack" which allows you to simulate keyboard input. For example:

    start RUNAS /USER:Administrator "somecommand.exe" & keystack "mypassword" enter

    This will pop up a new command window and then enter "mypassword" (without the quotes) followed by ther "enter" key. I’m not a part of the JPSoft company, but I think that 4nt is a great product for admins/devs.

  19. Vorn says:

    It should be pointed out that Unix’s login/user change functions – login/sh, rlogin/rsh, ssh, su, and sudo – all require that you input the password manually as well; this is not a feature specific to Windows, and it is the standard operating procedure for nearly all multiuser OSes in the world. Don’t yell at Windows for doing it right, please.

    (sudo is slightly different from the others – most of the above-mentioned commands require that you input the password of the user you intend to work as; sudo requires that you enter your own password, and simply gives you temporary root-like privileges. In most cases your box’s administrator needs to involve himself in allowing you access to sudo, specifically adding your username to the list of users; also, the administrator has access to a complete log of all commands completed under sudo.)


  20. Dave says:

    > you can be attacked via messaging.

    I was more interested in running IE in a sandbox to minimize the chance that a security exploit could cause trouble.

  21. Alexey Kats says:

    A little correction – "sudo" has multiple options and can be set to require root password, or your own password, or the password of a user you try to impersonate. Also, you can explicitely specify the account you want to impersonate – you are not limited to root account only. It’s a very flexible tool.

  22. The "Protect My Computer" checkbox on the GUI version of RunAs in WinXP actually implements the "Constrained" level that Mike Howard discusses here: http://msdn.microsoft.com/security/securecode/columns/default.aspx?pull=/library/en-us/dncode/html/secure11152004.asp

    When I was helping the shell team to integrate that feature for WinXP (I implemented the underlying kernel32 "Safer" APIs), there was some debate of also running the application in a Job Object with some JOBOBJECT_BASIC_UI_RESTRICTIONS flags set, but I think that was removed due to wide application incompatiblity.

    Note that the decision to make the GUI RunAs only have a single checkbox had to be made in order to make the feature easier to understand. We could have allowed the selection of fine-grained Normal/Contrained/Untrusted mode, the option of running in a limited Job Object, or running as another user with restrictions, but that would have made the UI so complicated that most people would not even understand it.

  23. Edward says:

    I suppose the ideal solution to running programs like Quickbooks is to use Regmon and Filemon while running the app under a limited account to find out where it is failing and then creating a new user group that has permissions to modify the files/keys that quickbooks requires and adding all the users who need to run Quickbooks to that group.

    That might be worthwhile when rolling out an application to a few hundred users, but it’s far too much hassle to do for a home user, especially with XP Home that has all the user and permissions GUIs stripped out.

    I’ve been running my XP systems with a limited account for a few months and it hasn’t been too much trouble. My most recent workarounds were for Half Life 2 and DigiGuide which both want to write to their installation directory.

    I actually prefer the OSX method where it prompts for a password when an elevated permission is required rather than failing outright. I suppose that leaves people vulnerable to social engineering attacks if they get used to entering their password at every prompt, but I find I only need to do it once every few days.

    The browser hijackers are already giving people instructions to click on the information bar in XP SP2, there is not a lot more that can be done to protect people from themselves.

  24. Raymond Chen says:

    "running IE in a sandbox to minimize the chance that a security exploit could cause trouble…"

    The chance is reduced but not eliminated. If somebody can inject code into IE then they can call interfere with any other program that has a window. (E.g., find its window, send some messages, change some properties…)

    I just run all the time as a limited account. Only rarely do I have to do something administrative.

  25. Lem says:

    I’m surprised that no one has mentioned psExec (http://www.sysinternals.com/ntw2k/freeware/psexec.shtml), which works as well for running programs under different credentials on the local machine as it does on a remote machine.

  26. Gene Hamilton says:

    One way maybe to get around the problem of programs wanting to write to their installation directory would be to intercept reads/writes to that file. (or redirect with the file is opened) Then redirect to another file, say in Documents and Setting or some place where that user could read/write. This maybe could be done by hooking CreateFile. But I can see tons problems in this method. Maybe there is another way.

  27. Foolhardy says:

    Jeff, one of the things that annoys me the most about Windows is that it has a powerful and flexible base but the UI is too crippled to use it. Isn’t it the point of an ‘Advanced’ button to hide complex buttons that not everyone understands? The advanced dialog should expose 100% of the system’s potential.

    Job objects with UI restrictions provide a great way to insulate untrusted processes from the rest of the desktop. Unfortunately, the only way I could use them was to create my own tool, jobprc:

    As for how to give elevated privileges only to those programs that need it, where appropriate, how about giving the user membership to the Administrators group but making it a deny-only SID normally (for the shell and it’s children), giving the user’s programs a full token only with trusted/necessary programs? The list of trusted programs would be decided by a standard administrator. Digital signing of binaries could also confer trust.

  28. Edward says:

    The file system and registry redirection and default restricted administrator account appear to be upcoming features of Longhorn.

    This article seems to be the most comprehensive so far on the directions Microsoft is moving.


    I just wish it wasn’t all so far off.

  29. JimB says:

    http://www.sysinternals.com have a utility called psexec which will do what you need.

  30. David Candy says:

    I saw a mention of Savecred. If you savecred one thing then there is no security.


    Runas Prog1 /admin /savecred

    will now allow anyone to type

    runas prog2 /admin

    and it will work and run in the admin account with the first statement’s savecred credentials.

  31. SrdjanS says:

    Using PSExec I’ve found some minor gotchas for some Shell APIs. In particular, you can check the following link for one particular problem I encountered:


    This is clearly related to running the said code in a SYSTEM account which is what PSExec will give you by default. It works OK if you’re not running in the system account, through the RunAs methods.

    Anyways, thought I’d point out that there could be other potential issues in applications that run using PSExec…

  32. Gene Hamilton says:


    "Second and more important, it is impossible to bring up a control panel with admin rights without logging off. I guess that the reason for this is that privileges are assigned per process, and the control panel sits inside "explorer.exe". Mr Chen has once explained the reason for this particular design decision: "

    Sure you can. You need to launch a second copy of explorer.exe. To set up this up you need to logon to the admin account and enable "Launch folder windows in a separate process". This has to be enabled on the target account. (i.e. the account you use in runas)

  33. Gene Hamilton says:


    Here is a better way. Create a shortcut with this:

    runas.exe /user:<adminaccount> "control.exe"

    This will open the control panels as admin.

  34. David Candy says:




    Data type Range Default value

    REG_DWORD 0 | 1 0


    Directs Windows Installer to use system permissions when it installs a program. By default, Windows Installer uses the user’s permissions to install programs.

    This entry stores the setting of the Always install with elevated privileges Group Policy. Group Policy adds this entry to the registry with a value of 1 when you enable the Always install with elevated privileges policy. If you disable the policy, Group Policy sets the value to 0. If you set the policy to Not configured, Group Policy deletes the entry from the registry and the system behaves as though the value is 0.

    Value Meaning

    0 (or not in registry) The policy is disabled or not configured. Use the current user’s permissions, except when installing published or assigned programs.

    1 The policy is enabled. Uses system permissions.

    This entry extends elevated privileges to all programs. These privileges are usually reserved for programs that have been assigned to the user (offered on the desktop), assigned to the computer (installed automatically), or made available in Add/Remove Programs in Control Panel. This entry lets users install programs that require access to directories that the user might not have permission to view or change, including directories on highly restricted computers.

    Change method

    To change the value of this entry, use Group Policy. This entry corresponds to the Always install with elevated privileges policy (Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Installer).


    This entry can appear in both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. If this entry appears in both subtrees, the value in HKEY_LOCAL_MACHINE takes precedence over the value in HKEY_CURRENT_USER.


    For detailed information about particular Group Policy settings, see the Group Policy Reference (Gp.chm) on the Windows 2000 Resource Kit companion CD.

    For general information about Group Policy, see Group Policy in Windows 2000 Help.

    To see a table associating policies with their corresponding registry entries, see the Group Policy Reference Table.


    Skilled users can take advantage of the permissions this entry grants to change their privileges and gain permanent access to restricted files and folders. Note that the User Configuration version of this entry is not guaranteed to be secure.

  35. Random says:

    I regularly reconfigure various aspects of my system, like most geeks do. However, I would still like to run my ordinary software (browser, IM client…) under a restricted account. I would not have believed how hard this actually is.

    First, I *can* run ordinary setup programs as administrator using Run As… from Explorer. However, this does *not* work with those "new" .msi-Installers.

    Second and more important, it is impossible to bring up a control panel with admin rights without logging off. I guess that the reason for this is that privileges are assigned per process, and the control panel sits inside "explorer.exe". Mr Chen has once explained the reason for this particular design decision:

    From http://weblogs.asp.net/oldnewthing/archive/2004/10/13/241725.aspx

    > "Why is explorer.exe monolithic? Why wasn’t

    > there a desktop.exe, taskbar.exe, etc?"


    > Processes are expensive.

    I wonder if this is still true, and if it is, why we bother with processes at all and don’t run every single (even 3rd party) Windows service or app as a thread of explorer. "But that would be a horrible security hole!" Oh wait…

    At any rate, I think it’s another case of a premature optimization sooner or later firing back. It forces me to use an admin account for daily work, which sucks because it makes my system a tiny bit less secure.

  36. RJ says:

    Just hold down the left shift key and right click on the control panel item. RunAs is now listed on the context menu.

  37. Gene Hamilton says:


    "However, this does *not* work with those "new" .msi-Installers."

    You can. Open cmd.exe/explorer.exe with admin rights and launch the .msi from there.

    Working with a limited account can be funny because you have to relearn howto do some simple tasks.

  38. Aaargh! says:

    Basically, what’s missing is a ‘sudo’ equivalent for win32 ?

    Looking at the EPAL page, I conclude that’s basically a LDAP version of sudo (correct?).

    So why is there no non-LDAP version ?

  39. Jean-Marc says:

    Johan et al., you should check Sanur at:


    I use it on an XP Home as a workaround for the missing /savecred, and it works pretty fine.


  40. Random says:

    @several people

    Thank you.

  41. marco says:

    for the *ultimate* solution check out our NeoExec/AD (www.neovalens.com). NeoExec allows you to manage privileges (group membership and user rights) on a per-application basis.

    NeoExec does _not_ use/require a second user account as the privileges are changed on the fly.

    It is free for home-users for non-professional use — and up to 5 computers.

    ps: XP Home users go for the "NeoExec Professional" version — all others get the full power and give the Active Directory version a go.

    Marco [alla] neovalens [punto] com

  42. Norman Diamond says:

    11/29/2004 12:01 PM Edward

    > The browser hijackers are already giving

    > people instructions to click on the

    > information bar in XP SP2, there is not a

    > lot more that can be done to protect people

    > from themselves.

    When first reading, I agreed with that, but later I figured out why people are obeying such things. Of course part of the problem is social engineering, but part of it isn’t.

    The old Windows Update used to tell people that they must click yes on every security warning popped up by IE, including that they must click yes and accept unsigned ActiveX controls.

    Even when the old Windows Update itself wasn’t running, other things were. When my parents used Outlook Express and the Windows 98 automatic update informer (whatever it was called) popped up a message advising them to go to Windows Update because patches were waiting, my parents thought that Outlook Express popped that up. When my wife uses Internet Explorer to read her mail on Yahoo, she still has trouble distinguishing between Internet Explorer’s buttons and Yahoo’s web pages’ buttons, and scrollbars, and what needs a single click and what needs a double click. When Internet Explorer pops up a warning saying that the next page is partly secure but partly insecure, she can’t distinguish whether that is from Internet Explorer or from Yahoo and I have to tell her to click yes. When the Windows 98 automatic update informer reports that updates are available, she can’t distinguish whether that report is from Internet Explorer or from Yahoo. I’m the one who understands that it’s neither, and I take the computer and do a Windows Update.

    Anyway, on occasions when people do read what they’re told in various windows, they have been conditioned to obey and to click yes. This is not only social engineering. They have been taught to act this way.

  43. Michael Puff says:

    By the way, how is the keyboard input surpressed while typing the password?

  44. splintor says:

    We had a similar problem with signing cab files.

    The signcode.exe utlity won’t accept password as a parameter, and prompts a password dialog.

    This was a problem in our nightly automated build.

    I ended up writing a small utility that is run before signcode.exe, sleeps in a loop until it finds the appropriate window, and then sends WM_SETTEXT to the password dialog and WM_COMMAND to the OK button.

    I guess I could do it with AutoIt3 (http://www.hiddensoft.com/autoit3/) as well.

  45. cjm says:


    If you want to run a control panel as an Administrator within a limited account, hold down shift and right-click the icon. You’ll see "Run As…". This works with most of them. It doesn’t work for "Folder Options", though.

  46. Kimmo says:

    I’m personally using the freeware utility CPAU from Joeware.net >> http://www.joeware.net/win/free/tools/cpau.htm


    Command line tool for starting process in alternate security context. Basically this is a runas replacement. Also allows you to create job files and encode the id, password, and command line in a file so it can be used by normal users."

  47. Raymond Chen says:

    It doesn’t matter how much you encrypt the password. It gets passed in cleartext to CreateProcessAsUser – that’s where the hacker attacks. Once there, you have the password after it has been decrypted. Good-bye security.

  48. 1 Litre says:


    On my home PC, I’ll take that tradeoff – I need an account where the kids can play Age of Mythology without being able to run all over the hard disc. Most of the utilities mentioned on this thread are "good enough" for what I’m doing, on a firewalled machine that doesn’t use IE/OE.

    (Though IMO the fault lies with the application here – for a game (and an MS-badged game, at that) to require Administrator rights is completely nuts. As long as stuff like that exists, home users won’t use limited-access accounts).

  49. Kimmo says:

    Thanks Raymond,

    I appreciate your comment about the security issues of using an application that uses CreateProcessAsUser. In my, and I guess, others as well, circumstances this is the best we can do to be able to run processes with elevated privilgeges. Do you have some other alternatives that would be sufficent secure?

    Kind regards //


  50. Raymond Chen says:

    I already gave a link to EPAL in the article.

  51. Michael Puff says:

    May I bring back your attention to my question once again?

    "By the way, how is the keyboard input surpressed while typing the password?"

  52. Raymond Chen says:

    I leave that as a (simple) exercise. Look through the console functions.

  53. Michael Puff says:

    Thank you for your hint. I just found "SetConsoleMode", "ReadConsole" and "WriteConsole".

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index