[Webinar] Learn how to a build a cloud-first strategyRegister Now

x
• Status: Solved
• Priority: Medium
• Security: Public
• Views: 4196

My goal is for users to execute batch scripts from Windows 7 laptops that exist on a Windows 2003 server.

I am able to execute the script because I am an admin on the server.

This works for me:

psexec.exe   \\Domain   D:\Restart_Scripts\test.exe

What I was hoping to do was to create a local admin account on the server and then have users map a share to a folder (Connecting using different credentials - the local id I created). They would then double-click the batch file via:

psexec.exe   \\Domain -u Domain\sam  -p Password   D:\Restart_Scripts\test.exe

I have made local id 'sam' an administrator on the server. It has access rights to Admin$too. The only way to get this to work is to add the user who is executing as an administrator to the server and then they can execute successfully as I was able to. Is there a way to accomplish this or does the user have to have admin rights on the server? 0 nowhere982 Asked: • 7 • 6 • 6 1 Solution Commented: psexec.exe \\Domain -u Domain\sam .... this does not look tike you are using a local account unless the name of your host is "Domain" ? ---- can't you give to a domain account the admin rights on this specific machine alone ? using either a dedicated or the existing user accounts ? ----- are you sure your account has the rights to execute the file ? if you created it using a different account, your dedicated account is likely not to have the right on the root of the drive or the file itself. maybe try using -cf and maybe try running filemon on the server ----- last of all, are you sure you are not allowed to connect and not just not allowed to do something the script does. did you try to run a dumb hello world batch file ? 0 C++ DeveloperCommented: Bad, bad idea! Giving out local admin account info will allow anybody to do what they like on the server. Having that in a script or desktop shortcut on a laptop which might leave the office makes me shudder. You should provide a local script using schtasks to start a preconfigured Scheduled Task on the server. That does not require advanced privileges, and allows to run only certain scripts. 0 Author Commented: Qlemo, I created a simple Scheduled Task on my server - the task is "Emailme" and let's call the server "server99". The script sends me an email. I created this batch file on my laptop to execute it: schtasks.exe /Run /S server99 TN "Emailme" It works for me since I am an admin on the server. I was able to execute this Taks using my own account and a local account (tester1) I created under Computer Management for "RunAs". How would I configure this for other people in my company? I want to give them the minimum access allowed. I just want them to execute certain Scheduled Tasks on demand. Can I use this local user account (tester1) created under Computer Management? If so, would they have to map to a shared folder on server99 using tester1 credentials? If the script is on server99, I could control which users have access to map to the folder based on their domain ids. Should they be executing the batch file on server99 or from their laptops? Would I add in the /U and /P parameters to the script? I would be converting the batch file to an .exe so they wouldn't be able to edit the file and see any passwords. Isn't this a similar concept I was originally trying to do? 0 C++ DeveloperCommented: Converting the .bat file to .exe is something different. That is ok, of course, as the password is obfuscated (probably - but I would check that!). In that case using psexec and schtasks is not much different from each other. With schtasks the tester1 user should work, and you do not need to map a network share. However, that way it will not allow for distinguishing the real users. PsExec is more flexible here, as you can provide additional parameters like the real username. However, the local user's privs should not matter at all, only the account provided. You might have to change the working dir for PsExec (-w) to something the impersonated user has access to. Or play with the -s (run as System account). 0 Author Commented: Getting this error now: Connecting to server99... Failed to connect to \\server99\ADMIN$. Access is denied. [Err=0x5, 5]
Failed to copy [\\server99\Restart_Scripts\psexec.exe] to [\\server99\ADMIN$\psexec.exe] -- going to try to continue anyway. Access is denied. [Err=0x5, 5] \\uswsap0510\Restart_Scripts\psexec.exe \\uswsap0510 \\uswsap0510\Restart_Scripts\try.bat This time I did a netuse using a local id for credentials. This local id is also an admin on the server. Will work if I make the user an admin on the server...trying to avoid that and use the local id. 0 C++ DeveloperCommented: Where's that coming from? \\uswsap0510\Restart_Scripts\psexec.exe \\uswsap0510 \\uswsap0510\Restart_Scripts\try.bat If you change the working folder (-w), have the psexec service installed on the remote machine and do not provide the -c or -f options, psexec should not copy anything to the target. All paths used with psexec should be local, however. 0 Commented: does this command work ? what is the output ? net use \\targetComputer\Admin$ /user:sam

---

using schtasks, it is very likely that you will end up with the exact same problem, for the exact same reason

---

not sure what you are trying to achieve, but as far as security is concerned, i believe it would be much better to create a dedicated service that will authenticate transparently a number of domain users, and let them execute a set of predefined commands

one simple way to achive that could be using IIS to authenticate your users using their domain credentials when they access a specific location such as http://computerName/adminStuff/ and execute your batch files as CGI, possibly after switching to a different account locally

----

i also think that giving administrative privileges to thesedomain  users on this specific machine is a simple way to achieve the same thing ; and that will not be much less secure than what you are currently trying to do.
0

Author Commented:
the output of this command: net use u: \\server99\Admin$password /user:server99\test1 is "This command completed successfully" using a local id(test1) created on the server with administration rights. "Access denied" if test1 not an admin. I then try to run this off the share and get "access denied": psexec.exe \\server99 D:\Restart\test.bat (test.bat simply does an echo statement. test1 id has rights to D:\Restart). Only when the person doing the net use is an admin on the server will the script work. I've tried this myself and with others. Summary ------------- 1. net use using local id account test1 2. execute command off share - works if the person is an admin on the server I can deal with this. The advantage of the netuse with the local id is that the person has less authority - such as mapping to \\server99\d$.

