How to complete the RUNAS command in one line [closed]

Question

This Stack Overflow question suggests a command which looks as if it should work, but it doesn't (that answer is deleted now, though):

Single line command for Run as a different user on Window 7 that contains a password also

The command would be:

echo PaSsWoRd | runas /user:Administrator cmd

However it says:

unknown user name or bad password.

The details are definitely correct though. For example, if I was to run:

runas /user:Administrator

...and on the next line, if I typed in PaSsWoRd, it would work no problem.

Coniferous

How about runas /user:Administrator “cmd” < “C:\pass.txt” – Contiguous

You can use runas /savecred ..., it will prompt for password once, then remember it. (see the password storage rundll32.exe keymgr.dll,KRShowKeyMgr) – Blinny

/savecred doesn't work with /netonly though. Most solutions I tried do not work. I didn't try psexec, as it's rather heavyweight for me, but I had success with the RunAs module for powershell and the built-in Windows "Credentials manager". – Williwaw

Answer 1

The runas command does not allow a password on its command line. This is by design (and also the reason you cannot pipe a password to it as input). Raymond Chen says it nicely:

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.

Unconformable

1) I didn't make this decision, so ranting about it to me is pointless. 2) Microsoft definitely made the right decision. Embedding passwords in a script is an egregiously bad idea, for the main reason already stated in the answer. – Unconformable

you could psexec from microsoft sysinternals e.g. psexec -user MyUser -p MyPassword "cmd" – Deoxidize

1) Using that "feature" is a bad idea and egregiously insecure. 2) You still cannot elevate from a non-elevated process without provoking the UAC prompt. – Unconformable

If anyone is curious: The "answer" from @N.S (which was, oddly, posted as a separate question rather than as another answer here) suggests using the WshShell COM object's SendKeys method to simulate typing a password for the runas program. That's even more insecure than if runas accepted a password on its command line, because it will send the keystrokes to whatever window has the current focus! I hope it goes without saying that this is a very, very bad idea and I hope nobody is actually doing this. – Unconformable

this topic has closed so i could not send answere so i wrote it as a new post. about security your right i just wanted to give a method to do the job. every one edit the code can read your password , so you can write a function to recive the password or what else needed. – Switzerland

here is code in a vbs file – Switzerland

Set oShell = CreatedObject("WScript.Shell") oShell.run("cmd.exe") WScript.Sleep 30 oShell.AppActivate "cmd" oShell.SendKeys "runas /user:poorTarget cmd.exe" oShell.SendKeys "{ENTER}" oShell.SendKeys "password" oShell.SendKeys "{ENTER}" – Switzerland

As I already noted, this is a very bad idea. I hope you are not really doing this on a production system anywhere. – Unconformable

Some of us have to live in big company hell where horrible hacks are the only way to duct tape things together. – Gesture

I refer the honorable gentlemen to the answer to this question and my previous comments. – Unconformable

My intent wasn't to antagonize but to point out that this is an example of when people ask for security holes as features. There are other secure ways of running an executable without exposing (administrative!) credentials in such an egregious way as embedding them in plain-text in a script. – Unconformable

Fair enough, I apologise for going off on an uncalled-for rampage...your comments just hit a nerve as I've struggled with 1000's of instances of "I can't run/do this thing I want to do on my own computer that I paid good money for" since Windows XP. I do agree however that the average user should not be able to do such things without understanding the full implications. The fact that power users have to suffer as a consequence?? Well it just sucks IMO :-( – Upbear

True power users, IMO, are more than capable of learning how to work with the system rather than against it. These kinds of security restrictions are not arbitrarily put into place to annoy people. – Unconformable

@AndrejaDjokovic usability-wise, yes user should be given more control. But the issue why it is prohibited is related to legal and money. When a user's PC suddenly was hacked due to usage of such password literals in scripts that is made by user themselves, the user starts to blame the developer company, and start suing. This is what developers trying to avoid - aka losing money for user's stupidity. – Kickapoo

As an aside: Downvoting this answer is silly, because the answer is correct. Not liking the answer doesn't change the fact that it's the answer. – Unconformable

Bill_Stewart +1 for a great answer even though I don't agree with it. I'd side with @AndrejaDjokovic on this one, that said this is a excellent topic for a separate security specific ticket. it's a broader question, who's exactly should be responsible for the security of the "usage" of a application? – Irritant

As noted already, MS made the decision not to allow a password on the runas command line. If you want to write your own program to do it, you're free to do so, of course, but at least MS isn't responsible for potential abuse. (Such a program is a bad idea anyway, IMO, as there are other ways of automating without exposing passwords in plain-text in a file.) – Unconformable

Microsoft treats professional developers and system administrators as children. We are not children, we have good reasons to perform tasks such as this ones. If a developer creates a security risk because of negligence, the problem is the developer, not the operating system. The should provide a system to security execute programs as another user, such as the sudo in Linux. – Alesandrini

As already mentioned several times, this design decision was intentional, and I guess I would be repeating myself if I said it's pointless to complain about it here. – Unconformable

Well this is totally possible to do a 1-liner from Dos. Just use powershell. powershell -command "& {&'Start-Process' -Credential (New-Object System.Management.Automation.PSCredential ('domain\user', (ConvertTo-SecureString 'Password123' -AsPlainText -Force))) -FilePath "notepad.exe"}" You can also add -verb runas to force admin rights – Epigastrium

1) A cmd.exe command prompt window is not "Dos". (DOS was a single tasking 16-bit operating system.) 2) Elevation will still provoke a UAC prompt. This is by design. 3) I guess I would be repeating myself if I said it is a very bad idea, for an innumerable number of reasons, to embed any kind of administrative password in plain-text in a script. – Unconformable