(imported comment written by Andrew_TEM)
Bringing back up an old topic here.
How have the improvements made in v9 with Client Mailboxing affect the above scenarios with changing passwords via fixlets in Endpoint Manager?
(imported comment written by JonLandis)
It is possible to use the OpenSSL bits that the Local User Management installs to transport encrypted passwords and pipe them into an actionscript similar to the way Local User Management works. The difference is that the encrypted passwords or data can be used for any purpose, not just an OS user password changes. Another advantage of using OpenSSL directly is that if you are targeting a large amount of endpoints with a single password, it only needs to be encrypted once (assuming you have already distributed the other half of the key pair to your environment). If you did the same thing with Local User Management, it would have to encrypt separately to each endpoint, potentially bogging down your central server if you are sending to a large number of endpoints.
The real fun is combining OpenSSL-encrypted bits with relevance substitution of client-specific bits. You can create a combination of what you have and what you know. Security folks seem to love this approach.
(imported comment written by jgstew)
We are using tasks that make use of client mailboxing and secure parameters to change passwords on client systems.
(imported comment written by jgstew)
A colleague of mine is going to upload our tasks for Win/Mac/Linux to
http://bigfix.me/
(imported comment written by jgstew)
The use of Secure Parameters require that the Root server & targeted client are v9 or greater. I do not know if the relays must also be v9 or above or not, but I presume so.
This will not work well in Baselines, and you must target machines directly. You cannot target “All Computers” or an Automatic Group, but you can manually select all computers that are currently in an Automatic Group. The reason that this does not work is due to the fact that the secure parameter is encrypted at the time of “Take Action” for each client and never passed as clear text anywhere until it reaches the destination client. The Secure Parameters will not show up in log files, or in the console, so they break the strict auditing of BigFix/TEM/IEM, which would be an issue if you had actionscript that was “waithidden {parameter “secret” of action}” because a “bad actor” admin could do anything without it being logged or audited. Even with the examples provided, you might be able to enter a password, end it with a semicolon, then add any command you want to run on the client. (I have not verified this theoretical issue)
Examples of changing passwords on the local system using secure parameters:
http://bigfix.me/fixlet/details/3666
http://bigfix.me/fixlet/details/3667
The “secret” to “secure parameters” is the following embedded in the description of the task/fixlet:
<p>
<label for="secret">Secure Parameter:</label>
<input id="secret" type="password" name="secret" />
<script>
document.body.ontakeaction = function() {
var theSecret = document.getElementById("secret").value;
if (theSecret==null || theSecret=="")
{
alert("Hey, you forgot to enter a secure parameter! Please enter one on the Description tab before taking the action.");
}
else
{
TakeSecureFixletAction( Relevance('id of current fixlet'), Relevance('id of current bes site'),"Action1", {}, { secret: theSecret } );
}
return false;
}
</script>
</p>(imported comment written by Andrew_TEM)
Awesome! So I’m new to client mailboxing, can you explain how the password parameter in the description is actually securing the password string and passing it to the action and then ultimately to the endpoint?
(imported comment written by jgstew)
I have no idea how it actually works, that is better answered by IBM.
My best guess:
The description is using HTML & JavaScript.
- You enter the secret in the input box. (HTML)
- The JavaScript grabs the secret and stores it in “var theSecret”
- If the value stored in “var theSecret” is not null and is not empty string, then the JavaScript Function “TakeSecureFixletAction” is called. The last part of this function “secret: theSecret” seems to be where the value entered into the input box gets sent along to this function as plaintext.
- I don’t know exactly the details from there, but I believe this function causes the secret to be encrypted with the target client’s public key and then passed along with the actionscript to the client.
- I then believe that the client decrypts the secret and replaces “{parameter “secret” of action}” with the unencrypted secret, but knows not to log it. The name of the parameter to be used in the actionscript appears to be defined in the left hand operator of this “secret: theSecret” in the call to “TakeSecureFixletAction”.
We were sent an example task by IBM that used a secret parameter and adapted it for this use, while also adding validation to prevent someone from taking action without entering anything in the input box.
(imported comment written by Andrew_TEM)
Pretty cool synopsis.
Anyone having an issue downloading the bes file from here?
http://bigfix.me/fixlet/details/3666
I cannot grab it.
(imported comment written by jgstew)
It is not just you, I cannot download it either. I think this is because it was uploaded, deleted, tweaked, then reuploaded… all probably with the same file name. Definitely something wrong on the bigfix.me side of things.
(imported comment written by jgstew)
Well, I just uploaded this one new, and it is also having issues:
http://bigfix.me/fixlet/details/3668
I think this is just something wrong on the bigfix.me server. I have attached the Linux version of this task which can be easily adapted to do anything just by changing the actionscript.
(imported comment written by Andrew_TEM)
So what about a recovery model?
Scenario:
10 server admins responsible for 100 servers each.
Not allowed to have shared passwords for compliance reasons, so each admin is responsible for his built-in admin password.
Say an admin is let go and the next admin takes over his servers, but at the same time a network outage occurs and we loose network and domain connectivity. Short of an ERD disk to reset the built-in admin password, is there a way to maintain a password repository based on certificates?
(imported comment written by jgstew)
You might be able to implement something like that, but I have no clue. That was not the purpose of this task, particularly since we do not use BigFix/IEM on servers typically.
(imported comment written by brolly33)
New, working link for the 3666 fixlet is
http://bigfix.me/fixlet/details/3670
New working link for the 3667 fixlet is
http://bigfix.me/fixlet/details/3671
You must log in to download the .bes files.
3668 throws an error - looks like it is unhappy about the relevance entry - I don’t think I can fix that one - can we delete it aned use 3671?
(imported comment written by jgstew)
This is working now:
http://bigfix.me/fixlet/details/3673
I took out the success criteria of "exit code
of
action
!=
0"
(imported comment written by brolly33)
I just uploaded a variation.
http://bigfix.me/fixlet/details/3679
It shows syntax for more than one secret and talks about hardcoding the secret in the console for use in baselines (not secure in the console, but secure downstream)
1 Like
Ok, so here’s a question, I have downloaded the task, and am all set to use it. But because of some special security items. We want to have it automatically include a field/value specific to that machine. Ie the last 6 numbers of it’s ip. So it would be our “Secretpassword110004"
But since the secret password if I understand it correctly is set before it runs how do I add my extra characters without them being written to a log?
net.exe” user {parameter “username” of action} {parameter “secret” of action}&(address of it, mac address of it ) of adapters whose ( loopback of it = false AND address of it != “0.0.0.0” AND address of it as string does not start with “193.”) of network
Hitting an old post doesn’t always help, but nothing is logged by default anywhere when there is a secure parameter in the action. This is to hide any usage of the parameter. The parameter remains encrypted until usage.