RE: Local User Management - Cannot change password
I downloaded and tried your “Change local user account password - Windows”. It works great! The only problem is how to keep the password consistent on all systems since we cannot use an automatic group. It seems that you would have to run a manual selection of all computers every week, or so. Do you have a better idea for updating new systems coming on the network.
It is possible to use the OpenSSL bits that IBM embeds to facilitate Local User Management to transport encrypted passwords and pipe them into an actionscript similar to the way Local User Management works. In this fashion, encrypted passwords can indeed target groups, even dynamic groups of machines not yet created. We use this custom approach successfully with our automated build process. It does require a common key pair for the group being targeted and assumes proper OpenSSL preparation.
An advantage of using OpenSSL directly is that if you are targeting a large amount of endpoints with a single password, it only needs to be encrypted once (assuming you have already distributed the other half of the key pair to your environment). If you did the same thing with Local User Management, it would have to encrypt separately to each endpoint, potentially bogging down your central server if you are sending to a large number of endpoints.
The real fun is combining OpenSSL-encrypted bits with relevance substitution of client-specific bits. You can create a combination of what you have and what you know. Security folks seem to love this approach.
Is there a way I can get more details about how to use OpenSSL bits to facilitate Local User Management?
Has there been any update on the Local User Management Dashboard? I am getting the same error that was reported in this thread where the generated code is not correct. There is and “endif” without a matching “if”, and there is a duplicated line at the beginning of the action script.
@mbartosh, here is an overview of the process flow.
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.
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:
openssl.exe genrsa -out private.pem 4096
openssl.exe rsa -in private.pem -out public.pem -outform PEM -pubout
Then insert half of your key pair in a location on your clients. Obscure the location and restrict permissions to all but system.
Secure and protect the other half as your organization requires.
OpenSSL can then be used to encrypt passwords, files, or whatever you want. Some sample generic syntax:
openssl pkeyutl -encrypt -pubin -inkey public.pem -in clear_text_data_to_encrypt.txt -out binary_encrypted_data.ssl
openssl base64 -e -in binary_encrypted_data.ssl -out Base64_encoded_encrypted_data_for_transport.ssl
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.
At runtime, reverse the order of the OpenSSL commands to decode the base64 to binary, then decrypt to a temporary location with only system access, pipe the decrypted information into whatever you need (app, config file, powershell, batch, etc). At the end of the job, it is a good practice to clean up by secure delete (Sysinternals Sdelete for Windows).
This process isn’t perfect, but it does work. It offers some advantages over the inherent LUM. 1) 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. 2) Anything supported by OpenSSL encryption is fair game, not just limited to passwords. 3) Target groups, not limited to specific individual machines. 4) Target machines that are not yet created via dynamic groups and policy actions (very helpful in automated build scenarios).
Common mistakes are not adequately securing the OpenSSL working folder on the client or not immediately secure wiping the decrypted data after use.
Hope this helps.
This is a problem.
Sort of.
One option is to disable the local admin accounts completely and only allow Domain Admin accounts to manage the machines.
You can rename the local admin accounts, disable them, and set them to a random password that you don’t store anywhere.
You can use DART to get into the machine if needed for recovery, or you can use a BigFix action to elevate an account to admin temporarily if needed. ( the BigFix Action will work as long as BigFix is working even for a computer off network depending on how it is designed )