Welcome to MSDN Blogs Sign in | Join | Help

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

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.)

Published Monday, November 29, 2004 7:00 AM by oldnewthing
Filed under:

Comments

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 7:20 AM by Ben
And what about the Runas /savecred switch ? You only need to type your password the first time you run your batch.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 7:33 AM by Johan Ericsson
Grr...

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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure11152004.asp

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 7:37 AM by Johan Ericsson
Why is /savecred only available in XP Professional?

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

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 7:55 AM by Christian
@Johann:

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?

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 8:02 AM by Gene Hamilton
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 8:07 AM by Gene Hamilton
@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"

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 8:21 AM by Benjamin Mateos
Depending on your final needs, you can also use TQCRunAs application.

http://www.quimeras.com/Products/displayproduct.asp?IdProduct=4

/r

Benji

# re: Blank password

Monday, November 29, 2004 8:23 AM by b100dian
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

# re: Blank password

Monday, November 29, 2004 8:24 AM by b100dian
sorry.. 'will generate troubles', not 'password'

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 8:28 AM by Gene Hamilton
But in the case of home users (ie. mom and dad) it works great. Very few people have physical access to there machines anyway.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 9:47 AM by Carl Nettelblad
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 10:00 AM by Jerry Pisk
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.

# Using the "<" doesn't work

Monday, November 29, 2004 10:05 AM by Joseph Moore
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 10:11 AM by Pat Piccolo (dr.ml)
(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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 10:26 AM by Pat Piccolo (dr.ml)
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 10:29 AM by Dave
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 10:47 AM by Raymond Chen
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 11:03 AM by Ian Baird
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 11:19 AM by Vorn
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.)

Vorn

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 11:20 AM by Dave
>> 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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 11:35 AM by Alexey Kats
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 11:57 AM by Jeff Lawson [ex-msft]
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 12:01 PM by Edward
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 12:03 PM by Raymond Chen
"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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 12:29 PM by Lem
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 12:48 PM by Gene Hamilton
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 12:58 PM by Foolhardy
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:
ftp://68.62.27.206/pub/jobprccur.zip

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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 1:32 PM by Edward
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.

http://msdn.microsoft.com/library/en-us/dnlong/html/leastprivlh.asp

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

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 2:53 PM by JimB
www.sysinternals.com have a utility called psexec which will do what you need.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 3:09 PM by David Candy
I saw a mention of Savecred. If you savecred one thing then there is no security.

EG

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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 3:13 PM by Random
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 3:19 PM by SrdjanS
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:
http://groups.google.com/groups?q=platformsdk+shell+srdjan&hl=en&lr=&selm=f052d26.0409211321.31b15ce0%40posting.google.com&rnum=1

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...

# Why doesn't Runas accept a password via the command line?

Monday, November 29, 2004 7:10 PM by James Summerlin's Blog

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 4:23 PM by Gene Hamilton
@Random

"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)

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 4:33 PM by Gene Hamilton
@Random.

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

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

This will open the control panels as admin.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 4:37 PM by Gene Hamilton
@Random

"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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, November 29, 2004 5:53 PM by David Candy
Eandom

AlwaysInstallElevated
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer

Data type Range Default value
REG_DWORD 0 | 1 0

Description
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 Configuration\Administrative Templates\Windows Components\Windows Installer).

Note

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.

Tip

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.

Caution

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.

# re: Opening Control Panel Item

Tuesday, November 30, 2004 12:21 AM by RJ
Just hold down the left shift key and right click on the control panel item. RunAs is now listed on the context menu.

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, November 30, 2004 1:37 AM by Aaargh!
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 ?

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, November 30, 2004 6:48 AM by Jean-Marc
Johan et al., you should check Sanur at:
www.commandline.co.uk/sanur/
I use it on an XP Home as a workaround for the missing /savecred, and it works pretty fine.

HTH

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, November 30, 2004 8:02 AM by marco
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

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, November 30, 2004 10:08 AM by Random
@several people

Thank you.

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, November 30, 2004 6:19 PM by Norman Diamond
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Wednesday, December 01, 2004 1:18 AM by Michael Puff
By the way, how is the keyboard input surpressed while typing the password?

# re: Why doesn't the RunAs program accept a password on the command line?

Wednesday, December 01, 2004 3:03 AM by splintor
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Wednesday, December 01, 2004 6:42 PM by cjm
Random,

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.

# re: Why doesn't the RunAs program accept a password on the command line?

Sunday, December 05, 2004 10:22 AM by Kimmo
I'm personally using the freeware utility CPAU from Joeware.net >> http://www.joeware.net/win/free/tools/cpau.htm

"Summary

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."

# re: Why doesn't the RunAs program accept a password on the command line?

Sunday, December 05, 2004 10:29 AM by Raymond Chen
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.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, December 06, 2004 2:33 AM by 1 Litre
Raymond:

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).

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, December 07, 2004 2:43 PM by Kimmo
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 //
Kimmo

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, December 07, 2004 3:03 PM by Raymond Chen
I already gave a link to EPAL in the article.

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, December 13, 2004 9:36 PM by Michael Puff
May I bring back your attention to my question once again?
"By the way, how is the keyboard input surpressed while typing the password?"

# re: Why doesn't the RunAs program accept a password on the command line?

Monday, December 13, 2004 9:48 PM by Raymond Chen
I leave that as a (simple) exercise. Look through the console functions.

# re: Why doesn't the RunAs program accept a password on the command line?

Tuesday, December 14, 2004 1:15 PM by Michael Puff
Thank you for your hint. I just found "SetConsoleMode", "ReadConsole" and "WriteConsole".

# Avviare il Pannello di Controllo tramite runas

Saturday, April 29, 2006 6:23 PM by Alex's Weblog

# People get hacked, not machines &laquo; Blogs are like opinions. Everybody has one&#8230;

Friday, May 04, 2007 4:23 AM by People get hacked, not machines « Blogs are like opinions. Everybody has one…

PingBack from http://adamo.wordpress.com/2007/05/04/people-get-hacked-not-machines/

# jernstrom.org &raquo; CPAU (Create Process As User)

Friday, January 02, 2009 1:18 PM by jernstrom.org &raquo; CPAU (Create Process As User)

PingBack from http://jernstrom.org/site/2006/01/cpau-create-process-as-user/

New Comments to this post are disabled
 
Page view tracker