You can always use the technique used in this fixlet …
You enter the password before you start the Action, and it obscures the password as you type it.
Yes there are. You may use a secure parameter for a serial number for a license key for a product. You don’t actually care that it be very secure, and being able to see it entered is helpful, but you might want it encrypted to the endpoint over the wire and not in the logs for a variety of reasons. There are other examples I’m sure.
The major issue that I’m experiencing is just the problem of presenting to other users how to use a fixlet or task that prompts for my password over screen sharing or over the shoulder or at a conference. Otherwise I don’t really mind it.
Also, I’m not aware of a way to use secure parameters other than through JavaScript embedded in the task/fixlet description. It seems like there should be an “action parameter query” that uses secure parameters like I suggested above.
@TimRice I am aware of that example fixlet and do use ones based on it in some cases, but I don’t find it ideal because it does not prompt the user for input. In some cases not prompting makes sense, but not in others. The best I can do for a work around is to use that example you linked and add validation so that input is required. Even so this is not an ideal option for something like a console operator password.
I agree that secure parameters should be presented to the user like other action parameter queries are, including an option to obstruct. It is confusing for operators to have to enter it in the description. I would also like to see a confirmation option. An issue I see is that because the password is being obstructed, it’s easy for someone to mistype it. There should be an option to require the operator to enter the password twice, if they don’t match then have them to try again prior to the action starting.
@jgstew You can prevent things from being logged using the following commands, regardless if you have secure parameters or not. I understand this doesn’t address your concern of having it encrypted though…
action log command - This causes only the command to be logged (i.e. wait, run, appendfile, etc.)
action log all - This re-enables normal logging
1 Like
I did recently stumble upon that option to log or not log things dynamically in actionscript. It is pretty rare that I don’t want things logged. Even when using secure parameters there are times where I’d like everything but that line logged.
Actually if there is a secure parameter in the action the action will automatically enter the action log command state so it doesn’t log anything that is “secure”
But I want it to do the opposite. I want it to log everything except for the command that uses the secure parameter.
You can override it with the action log all and action log command actionscript commands to show what you want 
1 Like
Hi,
Can some guide me that how we can take secure parameter in action ?
@jgstew … I have tried your given suggestion “action parameter query secure” but throwing an error.
I need to take password in action parameter… I saw couple suggestion like rest api or through modification of xml file of task but I want it through bigfix action parameter query.
I am using bigfix 9.0.853.0
Thanks
Niraj
@neerajmishra20feb the secure parameter needs to be defined before hand in the “Details” pane. The action then grabs it using the REST API. @jgstew has another thread where he points to a fixlet on bigfix.me that I’ve disected and used for deploying sercure parameters here. If you need to deploy a secure parameter, take the “Details” pane of this fixlet and apply it to your current one. That will allow you to use the REST API to enter a secure parameter into the action you’re deploying.
1 Like
To be clear, this is not a real thing:
action parameter query secure
That was just a suggestion to add something like the above as an easier way to use secure parameters.
Is there a solution to this that allows targeting automatic groups yet?
I don’t believe so, and that isn’t something that is technically possible and still maintain the security level.
It would be nice if there was an inbetween mode where the secure parameter would be encrypted in such a way so that the root server could read it and then the root would re-encrypt it for each computer it would run against when they are relevant.
The issue is that this would require some sort of extra protocol for the client to ask the root for that secure parameter because the way it works in the current architecture is that something targeting an automatic group is evaluated by all endpoints in the scope and they choose to run it based upon their evaluation of the relevance. It wouldn’t be possible to have a parameter be both secure and also available to all clients unless all clients get something encrypted just for them, which can’t really happen when targeting dynamically like an automatic group because they all get the same action.
I know this is an old thread and why I was looking to revive it if a new solution or workaround is available. I am using this fixlet Change local user account password to change passwords but it cannot be used dynamically, therefore difficult to track where it was run. I have added relevance to check for the password age to help identify new targets. I was thinking of using the “action parameter query” to enter the password, but understand this doesn’t hide the password nor encrypt it. I don’t care so much the password is visible while entering it because I can always copy/paste and it would be very brief. I am more concerned with it being exposed in the action, logs, etc. and easily retrieved by users.
1 Like
Rony,
The secure action parameters are still limited to static targeting for your actions. The mechanism uses the Client Mailbox for decryption, so the targets need to be “known” at the time the action is created in the console. Dynamic targeting does not know what endpoints will be targeted until after the action gets to the endpoint.
Yes, secure action parameters remain limiting. Overcoming these limitations is something that hopefully HCL takes seriously as it would be helpful to many folks.
My organization uses an OpenSSL-based approach that is a superset of the original Local User Management functionality offered in Bigfix Labs. While it isn’t officially supported and does that some legwork to get set up. It pays off by offering these benefits.
- Encrypt once to thousands of machines versus needing to spend root server cycles encrypting the same thing 1000s of times over uniquely for each client (in the client mailbox approach).
- Anything supported by OpenSSL encryption is fair game, not just limited to passwords. Keys, passphrases, files, licenses, etc.
- Target groups, not limited to specific individual machines.
- Target machines that are not yet created via dynamic groups and policy actions (very helpful in automated build scenarios).
HCL, are you listening? It would be HUGE to offer functionality like this natively within Bigfix. It is a common need across platforms and industries.
Discussion on this from a while back that still applies today is here.
This thread discusses some of the mechanics behind the approach.
2 Likes
This might be a good idea to pitch on the new HCL Ideas portal (our replacement for the IBM RFE tool)
https://bigfix-ideas.hcltechsw.com/ideas
1 Like
Thank you your input JonL and Brolly33. As a work around for now, I created a text file with a date when the password was updated. I then used relevance to query for that text file. This allowed me to determine which PCs remain. It is still not ideal but better than not knowing at all or keeping a separate list of computers.
So, each week you go into the BigFix console and target computers with your secure action based on the property that looks at the text file as a filter in the take action dialog. Clever.
I wonder if you could layer that into some automation with REST API queries.
1 Like
Thanks brolly33 for sharing the new HCL Ideas Portal!
If you are are in favor of improving secure action parameters to …
- Encrypt once to thousands of machines versus needing to spend root server cycles encrypting the same thing 1000s of times over uniquely for each client (in the client mailbox approach).
- Encrypt anything, not just limited to passwords. Think keys, passphrases, files, licenses, etc.
- Ability to target groups, not limited to specific individual machines.
- Ability to target machines that are not yet created via dynamic groups and policy actions (very helpful in automated build scenarios).
1 Like
It would be useful if we had better examples of how to do this. Would be helpful if you could provide any. Any encryption done with a secret that is shared among many possible clients is always going to be less secure than a solution that is endpoint specific, but sometimes that is an acceptable risk. One potential option would be to manage this through site subscription and site files, in which you have access to the decryption key by syncing the site to the endpoint. Ideally even in this case it would be best if there was a hard coded password that was required in addition to the private key file in the site.
You can do a lot with custom use of OpenSSL, but it would also be interesting if there was an easy way to encrypt arbitrary data on the endpoint using the masthead public key such that it could only be decrypted with the root server private key. I’ve looked into this a few times but never really got anywhere.
Another option is encrypt data with the Client public key such that it can only be decrypted with the Client private key.