psexec - Execute program on a remote computer: Access denied. Meaning of parameters in command? [duplicate] - remote-access

While I'm using PSEXEC.exe getting 'Access denied' error for remote systems.
Any idea about how to solve this?

Hi i am placing here a summary from many sources online for various solutions to "access is denied" :
most information can be found here (including requirements needed) - sysinternal help
as someone mentioned add this reg key, and then restart the computer :
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system
/v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Read this knowledge base article to learn what this does and why it is
needed
Disable firewall (note - this will leave you with out any firewall
protection)
netsh advfirewall set allprofiles state off
if target user has a blank PW and you dont want to add one, run on target:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LimitBlankPasswordUse"=dword:00000000
This didnt work for me, but i have read it did for others in a few places,
on target execute:
Start -> Run -> secpol.msc -> Local Policies -> Security Options -> Network Access: Sharing > and security model for local accounts > Classic – local users authenticate as themselves
if already in 'Classic':
move to "Guest only - .." run from elevated command prompt gpupdate \force
move back to 'Classic - .." again run from elevated command prompt gpupdate \force
This one solved my issue:
run on target from elevated command prompt "net use" look at ouput chart and for shares listed in remote column there (i only deleted the disconnected ones - you can try them all) run "net use [remote path from before list] /delete" then run 'net use \target\Admin$ /user:[user name]' enter prompt password request (if empty PW just press enter), viola should work.

I just solved an identical symptom, by creating the registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy and setting it to 1. More details are available here.

This helped in my case:
cmdkey.exe /add:<targetname> /user:<username> /pass:<password>
psexec.exe \\<targetname> <remote_command>

PsExec has whatever access rights its launcher has. It runs under regular Windows access control. This means whoever launched PsExec (be it either you, the scheduler, a service etc.) does not have sufficient rights on the target machine, or the target machine is not configured correctly. The first things to do are:
Make sure the launcher of PsExec is familiar to the target machine, either via the domain or by having the same user and password defined locally on both machines.
Use command line arguments to specify a user that is known to the target machine (-u user -p password)
If this did not solve your problem, make sure the target machine meets the minimum requirements, specified here.

You can try the command
net use \\computername\ipc$ /user:adminname password
to get admin permissions on remote PC before use psexec.

I had the same problem. And after a hard work, I found a easy and full solution:
I use runas to run the script in a admin account
I use the -s parameter in psExec to run in a system account
Inside the PsExec, I login again with a admin account
You can use & to run multiples commands
Remember to replace [USERNAME], [PASSWORD], [COMPUTERNAME], [COMMAND1] and [COMMAND2] with the real values
The code looks like this:
runas /user:[USERNAME] "psexec -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2]"
If you whant to debug your script in the another machine, run the following template:
runas /user:[USERNAME] "psexec -i -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2] & pause"

Try setting this key on the target (remote) machine, and restart the machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
See: http://forum.sysinternals.com/topic10924.html and http://www.brandonmartinez.com/2013/04/24/resolve-access-is-denied-using-psexec-with-a-local-admin-account/

I just added "-с" parameter. It makes Psexec copy executable to remote machine. So it works without access errors.

I found Sophos kept placing psexec.exe into the Quarantine section. Once I authorized it, it ran fine.

I still use psexec, even on win 10. Replace the psexec.exe in the Windows 10's win32 folder with the older version to work -> I use version 2.11.0.0. The Windows 10 version I was using would only run .bat files as background/hidden process on the remote computer. Took a whole day to figure this out.
Adding the registry key from above to the remote computer helps as well:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

I found another reason PSEXEC (and other PS tools) fail - If something (...say, a virus or trojan) hides the Windows folder and/or its files, then PSEXEC will fail with an "Access is Denied" error, PSLIST will give the error "Processor performance object not found on " and you'll be left in the dark as to the reason.
You can RDP in; You can access the admin$ share; You can view the drive contents remotely, etc. etc., but there's no indication that file(s) or folder(s) being hidden is the reason.
I'll be posting this information on several pages that i was perusing yesterday while trying to determine the cause of this odd problem, so you might see this elsewhere verbatim - just thought I'd put the word out before anyone else pulled their hair out by the roots trying to understand why the performance counter has anything to do with PSEXEC running.

