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.
I am trying to open Matlab software installed in remote Linux server from my Windows 7 PC. I am using SSH secure shell to connect with the Linux server. After successful connection, I am able to see and access the folders under my user account. I am able to start Matlab software using the following command in the SSH secure shell window:
[sushma#scorpio home]$ matlab
On doing so the following message gets displayed on the SSH secure shell window:
MATLAB is selecting SOFTWARE OPENGL rendering.
No protocol specified
< M A T L A B (R) >
Copyright 1984-2015 The MathWorks, Inc.
R2015b (8.6.0.267246) 64-bit (glnxa64)
August 20, 2015
From the above message it seems that the software is running. I want to access the GUI of the software.
Give a try to ssh -X
From ssh manual:
-X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for
the user's X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh
-Y option and the ForwardX11Trusted directive in ssh_config(5) for more
information.
-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.
steps that worked for me:
connect to the server by using the ssh -X flag
execute Matlab with matlab & (you should see Matlab opening on your local machine)
check within Matlab with the command opengl info if either software or hardware opengl is being used (if you're having trouble loading opengl go to step 2 and execute matlab -softwareopengl &)
run your gui script with run <script>
If the script is supposed to run independent of your ssh connection, I suggest to use the program tmux and repeat step 2-4 inside a tmux session
I am trying to use putty and XMing to run programs from my Fedora 20. I used this configuration before on other machines and I was able to run GUI programs on Linux and display them in my windows 7. But this time I have trouble and get the "cannot connect to X server" error when I try to launch kwrite and kdesvn which are GUI programs in Fedora 20. The connections were good. And the XMing server was running and the X11 forwarding was enabled in putty, like the instruction here.
From my another Fedora 20 machine, I was able to connect to and run GUI programs from the target machine with ssh -X and the same username. So I am thinking the settings of the target machine was right.
Then what else I can try? how to figure out where the problem is?
Ensure that X11 forwarding is enabled in /etc/sshd_config.
X11Forwarding yes
Ensure in your home directory that you have an .Xauthority file. Permissions should be set 0600. If the file does not exist create it.
touch ~/.Xauthority
chmod 0600 ~/.Xauthority
As was previous stated first make sure that X11 forwarding is enabled in PuTTY.
Config > Connection > SSH > X11 > Enable X11 Forwarding. Based on your question it appears you already did this. Make sure you save this config.
I had a problem much like this, what happened to me was that my DISPLAY was being set elsewhere. If you can, try opening a new settion via putty from the same Windows machine using another user and then checking the display and testing your GUI programs
Another thing would be to use your own user but remove any custom work you may have done in your configuration, login fresh, check the DISPLAY and then test X
Did you enable X11 in putty?
It's under SSH | X11 | Enable X11 Forwarding
Then save the putty profile and click on session | save | open
Should work perfectly after you make those changes.
I am trying to execute a bat file on remote windows machine on cloud from my Linux. The bat files starts selenium server and then my selenium tests are run. I am not able to start selenium RC server on that machine. I tried with Telnet but the problem with it is when telnet session is closed the RC server port is also closed. As my code my code has to start the server so I tried with ANT telnet task and also executed shell script of telnet in both ways the port was closed.
I read about Open SSH, psexec for linux and cygwin. But i am not getting how to use these and will they will solve my problem.
I have tried to start a service which will start the server but in this method i am not getting browser visible all tests are running in background as my script takes screen shot browser visibility is must.
Now my Question is what to use and which will be preferable for my job.
and what ever i choose should be executed by code it may be by shell, ant or php.
Thanks in advance.
Let's go through the various options you mentioned:
psexec: This is pretty much a PC only thing. Plus, you must make sure that newer Windows machines can get through the UAC that are setup by default. UAC is the thing you see all the time on Vista and Windows 7 when you try to do something that requires administrator's privileges. You can try something called winexe which is a Linux program that can do the psexec protocol, but I've had problems getting it to work.
OpenSSH: There are two main flavors of SSH, and Open SSH is the one used by the vast majority of sites. SSH has several advantages over other methods:
SSH is secure: Your network traffic is encrypted.
SSH can be password independent: You can setup SSH to use private/public keys. This way, you don't even have to know the password on the remote server. This makes it more secure since you don't have passwords being stored on various systems. And, in many Windows sites, passwords have to be changed every month or so or the account is locked.
SSH can do more than just execute remote commands: There are two sub-protocols on SSH called SCP and SFTP. These allow you to transfer files between two machines. Since they work over SSH, you get all of the advantages of SSH including encrypted packets, and public/private key protection.
SSH is well implemented in the Unix World: You'll find SSH clients built into Ant, Maven, and other build tools. Programs like CVS, Subversion, and Git can work over SSH connections too. Unfortunately, the Windows World operates in a different space time dimension. To use SSH on a Windows system requires third party software like Cygwin.
Cygwin: Cygwin is sort of an odd beast. It's a layer on top of Windows that allows many of the Unix/GNU libraries to work over Windows. It was originally developed to allow Unix developers to run their software on Windows DOS systems. However, Cygwin now contains a complete Unix like system including tools such as Perl and Python, BASH shell, and many utilities such as an SSH server. Since Cygwin is open source, you can download it for free and run SSH server. Unfortunately, I've had problems with Cygwin's SSH server. Another issue: If you're running programs remotely, you probably want to run them in a Windows environment and not the Cygwin environment.
I recommend that you look at WinSSHD from Bitvise. It's an OpenSSH implementation of the SSH Server, but it's not open source. It's about $100 per license and you need a license on each server. However, it's a robust implementation and has all of the features SSH has to offer.
You can look at CoSSH which is a package of Cygwin utilities and OpenSSH server. This is free and all open source, but if you want an easy way of setting it up, you have to pay for the Advanced Administrator Console. You don't need the Advanced Administrator Console since you can use Cygwin to set everything up, and it comes with a basic console to help.
I prefer to use cygwin and use SSH to then log in to the windows machine to execute commands. Be aware that, by default, cygwin doesn't have OpenSSH installed.
Once you have SSH working on the windows machine you can run a command on it from the Linux machine like this:
ssh user#windowsmachine 'mycommand.exe'
You can also set up ssh authentication keys so that you don't need to enter a password each time.
I've succeeded to run remote command on W2K3 via EXPECT on Debian Buster. Here is the script of mine:
#!/usr/bin/expect
#
# execute the script in the following manner:
#
# <script> <vindoze> <user> <password> <command>
#
#
set timeout 200
set hostname [lindex $argv 0]
set username [lindex $argv 1]
set password [lindex $argv 2]
set command [lindex $argv 3]
spawn telnet $hostname
expect "login:"
send "$username\r"
expect "password:"
send "$password\r"
expect "C:*"
send "dir c:\\tasks\\logs \r"
# send $command
expect "C:*"
send "exit\r\r\r"
Bear in mind that you need to enable TELNET service of the Win machine and also the user which you are authenticated with must be member of TelnetClients built-in Win group. Or as most of the Win LazyMins do - authenticate with Admin user ;)
I use similar "expect" script for automated collecting & backup configuration of CLI enabled network devices like Allied Telesyn, Cisco, Planet etc.
Cheers,
LAZA
Not a very secure way, but if you have a running webserver you can use PHP or ASP to trigger a system command. Just hide thgat script under www.myserver.com/02124309c9867a7616972f52a55db1b4.php or something. And make sure the command are fixed written in the code, not open via parameter ...
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.