3

I have a script in which I have used runas /savecred. First time it asked me for password. Later on it didn't ask me and it was working fine. But if another user logs on to the same server and runs the same script its asking him to enter the password.

How can I make the password to be stored for any user who kicks off that batch file.

I have checked Start > Run > control userpasswords2 > Advanced > Manage Passwords. It shows the stored username only when I am logged in. How can we store the same username and password be for all on the same machine?

5 Answers 5

17

The short answer: DO NOT DO THIS. You're only going to open your system to a HUGE, and I do mean HUGE system security flaw: Once you /savecred, you're saving your admin password to the users profile, UNCONDITIONALLY, for them to use any time, any way they like. That means, once saved, they can launch a console window (CMD prompt), type in "runas /savecred /user:administrator cmd.exe" and instantly launch a new command console with full admin rights to do anything they want. You probably do not want them to be able to do this!

What I think you really want is to allow any user to run a specific command without being asked for elevated (admin) permissions or needing to enter an admin password. For this, there is a secure and working solution in modern Microsoft(tm) Windows operating systems: Set the program to run as a scheduled task with the specific access rights that the program needs. You might create a user account specifically for this program, or you might just use the admin/system credentials for this, and only this, program. Here's how..

First, you need to set up a scheduled task, like any other scheduled task. You must assign it a specific command line (so if you need to pass parameters to the task, you'll have to use scripting or batch files to create an "parameter file" to pass the parameters to the program, or use some other method to do so.. This solution isn't perfect!). You can then assign it whatever security rights you need to give it. Name it something appropriate--and avoid the use of spaces in the name to keep it simple; We're going to be using this name to actually run the program when your user needs to run it. Also, do not schedule an actual time to run the task, since we'll be calling it to run on demand in a moment, rather than always running at a specific time.

Once the task is created, the next question is going to be "How do I RUN it?" Well, you either create a shortcut, or a batch/script file, which will call the scheduled task to run: "schtasks /run /tn name-you-gave-the-task-above". So, if you created a task called "AutoAddLocalPrinters" (a common admin task, for example), you'd create a batch file or shortcut to run the command "schtasks /run /tn AutoAddLocalPrinters" (if you did name it something with spaces, you'll have to put the entire name in quotes--this is why I avoid spaces in names).

Note that the only time it requires admin rights or a password is when setting up the scheduled task. Just running the task once set up does not need a password, does not ask for one, and most importantly, does not globally and blindly save the admin password to the users profile. It's saved as part of the scheduled task, which only affects that, and only that task, and won't let the user modify or change it, or start a new elevated console prompt with it, etc.

Furthermore, you can adjust the permissions on the scheduled task to allow only certain user groups to run it, and so on. You can further fine tune it by creating special user accounts or batch/script files with which you can check and validate any permissions of criteria you desire. For example, if you have children, you can create a script which checks if it's past their bedtime before allowing them to launch their chat program.. ;-) In short, you can pretty much do anything you want or need to do to validate and control how the program is run (or denied).

Finally, one more advantage (or disadvantage..) to doing it this way: It works on just about every edition of Windows where you can schedule tasks and run the "schtasks" command. For example, my understanding is that Windows Home editions ignore the /savecred option of "runas" anyhow, so you'll always have to provide the password. A scheduled task will run with the credentials you set it up with, even in Home editions.