I had a case where AV was quarantining Psexec - had to disable On-access scanning

For anybody who may stumble upon this. There is a recent (Dec 2013) Security Update from Microsoft Windows on Windows 7 that is preventing remote execution.
See http://support.microsoft.com/kb/2893294/en-us
I uninstalled the Security Update by going to Control Panel\Programs\Programs and Features\Installed Updates
It worked right after that.

The following worked, but only after I upgraded PSEXEC to 2.1 from Microsoft.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001 See:
http://forum.sysinternals.com/topic10924.html
I had a slightly older version that didn't work. I used it to do some USMT work via Dell kace, worked a treat :)

On Windows Server 2012 R2 I had trouble to run from user account
psexec -u administrator -p password \\machinename -h -s -d -accepteula cmd.exe
But it works fine if you run without parameters -h -s. That's why I use this to solve my trouble:
psexec -accepteula -u administrator -p password \\machinename %PathToLocalUtils%\psexec.exe -h -s -d cmd.exe

I couldn't get access to remote machines unless I had UAC disabled.
That has to be done locally, either from control panel or running the following through cmd:
reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
While UAC is enabled, make sure you run cmd as administrator.

For a different command I decided to change the network from public to work.
After trying to use the psexec command again it worked again.
So to get psexec to work try to change your network type from public to work or home.

I tried a lot of way but I could not use psexec. It gives "Access denied". After I change the target user account type from Standard to Admin, I connected the machine via psexec.
I researched the reason why admin type account is required then I found this answer.
You can change target machine user account this way: Control Panel -> User Accounts -> Change Account Type. You must enter an admin account and password to change that account if you logged in standard account.
After that I logged in with this command: psexec \\remotepcname -u remoteusername -p remotepassword cmd

Tried all suggestions above, but still was unable to resolve the error. Finally once I made the below change, I could successfully run the PSexec command.
Turns out that when you have UAC enabled psexec does not work as supposed. We need to set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to 0 then psexec starts working as expected.

Related

PsExec - The file cannot be accessed by the system

