Securely creating fixlets to update OS user passwords

Details are in this thread: Where to find API Logs?

Just to follow up on this thread, the bugs I hit were related to IEM issues in the way it processes the Action. The XSD says the action supports both computer ID and computer name, but if you are using a secure parameter, IEM only supports using the computer ID. Also for the source fixlet site name, it only accepts the actual text name of the site and not the site URI that uniquely identifies the site which is what is commonly used by the API.

Some explanation:

It is also true that when using the console, an action using a secure parameter can only be taken by selecting the machines specifically. This is so that the console knows the computerID at the time the action is taken so that the ID can be used. This is because the secure parameter is encrypted with the client’s public key when the action is taken so that it is always encrypted all the way.

When actions are taken using the computer name, it is actually using relevance to determine the correct endpoints to run against, which doesn’t work when you have to know that ahead of time.

1 Like

To me that just screams implementation bug as the XSD specifically allows the use of computer name there and if it requires the ID for secure paramaters it should be capable of doing that translation internally.

1 Like

If you want to pass encrypted content to a group of machines (even including machines that have not yet been created), you can do so with a shared key pair (which is in addition to the machine’s unique pair). See my post on 12/14 for more details. It does require some planning and OpenSSL expertise. It is not native IBM code (but very similar to the way the original Local User dashboard functions), but it does work very well. It is particularly useful for ‘role-based’ machines that are uniform in function.

This way you encrypt your content destined for a group of machines once, not hundreds or thousands of times based on your list of targets. This saves overhead on your server.

In this fashion, you could, for example, set a local administrator password on a whole group of machines. For extra fun, try static & dynamic combination passwords using relevance substitution. What you have and what you know. Security folks love this. :wink:

3 Likes

That is true, it really should be able to do that internally, but I think one issue is that the IDs are unique, while computer names are not, so that might be why that decision was made with the API. The console and webui would warn you before proceeding if there are duplicate computers, but the REST API can’t really do that.

I agree here, it should allow both.

Link?

See my alternative non-IBM supported but more flexible approach for securing passwords further up in this post on 12/14.

1 Like