The script that they run is an exe so they can't browse it for password.
I also disable their option to logon via RDC to the server.

0

C++ DeveloperCommented:
admin$shares only work for admins, of course - they are administrative shares, created automatically, and you can't change the privs on them. However, as I explained before, there is no need for admin$ access, if the psexec service is already existing on the remote machine.
Executing a command using a UNC path is known to be somewhat flaky with psexec, without having exact rules under which circumstances it works.

However, if you can leave it at that, go on with that workaround.
0

Commented:
once this command works
net use u: \\server99\Admin$password /user:server99\test1 can you try this one ? psexec \\server99 -w %SYSTEM32% -f -c local\path\to\script can you run a filemon on the server while you run the psexec ? 0 Author Commented: here are several results: psexec.exe \\server99 -w \\server99\c$\Windows\system32  -f -c  D:\Restart_Scripts\test.bat
-  The specified application is not on the path.

psexec.exe   \\server99  -w \\server99\c$\Windows\system32 -f -c \\server99\Restart_Scripts\test.bat - PsExec could not start test.bat on server99: The system cannot find the file specified. 0 Commented: the file needs to be located on the client's path when using the -c option i'm using this to determine wether the problem is about setting the psexec service or actually something about access rights on the file you execute btw, i still believe that creating a dedicated service on the server would be much better security-wise and more failsafe as well 0 Commented: i also do not understand why you could not or would not give the existing users administrative access on that specific machine. i recollect this was feasible in AD and it is not less secure than giving them a local admin account 0 C++ DeveloperCommented: psexec -c requires the file to be found on the machine issuing the command (where you execute psexec itself), and the file is then copied into the remote system32 folder, again needing elevated privileges. However, I tried with a non-privileged (domain) user to start an exec of another PC, and that worked flawlessly (something along psexec \\testpc -u domain\testuser -p testpwd \\anotherPC\uts\ftrace -t 1 www.google.com  ), so I don't get where your issues come from. Only strange thing is that the process is executed under SYSTEM account, though I did not provide the -s switch for psexec -- and the user should switch to the one provided. I tested this on 2003 (with anotherPC running W7), and traced with ProcMon. Opposed to that, on a W2008 DC the user changed, but I had to have domain admin privs to allow for connecting to that machine, so this might do another difference. 0 Author Commented: Others in my group initially wanted the users to be admins on the server, connect via remote desktop connection and perform their functions. My concern has always been that they could do unbelievable destruction - unintentionally since they have access to the software and all folders. Rather than logon and use gui tools I know I can provide batch scripts that they could execute instead. When I have them do a net use to the server, psexec and all supporting scripts and files reside on the server. I assumed that a local id with admin rights would be able to copy files to system32 but as you mentioned psexec is quirky. I like using a local admin account for doing a net use because it limits the users to folders that I control - the local id for example can't connect to D$. I also prompt them for the password of the local id.

I don't have an issue giving these users admin rights on the server since that's the only way psexec seems to work correctly. As I mentioned, because I convert the batch file to an exe it keeps the logic and password hidden. They just need to execute a few scripts on the server when we have issues.

Is there something strange executing psexec from a Windows 7 pc - even under admin permissions?

Can you explain this statement? What would I have to do to go this route? I'm open to alternate solutions.

btw, i still believe that creating a dedicated service on the server would be much better security-wise and more failsafe as well

btw, i still believe that creating a dedicated service on the server would be much better security-wise and more failsafe as well
0

C++ DeveloperCommented:
A simple "service" can be a batch file running in an endless loop, waiting for a signal file stored in a specific folder, and triggering actions when found. Users only need to have access to that folder, and maybe to a results folder if needed.

Anything running on the server, and getting triggered or polling for a trigger, can be called a "service". Since you can write VBS or PowerShell code using the FilesystemWatcher object (http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx), triggering by file creation, change, deletion is "easy" and works without any (significant) delay.
0

Commented:
if you are concerned with security, you are on the wrong track
if your users can use psexec with a local admin account, they can launch whatever they want on the remote server including explorer.exe, regedit, cmd ....  which means they can pretty easily do anything they would do in a remote desktop

the access to the d\$ will be controlled exactly in the same way in both cases

building a dedicated service seems to be the right way to do things
it is a simple way to implement controlled privilege escalation
you grant access to some normal users to execute a set of specific predefined commands as privileged users
0

Author Commented:
If I understand you correctly, I can abandon psexec and use this possible script?

Scenario - want a user to kick off a Task Scheduler job without them being an admin on the server. (The job is defined in Runas with a service account for permissions purposes)

- Create a local id and assign it rights to one or two folders on the server
- Provide them with a script(compiled as an exe) for their pc
- When they execute the script, it does a net use via unc share to the server. I will prompt them for a password for the local id.
- This would trigger a script in another folder that kicks off the Scheduled Task (I'm doing this currently in another process - kicking off the task using a service account).
I currently have scripts that monitor folders using WMI Events so I can do something similar

What I'm not sure about is exactly what to do for the folder being modified. The users script could do a simple copy command - copying a file to the older being monitored that would trigger the job in Task Scheduler I suppose. Maybe create a new file in the folder?

Thoughts?
0

Commented:
can't you do something more simple ?

run a daemon as a privileged user. for example a custom telnet that does not provide a command line but just a few preset choices

or possibly use a webserver and make the scripts CGIs. that could let the user trigger tasks using their browsers, see the results in the browser as the tasks run, and possibly use builtin authentication features so only a set of specifiv users can use the service, possibly through transparent authentication
0

## Featured Post

• 7
• 6
• 6
Tackle projects and never again get stuck behind a technical roadblock.