I'm looking for a way to create an index of files on a web page hosted on out intranet.

The files are located on various network shares, eg \nas\documents\tender.doc

When a user clicks on the file I want the file to be opened on there PC with whatever program they have associated with it. eg *.txt open with notepad++, *.doc with word etc

The user needs to be able to edit the file and then save it in its original location.

I don't want the user to have to download the file, edit it and then upload it.

  • I'm confused. I don't think the given command runs as SYSTEM. Why do you need to run something "as SYSTEM" but with alternate credentials anyway? – Iszi Jul 29 '14 at 21:59
  • And how do you plan on capturing the user's password, and storing it encrypted until the program needs it? (Neither of which you should be doing. Passwords should be hashed - and then some - not encrypted. But you'd need to use encryption if you were planning to re-use the plaintext as a command argument in the first place. And nothing should be capturing the user's password to begin with except the system/application for which it was designed to be used.) – Iszi Jul 29 '14 at 22:22
  • If you're actually writing a program, there's probably a dozen better ways to do this with API calls or somesuch. Unfortunately, that's out-of-scope here. Try Stack Overflow. – Iszi Jul 29 '14 at 22:25
  • Also, why do you feel the need to run your program as a service, as SYSTEM? Plenty of background processes run as the current user. And if you'll need to prompt the user for credentials otherwise anyway, you may as well just run it with the user's token to begin with and just minimize to tray until needed afterward. – Iszi Jul 29 '14 at 22:59
  • 2
    I suggest instead looking through here, here, here, and here - then, if you're still stuck, here - for solutions that don't involve running additional software on end-users' computers, or capturing their passwords, first. – Iszi Jul 29 '14 at 23:46

Use the same psexec command, but without -p SomePassword. You should be prompted to enter the password, and your input will not be displayed on-screen.

If this is part of a batch script, put the following at the start of the script:


That will disable command echoing to the terminal, so the commands in the script will not be displayed as they run. Command output will still be displayed.

If you want to leave command echoing on, but just hide this one, precede it with an @ sign. Example:

@ PSExec.exe -accepteula -h -d -u someUser -p somePassword -i 1 C:\WINDOWS\SYSTEM32\CMD.EXE /c start "" "C:\WINDOWS\SYSTEM32\CALC.EXE

Do bear in mind that the password will still be available as plaintext in the script file. In general, that's a bad idea.

  • @JamesG See my update, and comment to your question. – Iszi Jul 29 '14 at 22:00
  • @JamesG And we're back to why putting passwords into scripts is a bad idea. Again, why are you doing this to begin with? I'm still having a hard time thinking of a use case for "run as SYSTEM, then let system run as a different user". – Iszi Jul 29 '14 at 22:16
  • @JamesG In the script or in memory, the point is it's being stored in a place and manner which is not secure. If you're worried about an attacker dedicated enough to know and bother to check the parameters in Task Manager, you should be just as worried (if not more so) about the one who's going to be scraping the system's RAM. – Iszi Jul 29 '14 at 22:27
  • 1
    Most browsers these days are intelligent enough to seek out or prompt the user for an external application (with many built-in as defaults upon install) when the browser itself cannot open a certain file. Also, be aware that linking to file shares may not work on pages served over plain HTTP due to default browser restrictions. (Though testing of pages stored in the local file system worked fine for me.) This is for very good security reasons that should not be tampered with. – Iszi Jul 29 '14 at 23:23
  • 1
    @AdiInbar I think that point is really moot right now. This is obviously an XY Problem. – Iszi Jul 29 '14 at 23:34

Using PowerShell, you can store the username and encrypted password in a text file. The automated task can read the credentials credentials from the text file and create a PSCredential object, the use Start-Process to launch the executable using those credentials.

  1. Store the credentials:

    $path = <path_to_text_file>
    Read-Host "Username" | Out-File $path
    Read-Host "Password" -AsSecureString | ConvertFrom-SecureString | Out-File -Append $path

    Note that ConvertFrom-SecureString does not decrypt the secure string into plain text; it converts it to cryptotext that can be stored in a file. After running this, you'll have a file with two lines. Line 1 contains the username, and line 2 contains the encrypted password.

  2. In the automated task, read the credentials and use them to launch the executable in that accounts context:

    $stored_creds = Get-Content <path_to_text_file>
    $username = $stored_creds[0]
    $password = $stored_creds[1] | ConvertTo-SecureString
    $credential = New-Object System.Management.Automation.PSCredential $username, $password
    Start-Process <path_to_executable> -Credential $credential 

    Note that <path_to_executable> is just that: the path to the executable, not the full command line ('C:\Windows\System32\calc.exe' in your example). If you have any arguments, tack on -ArgumentList <the_rest_of_the_command_line>.

  • "Decrypt", "Hash"... I do not think these words mean what you think they mean. "Hashes" cannot be "decrypted". Regardless, this doesn't address the issue the OP mentioned of being able to see the parameters used for PSExec in the end. (Neither does mine, at this point, but I'm leaving it up for the comment thread at the moment.) – Iszi Jul 29 '14 at 22:48
  • The term "hash" means several different things. One of the common meanings is the cryptotext produced by a cryptographic hash function. And yes, this absolutely addresses the issue. At no point is the password exposed. It does get stored in plain text in RAM while the script is running, but if you're concerned about the possibility of the RAM location being paged out and captured from the pagefile, you can skip the variable assignment and replace $Password on the second line with the expression assigned to it on the first line. – Adi Inbar Jul 29 '14 at 23:21
  • 1. You should read your own wiki links. The very first sentence says, effectively, that hashes cannot be decrypted - they are one-way functions. 2. This still does not address the issue. Any time you run PSExec (doesn't matter how you do it) the parameters passed to it must be converted to clear plaintext (otherwise they'll be unusable by PSExec) and then those parameters will be available by viewing PSExec.exe in Task Manager and choosing to show the "Command Line" column. – Iszi Jul 29 '14 at 23:29
  • 1
    @Iszi Okay, I see what you mean, you're right on both counts, I just hadn't thought it through carefully. The output of ConvertFrom-SecureString can't be a hash if it's reversible. And the password can be seen in Process Monitor if it's supplied as a command line argument to psexec by any means. In that case...I'm still not sure what the problem is with using runas or just using psexec without the Password argument and being prompted. But in any case, Start-Process is always an option... – Adi Inbar Jul 29 '14 at 23:52
  • 1
    The commands are being output from a program, so either I need to pass the password as an argument or I could make the user enter the password once as part of the setup procedure. I looked into using runas and start-process, but neither of them work if your logged in as system. – James Jul 30 '14 at 0:16

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.