I read this from a posting in the Windows SysInternals forum.
The HKCU - hive key current user - will point to that user's hive key who authenticated on the remote machine with the help of psexec. It will not point to the user's hive key who has logged on interactively to the machine's desktop, unless both accounts happen to be identical.
I am facing the same problem with trying to push the signer and cert associated with a self signed certificate to the HKEY_CURRENT_USER/Software/Microsoft/SystemCertificates/Root/Certificates folder in the Windows registry for the user signed onto the remote machine.
If the userid and password used with PsExec are the same as the user currently logged onto the remote machine everything works fine. The PKCU registry entries get added as expected.
Since we can't ask each end-user for their AD password I am trying to sort out how I can get this to work when both accounts aren't identical. I have a Windows service account that has admin rights on all the PCs in the domain I am trying to push the cert and signer out to. If I use that account with psexec the registry entries do not get added for the user logged onto the remote PC.
Is there any way I can I write to HKEY_CURRENT_USER using psexec when both accounts aren't identical? That is, when the account used with the psexec command is not the account that is currently logged onto the remote PC.
example:
User remoteuser is logged onto the remote PC on which we want to install the cert entry into the HKCU hive but we use a different user/account with psexec. We do this because we don't know the AD passwords for all the remote users we want to update the HKCU hive for.
That would be a serious security issue.
In this example we use the psexecuser account to start the psexec service on the remote PC that the AD user remoteuser is logged onto.
C:\psexec #C:\remoteUserPCList.txt -u ourdomain\psexecuser -p psececuserpassword -d -c -f C:\InstallSSLCertinHKCU.bat
The HKCU registry entries do not get added for the remoteuser account on the remote PC.
Any fixes that would work with psexec would be a great help. I suspect we could use AD GPO but I am hopeful that there is some trick out there that can be used with PsExec.
regards
psexec can't impersonate the logged-on user. But you don't need to push a self-signed certificate to the user's profile on the remote machine, you can push it to the computer account instead, and you can even do that with group policy.
Related
I need to use my local computer to simulate a test stand which will be on a domain and access a remote computer which is on a workgroup using PsExec. The testing computer is built from an imaging tool. The IP will be the same every time but the name isn't. The process I'm working with was used on an embedded XP system and is now being upgraded to WIN10. I've added network security using GPO and have found workarounds to be able to open the connection but for some reason just trying to run cmd on the remote machine does not work when using the IP, only the name. Using the IP returns the "access is denied" error. I have already added the token filter key to the registry. Has anyone heard of something like this before?
I have a script I'm trying to run but in the meantime I'm just trying to get
psexec \IP_ADDERESS -h -u USER_NAME(this is an admin) -p PASSWORD cmd
edit: I have to keep my computer on a domain but I have a spare that I was able to put on a workgroup with the test system. Running psexec went perfect. It makes no sense why it works for the name and not ip on a domain->workgroup connection and works exactly how I need it to on a workgroup->workgroup connection.
Need inputs to create a power shell script to run on remote machine to check whether local admin account exist on that machine
If yes report it to manage engine desktop central or send an email
Any ideas would be appreciated thanks in advance
I'm trying to start a remote desktop connection to a computer with a user that doesn't have a password, using Powershell. The cmdkey command does not seem to accept an empty password, but asks me for a password with a prompt.
I need to launch the remote desktop from a Powershell-script as it needs to connect to any of several computers at will, so saving the credentials to Remote desktop is not an option.
I have tried using stuff like "", $null, """", "^", ` but none of these work, they are either not a password at all, are the wrong password or just freeze the Powershell-script. The same exact code works just fine for an account that has a password on the same machine.
$username=
$IPAddress=
cmdkey /generic:$IPAddress /user:$username
mstsc /v:$IPAddress /admin
Start-Sleep -Seconds 1
cmdkey /delete:"LegacyGeneric:target=$IPAddress"
The script either asks for the password, or the remote desktop prompts for it, but then accepts just pressing "Ok" with an empty password, or the whole script freezes in some cases.
It should just connect as the empty password is correct.
Windows will not allow the logon over a network with a blank password. However, there is a registry setting you can do on the target machine that disables this behaviour:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LimitBlankPasswordUse"=dword:00000000
A 'cleaner' way to set this is by using the Group Policy Editor (gpedit.msc) on the target machine.
Navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and search for option Accounts: Limit local account use of blank passwords to console logon only
Double-click this option and check Disabled.
From then on, you should be able to remote log on to that computer with a blank password.
Note: this setting of course provides a security risk.
Read about Accounts: Limit local account use of blank passwords to console logon only
GOAL
Remotely access from a machine to another, using psexec, in order to start/stop a net service.
CONFIGURATION
Windows 10 Pro on both machines
PsExec v2.2
ISSUE
Couldn't access MACHINE_IP:
Access denied.
PREMISE
from now on, I'll refer to those machines as A and B
A is able to ping B
the accounts I used to accomplish that task are both administrators
WHAT I'VE TRIED
The first attempt was quite simple; so, from A, I ran:
psexec \\B_IP -u B_ADMIN_NAME -p B_ADMIN_PWD net stop SERVICE_NAME
but, as a result, I got the "Access denied" error.
Searching for the issue, I've found a lot of possible solutions but, unfortunately, noone worked for me. Here's what I tryied:
disable Windows Defender on A and B
disable User Account Control on A and B
uncheck "Use Sharing Wizard" from "Folder Options > View > Advanced Settings" on A and B
add the new DWORD (32-bit) LocalAccountTokenFilterPolicy (set to 1) inside "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" on A and B
save credetials before execute psexec using cmdkey.exe /add:B_IP /user:B_IP\B_ADMIN_NAME /pass:B_ADMIN_PWD
try to get admin permissions on remote PC before using psexec with net use \\B_IP\ipc$ /user:B_ADMIN_NAME B_ADMIN_PWD
try to run psexec as administrator using runas /user:B_ADMIN_NAME "psexec -e -h -s -u B_ADMIN_NAME -p B_ADMIN_PWD \\B_IP cmd /C net stop SERVICE_NAME"
Another strange thing is that A cannot access to B via filesharing.
To be precise, it can access to \\B_IP but not to \\B_IP\C$ nor \\B_IP\ADMIN$.
I think those two issues (access denied with psexec and filesharing) are somehow related but, as I said, noone of the previous solutions worked for me.
Any other ideas would be very appreciated.
Thanks.
IIRC the admin$ share uses SMB1/CIFS which 1709 or 1803 automatically disabled because MS considers SMB1 not secure enough.
(If you're using a samba server and your windows client cannot access network shares anymore after upgrading to one of these versions, the answer below should also work for you)
It has to be manually reactivated through "turn windows features on or off"
full name : SMB 1.0/CIFS File Sharing Support.
Be aware that this feature contains both client and server, be sure to expand the feature's tree to check if you correctly install the one you need (server for psexec, client for network shares)
First, my teammate is successfully deploying on almost exactly the same setup and using the exact same config as me re deploy. Therefore, cannot be a deploy configuration issue, there is nothing local or unique to any of our machines.
Second, I can successfully login via my machine using ssh user#server.com without password prompt.
However, I have tried everything to stop capistrano asking this question:
--recursive; fi"
servers: ["myserver.com"]
Password:
* [deploy:update_code] rolling back
I have tried every single password I have, and not entering a password. I don't even know what this password is for. Is it SSH? Because I don't even have a password protected key file.
I'm totally lost and I've literally been debugging this for 5 hours now without a single change in status. I'd really appreciate some help on how I can find out what the problem is.
Note, cap deploy simply works for my teammate using same config, same server. Everything, except different key file (note mine works and tested via ssh command).
Do you have to specify user#server.com to SSH to your server successfully (i.e., do you have a different username on your remote server from your local machine)?
You might just need to tell Capistrano what username it should be using to connect with by adding it to your deploy.rb:
set :user, "your-username"
You could also change the default username SSH will pick for that server by using ~/.ssh/config:
Host your.server.name
User your-username