Hi.
Could somebody kindly tell how I can examine remote installation of Webroot SecureAnywhere immediately upon install command issued?
I found some articles that mention deployment via GPO but I'd like to confirm how to install Webroot SecureAnywhere via command line safely.
I am thinking of its temporary use on the security incident handling.
Using PSEXEC, it can be but thinking its wiretappable nature, it's not the way. # And I actually failed to do that.
I wish such a batch file makes sense...
---
set user=daifukudomain_admin
* SNIP *
%serial%.exe -proxyhost=%proxyIP% -proxyauth=0 -proxyuser=%user% -proxypass=%passwd% -proxyport=8080 -target=%targetIP1% /lang=ja /silent
----
Now I am under its trial with only a few days rest but seems to be extend its term.
Thank you for your attntion.
Seiya,
+6Seiya
I guess this is what you are looking for partly
Read this first and then possibly consider the use of Powershell over dos batch files as there you can send the password as a secure string which is safer then sending it as clear text.
It's the way i do it whenever i'm required to send a password via a script. In general i store the password in a text file on a thumb drive i carry on me at all time. That text file only contains the password and only i know what the purpose of that text file is as neither the name or the contents of the text file indicate the purpose of the string that's in the text file. that way when the thumb drive is lost nobody knows the purpose of the text file on the thumb drive...
The principle behind it is as follows ( it's but a sample but the basics can be adapted to suit your needs
$username="TheElevatedAccountYouAreLookingFor"$password= (get-content c: empedwin.txt)$sec_password = convertto-securestring $password -asplaintext -force$Credentials = New-Object System.Management.Automation.PSCredential ` -ArgumentList $UserName, $sec_passwordThen in the code to trigger the remote install specify the credentials as parameter -credential with as variable $credentials
new-psdrive -name PsDrive -psprovider FileSystem -root \Server01Public -credential $credentials
Hope the code doesn't scare you but i felt the need to specify it since we are talking about admin credentials. Instead of using the real domain admin creds i'd use a lesser privileged account that's only local admin on the workstations. Then if the worst case scenario would happen then they only compromise the local admin act and that's less evil then a compromised domain admin account.
I guess this is what you are looking for partly
Read this first and then possibly consider the use of Powershell over dos batch files as there you can send the password as a secure string which is safer then sending it as clear text.
It's the way i do it whenever i'm required to send a password via a script. In general i store the password in a text file on a thumb drive i carry on me at all time. That text file only contains the password and only i know what the purpose of that text file is as neither the name or the contents of the text file indicate the purpose of the string that's in the text file. that way when the thumb drive is lost nobody knows the purpose of the text file on the thumb drive...
The principle behind it is as follows ( it's but a sample but the basics can be adapted to suit your needs
$username="TheElevatedAccountYouAreLookingFor"$password= (get-content c: empedwin.txt)$sec_password = convertto-securestring $password -asplaintext -force$Credentials = New-Object System.Management.Automation.PSCredential ` -ArgumentList $UserName, $sec_passwordThen in the code to trigger the remote install specify the credentials as parameter -credential with as variable $credentials
new-psdrive -name PsDrive -psprovider FileSystem -root \Server01Public -credential $credentials
Hope the code doesn't scare you but i felt the need to specify it since we are talking about admin credentials. Instead of using the real domain admin creds i'd use a lesser privileged account that's only local admin on the workstations. Then if the worst case scenario would happen then they only compromise the local admin act and that's less evil then a compromised domain admin account.
1 person likes this
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.