I'm trying to execute a .bat File on a Server in a local network with psexec
I'm currently trying with this command:
.\PsExec.exe -i -u Administrator \\192.168.4.36 -s -d cmd.exe -c "Z:\NX_SystemSetup\test.bat"
The server has no password (it has no internet connection and is running a clean install of Windows Server 2016), so I'm currently not entering one, and when a password is asked I simply press enter, which seems to work. Also, the .bat File currently only opens notepad on execution.
When I enter this command, I get the message "The file cannot be acessed by the system"
I've tried executing it with powershell with administrator privileges (and also without, since I saw another user on Stackoverflow mention that it only worked for them that way) but to no success.
I'm guessing this is a privilege problem, since it "can't be accessed", which would indicate to me that the file was indeed found.
I used net share in a cmd and it says that C:\ on my server is shared.
The file I'm trying to copy is also not in any kind of restricted folder.
Any ideas what else I could try?
EDIT:
I have done a lot more troubleshooting.
On the Server, I went into the firewall settings and opened TCP Port 135 and 445 explicitly, since according to google, PsExec uses these.
Also on the Server, I opened Properties of the "windows" Folder in C: and added an admin$ share, where I gave everyone all rights to the folder (stupid ik but I'm desperate for this to work)
Also played around a bunch more with different commands. Not even .\PsExec.exe \\192.168.4.36 ipconfig seems to work. I still get the same error. "The file cannot be accessed by the system"
This is honestly maddening. There is no known documentation of this error on the internet. Searching explicitly for "File cannot be accessed" still only brings up results for "File cannot be found" and similar.
I'm surely just missing something obvious. Right?
EDIT 2
I also tried adding the domain name in front of the username. I checked the domain by using set user in cmd on the server.
.\PsExec.exe \\192.168.4.16 -u DomainName\Administrator -p ~ -c "C:\Users\UserName\Documents\Mellanox Update.bat"
-p ~
seems to work for the password, so I added that.
I also tried creating a shortcut of the .bat File, and executing it as Administrator, using it instead of the original .bat File. The error stays the same "The File cannot be accessed by the system"
As additional info, the PC I'm trying to send the command from has Windows 10, the Server is running Windows Server 2016
So, the reason for this specific error is as simple and as stupid as it gets.
Turns out I was using the wrong IP. The IP I was using is an IPMI Address, which does not allow for any traffic (other than IPMI related stuff)
I have not yet gotten it to work yet, since I've run into some different errors, but the original question/problem has been resolved.

Can you help me access Mac SMB share from Ubuntu using smbclient? (NT_STATUS_ACCESS_DENIED error)

I've been working on a file server product that uses smbcilent to transfer files between client computers and the server. It's been working great so far with our LAMP (Ubuntu) server and Windows machines.
I'm currently trying to expand the setup to include Mac's, but am having trouble with the server accessing the share on the Mac.
Here's my command and error (bracketed descriptions replace private info):
# smbclient //10.101.0.7/[share-file] -U [username]%[password] -c ls
WARNING: The "syslog" option is deprecated
NTLMSSP packet check failed due to short signature (0 bytes)!
NTLMSSP NTLM2 packet check failed due to invalid signature!
session setup failed: NT_STATUS_ACCESS_DENIED
Things I've tried:
✓ Accessing share using a Windows machine to ensure the share is setup properly - check! Works fine there.
✓ Invoking -S off or --signing=off in the command - no change.
✓ Just looking at the shares first using smbclient -L 10.101.0.7 -U [username]%[password] - same error.
✓ Googling for an answer - check! Several people with similar problems, but no working solutions so far.
The most promising thing I've see so far involves compiling smbclient 4.4 from sources and running that with no authentication (-U ""%""), but that seems like a temporary solution based on a bug rather than a solid plan that will work for a long time. (But I'll try that next if I can't find any better ideas...)
Thanks for reading and trying to help!
Try adding --option="ntlmssp_client:force_old_spnego = yes" to the smbclient command as suggested on the samba-technical mailing list.
For me, this now lists shares on a Mac OSX server:
smbclient -U$user%$password -L $mac_host --option="ntlmssp_client:force_old_spnego = yes"
For mounting, you may need to add the nounix,sec=ntlmssp options as in
sudo mount -t cifs //$mac_host/$share $mountpoint -o nounix,sec=ntlmssp,username=$user,password=$password
On recent versions of MacOS (e.g. Monterey) it is necessary to do several configuration steps to enable smb access from Linux:
Open System Preferences.
Select Sharing.
Select File Sharing.
Ensure that the directory is listed in Shared Folders.
Right-click/two-finger click on the share directory.
Click on Advanced Options
Ensure Only allow SMB encrypted connections is checked.
Click OK
Click on Options
Click on the checkbox for Share files and folders using SMB.
Under Windows File Sharing ensure the appropriate user is checked.
Type the user's password in the 'Authenticate' dialog bo and press 'OK'.
Click 'Done'.
You should now be able to connect from Linux to the MacOS share using the commands given by #mivk.

Remotely Changing permissions of file pushed to W7 machine using smbclient

I have a file that I want to transfer to a remote machine that is running W7 32 bit
I have a script that enables me to push the file to the machine from a linux management server, using a combination of:
1) smbclient to mount the Admin share on the W7 machine
2) winexe to move the file to the location I require
This leaves me with the file in the correct location, but owned by the Admin user - whereas I need it to be editable by a standard user, User1
I have been trying to resolve this by using icacls
Using winexe I can run this remotely on the W7 machine. Initially I tried setting the poermissions to "Full" for the user account:
icacls c:......\myFile /grant User1:F
Checking this from the command line showed that it had apparently worked:
icacls c:......\myFile
c:......\myFile User1:(F)
However, from the windoes desktop, the file properties dialogue showed User1 having only read permissions, and anything else gave access denied.
My next attempt was:
icacls c:......\myFile /setowner User1
However, when logged in to the windows desktop as User1, attempting to delete or edit the file now tells me that doing so requires permission from User1....which is a bit peverse, since I am logged in as User1....
Any ideas?
This may or may not help, but I was unable to delete a file I copied from a Linux machine to a Windows shared folder - was getting a 'need Administrator permission' type error.
I was trying to solve this with the smbclient -c "setmode -r;" option, but when this didn't work I realised the Windows folder itself was set for read-only access for all but Administrator level.

