However I am getting Relevance Substitution Failed everytime that I try and run it.
Snippet from log file on client:
=========================================
Relevant - Change local user account password - Windows (fixlet:4956)
At 15:28:46 +1000 -
ActionLogMessage: (action:4956) Action signature verified for Execution
ActionLogMessage: (action:4956) starting action
At 15:28:46 +1000 - actionsite (http://XXXXXXXXXX:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded action parameter query āusernameā with description āPlease specify the name of an existing local user accountā (action:4956)
Command failed (Relevance substitution failed) waithidden āC:\Windows\System32\net.exeā user {parameter āusernameā of action} {parameter āsecretā of action} (action:4956)
At 15:28:46 +1000 -
ActionLogMessage: (action:4956) ending action
Good catch. Iām not sure it that is the problem or not. I think this is a case where there is ONLY an action2 because I ended up deleting action1, but I could be wrong and that could be a part of the problem.
Didnāt want to revitalize this thread, but curious, what are the security parameters around this Fixlet? I understand the end-to-end encryption aspect so no one can intercept. But what about it being stored on the laptop itself? If someone had access to the laptop, would they be able to decrypt the password change fixlet of the local admin to gain access to that PW?
I know this is a very old thread, but I stumbled upon it when searching for a way to supply a secured password for a BIOS setting task. I donāt know anything about javascript so I just did some experimenting and got the piece of code to work.
The problem is that ā<>ā is not a valid comparator in javascript. Change it to ā!=ā and it runs fine.
@haraldk, the basic idea is to distribute the OpenSSL binaries in a consistent location across your clients. Create an OpenSSL key pair, securing half the pair, while distributing the other half to all your clients. Then when you encrypt a bit of data, say a password, with the secured half of the key pair, then your clients will be able to decrypt the secure value. Here is an excerpt of a prior thread that has some basics. Try it out and post if you get stuck.
Start with a current set of OpenSSL binaries for whichever OS(es) you plan to target. Create a task or add these to your image. Then set permissions to deny all but system for this location. (I like to use \OpenSSL under the client install folder.)
Create at least one key pair using OpenSSL adapting the parameters to your situation. For example, a 4096-bit RSA key pair can be created:
The encoded encrypted files can be deployed via Bigfix or inserted into an image. (I recommend a naming convention for these files.) This is essentially what early versions of Local User Management were doing under the covers. Today they embed OpenSSL libraries with the installs so it is more integrated into the product versus a bolt-on.