Secret, REST API, and Dynamic targeting

I have an fixlet that I created that uses a secure parameter (password for REST API user), but I can’t seem to target dynamically when I take action. I assume this is some sort of security feature? Has anyone else seen this?

I will try to generate this action using the API itself, but not sure that will work.

Any ideas on how to get around this?

Dynamic targeting has an action that ends up in the actionsite of the user. If you use secure parameters this MUST be a mailbox action and thus targeted directly which means picking the endpoints so that the system can encrypt the parameters to the specific endpoints.

No, you can’t get around this as this would mean breaking the security of the encryption.

Ok… is there any secure way to do what i’m doing? I’m trying to have an endpoint to create a custom action, so I need to use the restapi to send a query and then add the action.

Can you provide some more details? Why does the action have to be targeted dynamically in this case?

Sure. One of the issues we have right now is we have multiple different build methods/images. We want to make sure after we build a server that it is fully patched.

For that I made a task which will make a multiple action group of patches needed on that server… basically skipping the baseline creation. All of this is based off a reg key we add to those new servers, so I want this task to run on any server that has that reg key.

It doesn’t really have to be targeted dynamically, but I just need some way to kick it off automatically on those machines.

1 Like

This is possible, but not in an officially IBM supported way. Several years ago I took the original premise of the Local Admin Bigfix Labs tool and adapted it for precisely this purpose. My use case is to dynamically target machines that may or may not yet exist with certain secure bits of information such as passwords. I’ve targeted thousands of machines dynamically for a while now. I just wish IBM would incorporate the use case into the official product.

See this post for more details as well as the last post in this thread.

This would be the solution. Have something watch for new machines and then generate the patching baseline / multi action group for that machine(s) and target it specifically instead of dynamically.

You don’t actually need to use secure parameters at all since you can have something running elsewhere that actually uses the credentials that are used to create the baseline/multi action group. You could also use a secure parameter that is targeted at a top level relay or something like that who’s job it is to generate the baseline / multi action groups and not have the server that needs the patches responsible for that. This way the action that makes the multi action groups can be targeted specifically but the resulting multi action group can be targeted any way you want.

Ahh ok… so I can make a 2nd task on a utility type server to run every 30-60 mins. That task is just "if there are any relevant servers for the task above… take action on those. I’ll have my security because it’s a secure parameter on a known server, yet it will be pseudo “dynamic” because I can target new systems.

Ty! will try this.

1 Like

It wouldn’t be automated, but you could also have a console dashboard that could be used to trigger deployments if the right conditions are met with dynamic content but it would have the advantage of using a user’s existing console session, no need to embed creds anywhere.

You can tell if a computer is new based upon minima of subscribe times of sites and tag systems after they have completed initial provisioning.

@jgstew and @JonL thanks much for the help!

I’d like to look more into the OpenSSL item as I’m not too familiar with it. The way I “automated” it now is:

  • I created a “dummy” task (could have made just a property) to identify servers that are tagged as needing post build patching.
  • I then created a powershell script on another server that runs every 15 mins and looks servers that reported in the last 2 hours for the task, but don’t already have an open action (based on how I name it).
  • The script creates the “patching action” with a few API calls, writes out a property formatted XML action, then imports it, targetting the server via mailboxsite.

Thanks both for the help/ideas!

1 Like