Footnote: I mention this because I usually remove many program paths from the system PATH variable, and add "C:\sys\admin;C:\sys\bat;C:\sys\bin" to the system path. Then under the "C:\sys*" folders (you'll need to create them, obviously), I create individual batch/script/shortcut files which call the real programs or scheduled tasks. This way, I have complete control over who, what, when, where, and how various programs are allowed/disallowed to run. It also helps prevent stupid errors--One error I've actually encountered was one of my end-users trying to convert a file and running the "convert" command without knowing what they were doing. Since Windows already has a "convert" command, which converts FAT to NTFS, all they managed to do was convert their file system.. They got lucky and it still worked since their computer didn't care if the file system was FAT or NTFS. But now I always have a C:\sys\bat\convert.bat file which slaps them on the hand and tells them to talk to me before trying to run this command.. ;-) I do the same with many other potentially dangerous or power-user commands that can seriously cause problems when mis-used/mis-typed.

Good luck!

Edited 2020-09-18 to add:

  1. As an administrator (even in the context of a personal/home computer, not just professionally), get in the habit of ALWAYS securing your file system and files. Do not give read, write, execute, or other types of permissions to users unless they really make sense in context. I strongly advise against giving additional access rights simply because it may reduce administrative headaches--the headaches caused by mis-use, whether benign or malicious, far outweigh the extra work done to keep your system secure in the first place. I personally even set up and use two user accounts for myself, a administrative one and a "regular user" one for my daily and regular use. Despite the hassle of switching between them a lot, it has saved me from far worse issues when it comes to others' attempts to "hack" systems I manage, including (but not limited to) keyloggers, trojans, viruses, and even my nephew simply innocently trying to set up a game server to game with a 'friend'--which said 'friend' tried to exploit a game server flaw to gain access to his system.
  2. I have not reviewed my original post to update it for Windows (tm) versions after Windows XP/2003/7, which are no longer supported by Microsoft (tm). I have switched to a Linux based OS around 2016, and am no longer "up to date" on issues with Microsoft Windows based systems to further verify things.
3
  • 3
    Add note: If you've already EVER run "runas /savecred ..." under the user account, you'll have to remove the saved credentials with this command: rundll32.exe keymgr.dll, KRShowKeyMgr -- You'll also be able to see a list of any credentials the user will be able to use with "runas".
    – C. M.
    Apr 20, 2015 at 17:32
  • which is safe solution ?
    – Kiquenet
    Jan 21, 2020 at 9:47
  • @Kiquenet: I gave a detailed solution, using a scheduled task. It's a bit of work to set up, but it's safe and can be set up once, and then you can use batch files, powerscript, or just about any other method you like to control who/what/when/how users can execute it.
    – C. M.
    May 19, 2020 at 5:15
4

A script can be run as a task, but if we have to run an interactive application as another user, then creating a task does not work. You will have to necessarily tick the box "Run whether user is logged on or not" and if you do that, the task will not show the user interface of the application. Dont know whether there is a solution for this.

3
  • I recommend not presenting a user interface for any command which allows the user to enter arbitrary--and thus, potentially unsafe--input at any time. If you need user input, you can use a multi-stage method. Collect the input with a custom made script, check and scrub the input for safety, then pass it on to the system command in a secure fashion.
    – C. M.
    Sep 19, 2020 at 1:59
  • 1
    @C.M. I think you missed the point of this answer. The program being launched isn’t asking for input. It merely has a user interface. Creating a scheduled task this way forces the application to run “in the background” and the desired UI is suppressed. (Windows 10) May 31, 2021 at 1:55
  • I did not "miss the point", but rather, you are presenting an answer that circumvents system security. Almost any application which would require elevated permissions will provide a non-interactive method to operate without the need for user input via a UI. Thus, if you need user input, you can, and should, use some other method to get the user data, scrub it to remove anything dangerous, and then pass that on to the application.
    – C. M.
    Apr 11, 2022 at 12:12
1

There is not a simple way to run a program with higher privileges without /savecred option, if the program must be interactive.

With scheduled Task the interface is not shown to the actual user, so it's not possible to interact.

The only way i've found for my purpose was to create a small vb program that launch a runas command (without /savecred option) and then send the password to the Dos window through the Windows API SendMessage.

User and password are stored in the Windows Registry, and password is crypted with a Blowfish Algorithm (in my case, but everyone can choose a different way).

Then i simply launch that program when i need it (in my case during login).

I don't know how to attach the source code, anyway this is the main part:

Declaration:

Private Declare Sub Sleep Lib "kernel32.dll" (ByVal dwMilliseconds As Long)
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal 
lpClassName As String, ByVal lpWindowName As String) As Long

Private Declare Function GetSystemDirectory Lib "kernel32" Alias 
"GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As 
Long
Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" 
(ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As 
Any) As Long

Private Const WM_CHAR = &H102
Private WshShell 

Body:

' Used in a Subroutine
If Not IsRunning("runas.exe") Then

                        Set WshShell = CreateObject("WScript.Shell")
                        Set WshEnv = WshShell.Environment("Process")

                        rc = WshShell.Run("runas /user:" & sUser & " notepad.exe", 2, False)
                        Sleep 400

           End If
                       SendPass    

The function isRunning check if there is already an active runas window:

Private Function IsRunning(ByVal proc As String) As Boolean

Dim oProcs As Object
Set oProcs = GetObject("winmgmts:").ExecQuery("SELECT * FROM Win32_Process 
WHERE Name='" & proc & "'")
IsRunning = (oProcs.Count > 0)
Set oProcs = Nothing
End Function    

And the function SendPass , send the password to the runas command:

Public Function SendPass()
Dim winHwnd As Long
Dim sSave As String, Ret As Long
Dim intConta As Integer
Dim bytBuffer() As Byte
sSave = Space(255)
Ret = GetSystemDirectory(sSave, 255)

sSave = Left$(sSave, Ret)
winHwnd = FindWindow(vbNullString, sSave & "\runas.exe")

If winHwnd <> 0 Then

    bytBuffer = StrConv(sPass & vbNullChar, vbFromUnicode)


    For intConta = 0 To UBound(bytBuffer, 1) - 2
       Call SendMessage(winHwnd, WM_CHAR, bytBuffer(intConta), ByVal 0&)
    Next intConta
End If
End Function
2
  • You can always collect interactive data with an unsecured program/script, pass it (via command line or "drop files") on to a secured program/script which scrubs/validates the data, which finally passes it on to the system privileged command as needed.
    – C. M.
    Sep 19, 2020 at 2:03
  • Why you don't use the Windows API (CreateProcessWithLogonW) to launch directly the application? Check this: stackoverflow.com/questions/480358/…
    – NetVicious
    Oct 21, 2021 at 8:40
0

If you don't mind to have the password in cleartext in the script, you can use

runas /user:DOMAIN\youradminuser C:\somepath\somefile.exe

But most of the time it's probably not suggested to save passwords cleartext...

-1

The file are stored under: %appdata%\Microsoft\Credentials There a hidden system file will be created, which you can properly open with a hex editor to read the content.

1
  • 1
    Welcome to Super User. This does not explain how to do what the OP is asking. Please do not respond in the comments. Instead, edit the post with this information. Dec 19, 2018 at 12:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .