Does anyone know how could I installed the following silently ?
C:\> certutil -importpfx -user -f -p [Password] "O:\Certificates\test2.pfx"
I tried using the -silent option but it says it does not exist.
Any other recommendations ?
The certificate install is causing issues with our users, since they are unable to say yes to install it. A Citrix security box appears behind the certificate window which needs to be 'allowed' before they can install the certificate. Some users are able to drag the security warning from the back to the front, but the majority are unable to do so.
If anyone could help that would be great!
Thanks
This is by design, if you could silently install user certificates it would be a hefty security breach.
You could use a vbs script such as below to call your bat file during logon, this will install silently..
VBS SCRIPT
Set oShell = CreateObject ("Wscript.Shell") Dim strArgs strArgs = "cmd /c %LOGONSERVER%\netlogon\import-certificate.bat" oShell.Run strArgs, 0, false
BATCH SCRIPT
certutil -f -user -p "PASSWORD" -importpfx "%LOGONSERVER%\netlogon\CERTIFICATE.pfx" NoRoot
Related
I having a bunch of Linux Servers on which i need to run few commands to get the host file entry of backup servers. I am using planning to make power shell script using plink to achieve this . It logs me in the server but the commands does not execute. Below is Powershell console
$switch = "172.20.19.50"
$commands = "c:\scripts\cmd.txt"
$username = root
$pw = Read-Host -Prompt "Enter password" -AsSecureString
plink -ssh $switch -l $username -pw $pw -m $commands
output
bash: Support: command not found
bash: Maintenance: command not found
my c:\scripts\cmd.txt contains following two commands :
Support
Maintenance
is there anything in command i am missing here ? Also if anyone could suggest a better way to get the output from linux servers remotely will be great help . I just need to query few commands to get the output
In 99.999% of all cases, if a computer tells you it cannot find something, the reason is, that that something is, in fact, not there. So, are you 100% sure that those commands exist on your server?
In the remaining cases, the reason is, that the thing is there, but not in the right place. Are you 100% sure that those commands are in root's $PATH?
I made a script wich does the same (connect to UNIX machine and execute command using Powershell) and I had to make this:
echo y | & $Plinkpath -P 22 -v $User#$server -pw $passw "$commands $($target)"
Where $commands are:
/usr/local/bin/sudo /usr/sbin/userdel
Because sudo and userdel was not always in mi $PATH (as said Jörg W Mittag) i've to use the full path to the command.
Hope this works for you!
I have a problem, and the Internet doesn't seem to have a solution, so maybe someone here can help.
I'm trying to start a command-line prompt on a remote machine using PsExec, but I keep getting an "Access is Denied" error. Both my local and the remote machine are running Windows 7 Enterprise (local: x64, remote x86) and I'm using PsExec 1.98. I use the following command:
psexec \\remote -u domain\user -p password -i -d cmd.exe
I have also tried other commands (such as using -s, -h, etc.), it doesn't seem to make a difference. I have access to the admin$ share of the remote machine from my local one. The Event Viewer tells me that a logon (and logoff) occurs on the remote machine.
Also, PsExec creates the PSEXESVC.EXE in the windows directory, but does not delete it!
Interestingly, the same command works just fine on a Win-7-Professional (x64) and it also works perfectly fine in reverse (i.e. when executed from the remote machine to start cmd on the local one). Deactivating anti-virus and firewall on the remote machine did not make a difference. I cannot deactivate it on the local one, but I have my doubts that the error is caused there.
Does anyone have any ideas?
Bit late, I know, but I've just been trying to solve this too. Turns out it has to do with security levels / user access levels.
I was trying to run psexec from a command prompt on a local PC and had started the command prompt by right clicking and choosing "Run as administrator". Then I'd run the psexec command targetting a remote server and specify a domain admin account for the -u parameter.
However, my local account only had administrative privileges on the local machine, not the remote one and choosing "run as administrator" doesn't actually mean "run as domain administrator"! (Obviously, duh!).
So, in effect, what was happening was that it was trying to run my main command as a domain admin on the remote but the psexec part was being run as my (non-admin) domain user account - which didn't have the appropriate permissions on the server.
Solution: Instead of starting a command prompt as above use the runas command.
eg: Start -> Run -> runas /user:domain\administrator cmd
then run your psexec command and you won't need the -u flag
or, from inside a normal command prompt you could do this instead:
runas /user:domain\administrator "psexec \\remote cmd"
after trying everything and still not getting any good results I figured what was the issue at least in my case. I had a machine with logged in domain account(not domain admin but at least local to the machine admin) and few other machines that had local accounts with admin rights. Psexec worked on all of them but was not working on my machine using domain account with local admin rights. On the machine that psexec worked with the local admin account I logged in with my domain account with local admin rights - and to no surprise it did not work.
So bottom line is that you should start the psexec call to the remote server with admin account local to the machine that you are sending the call from.
Better yet just insert this before your psexec string which will go now in double quotes
runas /user: ""
this way psexec will run but using the local admin account and no need to actually log in with the local admin account
The only way which works for me was to set the network credentials:
cmdkey /list:%DOMAIN% | find "%DOMAIN_USER%" >NUL || cmdkey /add:%DOMAIN% /user:%DOMAIN%\%DOMAIN_USER% /pass:%DOMAIN_USER_PWD% >>%LOGFILE% 2>>&1
Runas was not possible with local shares and other permissions.
I know this is really late, however as it's the first search in Google I am going to reply.
Through much research I found that you need to have the username and password BEFORE the system name, so instead of:
psexec \\remote -u domain\user -p password -i -d cmd.exe
Do it this way:
psexec -u domain\user -p password -i -d \\remote cmd.exe
I wanted to install a program from a server share (the PC I'm working on, I was logged in as domain administrator) remotely on "RemotePC".
PsExec worked on RemotePC with "local" programs (local to "RemotePC") like cmd.exe:
PsExec.exe \\RemotePC cmd.exe
Initially, my full command looked like this:
PsExec.exe \\RemotePC "\\server\sharename\path to program\setup.exe" /s /v"/qn IP_SERVER=192.168.1.10 PORT=112 INSTALLDIR=\"%ProgramFiles(x86)%\path\ \" "
But the setup from the server share didn't start.
Error message:
PsExec could not start \\server\sharename\path to program\setup.exe on RemotePC
Access is denied
I tried much of the solutions I found here and on other websites like adding PsExec -u administrator -p password and using cmd.exe /c, but it didn't work.
Finally I found a working command (the /s with extra quotes around the commandline did the trick):
PsExec.exe \\RemotePC -u administrator -p AdminPassword cmd.exe /s /c " commandline "
The full working command looks like this:
PsExec.exe \\RemotePC -u administrator -p AdminPassword cmd.exe /s /c " "\\server\sharename\path to program\setup.exe" /s /v"/qn IP_SERVER=192.168.1.10 PORT=112 INSTALLDIR=\"%ProgramFiles(x86)%\path\ \" " "
I've been working on a Powershell script for a little while, which is designed to be used both by me personally (on my local machine) and by other people both in my domain and outside of it.
The problem is, when someone other than me tries to run the script, they're greeted with the following error:
The file C:\my_script.ps1 cannot be loaded. The execution of scripts is disabled on this system. Please see "Get-Help about_signing" for more details.
I thought I had taken care of this by changing the policy on the other employee's workstation to allow remotesigned within the script itself, but according to this link, I'll need something a bit more robust.
Since the idea is to allow this to run, self-contained, on both internal and external machines, I'd rather not force the script to change things to unrestricted. Are there other options? Could I wrap this up in some other way (one person recommended a .NET container) project or something to allow it to run cleaner and be more self-contained?
I'm not sure I understand your problem. You can use makecert on the machine where you wan't to execute the script:
#echo off
makecert -n "CN=PowerShell Local Certificate Root" -a sha1 -eku 1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer -ss Root -sr LocalMachine
pause
makecert -pe -n "CN=PowerShell User" -ss MY -a sha1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk -ic root.cer
then, sign your script:
$cert = #(Get-ChildItem cert:CurrentUser\My -codesigning)[0]
Set-AuthenticodeSignature <your script path> $cert | Out-Null
The "self containing" part shouldn't be a problem.
I'm trying to make a certificate for testing and I am using this site How to: Create Your Own Test Certificate as a tutorial on how to but when it comes time to enter in the password after you create the password it says failed in the command prompt why is that?
What I've done:
First, I open a command prompt and type in:
cd C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
Second, I type in
makecert -sv myPrivateKeyFile.pvk -n "TestCert" myCertFile.cer -b 01/01/2011 -e 01/01/2015 -r
Then I create the password then enter the password on the sencond pop up box and then it says failed in command prompt
When I enter in this again, the popup is asking for the password pops up first this time, and I enter it in and it says:
Error: CryptCertStrToNameW failed => 0x80092023 (-2146885597)
makecert -sv myPrivateKeyFile.pvk -n "TestCert" myCertFile.cer -b 01/01/2011 -e 01/01/2015 -r
I solved the problem by running the program as an administrator, but I had to change also the name of certificate in a LDAP style like this (CN=...):
makecert -sv myPrivateKeyFile.pvk -n "CN=TestCert" myCertFile.cer -b 01/01/2011 -e 01/01/2015 -r
This was a bit of a shotgun-debug for me. I started with this after reading the makecert guide:
makecert.exe /b 01/01/2014 /e 01/01/2114 /len 256 /m 1200 /n "CN=In-House-Software" /pe /r /sr localMachine Test_Cert.cer
There's two error-causing flaws here:
/e and /m likely are not supposed to overlap; seems kind of obvious, but they didn't document it or create an expressive error message for it.
/len 256 was an invalid value -- too low. This also didn't seem too obvious/documented/expressed in a good error message. 512 did work. I didn't bother finding the floor-value, but by default 1024 is used.
I ended up using this with success:
makecert.exe /b 01/01/2014 /e 01/01/2114 /len 512 /pe /r /n "CN=In-House-Software" /sr localMachine Test_Cert.cer
The reason why I was getting this error is, because I didn't right click on cmd when I ran it. So when you have this problem you need to right click on cmd and then run as administrator and see if that fixes your problem as it did mine.
I also received this error when I specified the CA name for a self-signed cert, in other words, if you specify the '-cy authority' and the '-r' options, then DON'T specify the CA name explicitly in the name via the -n option.
The issue was by the publisher name not starting with "CN=".
This fixed the issue, I didn't need to run as administrator.
For some reason I couldn't run makecert properly from Dropbox folders. So try moving it to a solid disk like C:\ and try again.
I have two XP machines and I have the following situation.
I am running psexec from comp1
comp2 does not have any password
My bat file command
psexec -i -d -c \\comp2 c:\xyz.exe
The error message I get is
Couldn't access comp2: Access Denied
I also added new user 'test' with password 'abcd' on comp2 and logged in then from comp1. I gave command
psexec -i -d -c \\comp2 -u test -p abcd c:\xyz.exe
but the error remains the same. Please help.
Are you using XP Home by chance? According to the Sysinternals Forums here, one of requirements for psexec is check the target machine to make sure it's not running Windows XP Home because it lacks the network functionality required by (most) PSTools commands. The issue with XP Home was also investigated in detail in this thread from the same forum.