Can't run PSExec using NETWORK SERVICE account

I am using TFS to kick off PSExec to run an InstallShield process that creates installers. Our TFS build agent runs under the NETWORK SERVICE account.
I run PSExec using the -u -p options, and I am able to run the command and successfully build the installers from a command prompt against the remote machine.
However in TFS, I always get a 2250 error code and the installers don't build.
To isolate the problem, I changed the psexec command to the following...
PsExec.exe -accepteula \\<machine> -u <username> -p <password> xcopy /y c:\temp\testing.bat c:\temp\1.bat
If I run the above from the command line it copies the file. If I run the above from TFS (calling out to the above in a batch file), it fails with 2250.
So to simulate what TFS is doing I...
Started a command prompt with elevated Admin privileges
Issued psexec -i -u "nt authority\network service" cmd.exe
Ran the batch file containing the above xcopy command
So step 2 starts a command prompt using the NETWORK SERVICE account. When I run step 3 from this command prompt, I received the same 2250 error. So this is good b/c now TFS is out of the picture, and I am closer to the real issue.
Just for grins I added NETWORK SERVICE to the remote box's Administrators group. That did not solve the issue.
So here is where I am at...
If I login to the TFS box using a login in the Administrator group, open a command prompt, and run the xcopy command batch file with the -u -p parameters, everything works fine.
If I start a cmd prompt with the NETWORK SERVICE account and run the same batch file as in step 1 I get a 2250 access denied.
So in my mind the issue is clearly related to the NETWORK SERVICE account. Question is how can I get psexec to run with this account?
UPDATE
Here are the dialogs that show the NETWORK_SERVICE account in the Administrators group for and that it has full access to the path (c:\temp).
Let's say your two machines are called TFSSERVER and TARGETMACHINE.
The NetworkService on the TFS Server would be seen as the machine account, i.e. DOMAIN\TFSSERVER$, on the TARGETMACHINE. Any accounts in the NT AUTHORITY group are local accounts so it looks like you've just added TARGETMACHINE's network service as an admin, not the TFS machine's network service.
Try adding the TFS machine account to your permissions list and see if it works.
If that doesn't, look at this related question and see if anything there helps you at all: PSEXEC, access denied errors

Using Psexec with Windows Server 2003

I'm trying to run a psexec command to a remote Windows Server 2003 machine. I run the following command:
psexec \machinename perfmon.msc -u machineadmin -p adminpassword -i -s
The -i and -s flags will allow me to run the GUI for perfmon.msc on the remote machine's desktop interactively.
I get the following error when I try to run the above command:
Couldn't Access machinename
Access denied
I'm using psexec version 1.94 and I'm certain that the machinename, user, and password are correct. Does anyone know if there are known issues with psexec on Windows Server 2003 and whether or not there is a fix?
[This question would be better fit for ServerFault.com, but nevertheless...]
A few suggestions:
Use two slashes before the machinename e.g. \\machinename (maybe that's what you meant the StackOverflow escaped the backslash)
*.MSC files are not usually directly executable remotely--you'll want to give the path to "c:\WINDOWS\system32\mmc.exe" and then the parameters
All parameters for psexec should go before the remote program and its parameters.
Is there really a reason to run the process as the System account ('-s') instead of just Administrator?
All together, it should look something like this:
psexec \\machinename -i -u machineadmin -p adminpassword "c:\WINDOWS\system32\mmc.exe" "perfmon.msc"
Are you connecting as an admin to the remote machine? The error says 'access denied'. You may not have the necessary privileges. Try connecting as an admin.

Resources