I have a custom fixlet that uses the secret parameters in the fixlet XML that allows the operator to push credentials to a endpoint (Secure Parameters). I think the secret parameters are used so that the password is not stored on the relays. Is this correct?
When I push the fixlet, the only targeting options are by selecting the host or entering in the hostnames. Is this because it uses the client’s mailbox site and that is how the Relays don’t store the fixlet’s inputs? The downside is I can’t target by retrieved property so when I need to push the fixlet to 10’s of thousands of clients, it is very inefficient for the BF infrastructure. Is there any other way to get around that?
@cstoneba – Targeting options are limited as parameter gets encrypted individually for each computer using its public key on the root server. in this way it can only be decrypted by the agent.
Pushing to 10k computers would not be recommended as it’s not efficient. Are you able to elaborate on the use case maybe? Or its frequency?
2 Likes
@jtavan may be able to elaborate on a custom solution he’s posted about here, which involves managing your own set of encryption keys that you deploy to clients.
The lack of dynamic targeting for secure parameters is indeed a limitation in the architecture - because we separately encrypt the parameters for each specific targeted endpoint, we need to have that endpoint’s public key available when we create the action. We can’t predict what some other client’s individual public key might be when it becomes relevant in the future.
2 Likes
When we deploy a tool to rotate local admin passwords, we run it locally on the clients, so there’s no need to pass the credential through BigFix in a secure parameter. We push a public key to the system, rotate the password with a simple tool which also encrypts the password with the public key, and store the encrypted blob in a text file that gets read in to BigFix for escrow.
If I had to generate some sort of per-system-unique credentials centrally and distribute them to BigFix clients without exposing the credentials to the relays, I’d probably stand up a simple web service (maybe using Hashicorp Vault?) which mapped client certificates to their credentials, then have BigFix trigger a fetch of the credentials using mutual TLS authentication to the web service (using curl or Powershell) to obtain the unique credential per client. This keeps the credential transfer out of band for BigFix. But I’ve never had to do this.
1 Like
Yes, that’s an alternative I’m thinking about too.