30

Is it possible to use psexec to execute a command on a remote machine without having admin privileges on the remote machine?

I tried running psexec \\<machine> -u <username> -p <password>, where <username> and <password> are non-admin credentials, but I get an "access denied" error

I can remote desktop into the remote machine with the same credentials without any problems.

My local machine is running Windows 7 Enterprise 64-bit, and the remote machine is running Windows Server 2008 64-bit. I do have admin privileges on the local machine.

EDIT: To all the people who are downvoting this question: I am not trying to circumvent any sort of security measure. I can already run the process on the remote machine by remote desktop-ing into the remote machine and running it. I'm simply looking for a command-line way to do something I can already do through a GUI.

HighCommander4
  • 433
  • 1
  • 4
  • 8

9 Answers9

28

As found at: https://stackoverflow.com/questions/534426/psexec-help-needed

You need to have admin rights on the target as part of psexec starts up a windows service on the target, and you need admin rights to be able to do that.

psexec copies a psexecsvc file to the admin share and then using remote management starts up a service using that file. It opens up named pipes and uses that for further communication. When it's finished it tidies up after itself.

Although I can't find OFFICIAL documentation that says the same thing.

Community
  • 1
Safado
  • 4,836
4

Ask to be local admin on the machine.

Edit: Or run the command as a scheduled task. Or use the -l switch in PsExec:Run process as limited user (strips the Administrators group and allows only privileges assigned to the Users group). On Windows Vista the process runs with Low Integrity. See here:http://technet.microsoft.com/en-us/sysinternals/bb897553. Sorry to say but RTFM!

For example: To run Internet Explorer as with limited-user privileges use this command:

psexec -l -d "c:\program files\internet explorer\iexplore.exe"

Note that the password is transmitted in clear text to the remote system.

Turdie
  • 2,945
1

in former times this was possible. Windows offered a virtual share called IPC$. Because the IPC$ was shared to everyone. Till NT4 SP2. Later it was restricted to "authenticated users", then around 2009 MS has removed all default shares like the "file and printer share" and starting with Windows 7 / SErver 2008R2 the built in firewall acts with the "need to have" principle, and without exceptions it is just closed. Gents, the barn door days are gone. The "admin for everything" is gone, the "sysadm" is gone and you MUST DO THE HEADACHE STUFF. IPC means Inter Process Communication and in the early days this was the barn door because in the first rights concept of Windows NT there was a "guest" account active by default and guest could launch processes. Nowadays (2023) concept of security is "to accomplish a task with the least possible privileges". People used to give everyone the admin rights will loose their job nowadays because of incompetence in the area if IT security, and if one of my guys says "well we will take the Administrator account" I will ask him from whom he got a bonus to say that. Hackers are everywhere, automated bots to find exploid possibilities are standard. For that reason noone has to be an admin, but what do we need exactly? PSexec will launch a process in session 0. To do so the account used requires the privilege "log on as a service", possibly the "logon interactively" is requried too and certainly an non administratvie acocunt must have access to the .exe file to be launched with "Read Execute" permissions, the process will most likely process some data stored in a folder where that user account must have "modify" rights. And the process must be made for running without a GUI, e.g. no modal dialgues and fully made for automation with scripts or launch parameters.

Taken from the systinternals "remote process explorer" documentation

Port 135 (TCP) - for Remote Procedure Call (RPC) Service (that's what psexec will do too) Port 137 (UDP) - for NetBIOS Name Service Port 138 (UDP) - for NetBIOS Netlogon and Browsing (used in PSEXEC to verify the provided user name annd password) Port 139 (TCP) - for NetBIOS session (NET USE) Ports above 1024 (TCP) - for RPC Communication. DCOM needs open UDP ports in the 1024-5000 range.

Ojutan
  • 11
  • 2
1

Nope, not in a useful way. Why would you want to do this and not be an admin?

John Gardeniers
  • 27,844
tony roth
  • 3,952
  • 20
  • 14
1

You'd probably be better off using Powershell commands:

Robert Ebers
  • 11
0

A solution would be to use an AutoIT script to log into your remote desktop on a schedule from your workstation. Have your "startup" folder execute your process via either a batch script or another AutoIT script (so that you can cancel if doing other work). This is not command line, but it does automate your work within the parameters that your sysadmin has given you. Hope it helps.

Thrakorzog
  • 1
-1

`const string subkey = "Software\Sysinternals\PsExec";

        if (Environment.Is64BitOperatingSystem)
        {
            // For 64 Bit PC
            RegistryKey registryKey64 = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry64);
            RegistryKey NDPKey64 = registryKey64.OpenSubKey(subkey);
            if (NDPKey64 != null)
            {
                Registry.CurrentUser.OpenSubKey(subkey, true).SetValue("EulaAccepted", 1, RegistryValueKind.DWord);
            }
            else
            {
                RegistryKey regKey64 = registryKey64.OpenSubKey("Software", true);
                regKey64.CreateSubKey("Sysinternals\\PsExec", RegistryKeyPermissionCheck.ReadWriteSubTree);
                Registry.CurrentUser.OpenSubKey(subkey, true).SetValue("EulaAccepted", 1, RegistryValueKind.DWord);
            }
        }
        else
        {
            //For 32 bit PC
            RegistryKey registryKey32 = Registry.CurrentUser.OpenSubKey(subkey);
            if (registryKey32 != null)
            {
                Registry.CurrentUser.OpenSubKey(subkey, true).SetValue("EulaAccepted", 1, RegistryValueKind.DWord);
            }
            else
            {
                RegistryKey regKey32 = Registry.CurrentUser.OpenSubKey("Software", true);
                regKey32.CreateSubKey("Sysinternals\\PsExec", RegistryKeyPermissionCheck.ReadWriteSubTree);
                Registry.CurrentUser.OpenSubKey(subkey, true).SetValue("EulaAccepted", 1, RegistryValueKind.DWord);
            }
        }`
Shyam
  • 1
-1

Why does someone not just say that it is not possible? I need to do something similar (Remote Exec a SAS Program), which I do have access to do if I RDP into that server (i.e. I have logon access to the server. I have file system access to the source code folder and I have access to run SAS).

No sysadmin is his/her right mind is going to grant me full admin rights on that box just to exec remotely. Basically PSTools is a sysadmin tool not designed to be used for the deployment of actual IT system solutions.

Kenny Rasschaert
  • 9,175
GMT
  • 11
-2

There is probably a way to do this. It's probably as simple as editing WMI permissions on the machine. If it's not possible, then using something like WinRM would definitely work.

All of that is moot for you though. You don't have admin access to the machine at all. Therefore, you cannot make any of the changes necessary to get this going. You need to work this out with your sysadmin instead of asking us to help you go around him. Remember one thing very clearly, most of us here are sysadmins and we do not like users trying to go around us. That doesn't make us very likely to help you try to go around your sysadmins.

Jason Berg
  • 19,334