When IBM promised to release a workaround for the vulnerability we found in their product, I truly expected such a widely respected company to release an enterprise-ready workaround, and not just a manual approach to set registry permissions in the GUI.
One would think, that IBM would release something easily deployable to multiple servers in the enterprise, right? But instead they released a workaround that requires system administrators to click around in the Windows GUI, for every server they have in the environment, potentially tens, hundreds or thousands of systems.
They could at least have provided a scriptable solution, e.g. with Regini.exe or PowerShell. A standalone executable, like an EXE or MSI file would also have been nice.
At your own risk
Instead of clicking through the GUI, I'll suggest another approach - however, I cannot promise or offer any support for this solution. Please do your own controlled testing before deploying a large scale. Doing this is at your own risk!
It is much easier to use built-in Group Policy settings to set the correct permissions on the relevant registry keys. The problem is knowing exactly which keys are required to be read and by whom.
What keys?
I'd suggest that you choose to control one of these registry keys:
"HKEY_LOCAL_MACHINESOFTWAREIBMADSM"
"HKEY_LOCAL_MACHINESOFTWAREIBMADSMCurrentVersionNodes"
I can't see why regular users should be able to read anything below the ADSM branch, but I can't be 100% sure. IBM should be able to answer that question.
What users/groups?
I'd suggest that you remove the regular "Users" group, and stick to the following groups instead:
BUILTINAdministrators
BUILTINBackup Operators
NT AuthoritySYSTEM
A manageable approach, but...
The disadvantage of using the following approach is, that the registry value will be created on all servers hit by this GPO, no matter if they have IBM TSM installed or not - although one perhaps could create a WMI filter. Just be careful to hit only relevant servers with the GPO.
Also remember, that with a manual approach - if you'd ever have to undo permission changes in the registry - that would be another round of manual labor.
Create a GPO and deploy to relevant servers
Create a new Group Policy Object (GPO) to be linked to relevant Windows servers "protected" by IBM TSM. Use Security Filtering if required.
Open the new GPO in Group Policy Management Editor
Browse to "Computer Configuration" > "Policies" > "Windows Settings" > "Registry"
Right-click and choose "Add Key..."
In the "Select Registry Key" dialog, browse to the registry key of your choice (see above) and click OK
Select "Configure this key then" and "Replace existing permissions on all subkeys with inheritable permissions"
This will make sure that permissions on all subkeys, including the key where the IBM TSM Node Password is stored, will be replaced by the new and more secure setting.
Then click the "Edit Security..." button
Make sure to only include the users/groups mentioned above (see screenshots below)
Do NOT include "Users" here, like IBM did... Regular users have no need to see this.
Make sure all included security groups and user accounts are assigned "Full Control"
Accept all dialog boxes and exit Group Policy Management Editor
The GPO "Settings" tab in Group Policy Management Console (GPMC) should look like the screenshot below (depending on what registry key and groups you chose to go with)
Looking at the result
After linking the GPO to relevant servers, and awaiting the Group Policy update cycle (or forcing GPupdate to execute) their registry permissions should be set correctly.
Using PowerShell to confirm changes
Before the Group Policy change, the Get-Acl command would return the following (which is default IBM TSM permission settings).
PS> Get-Acl -path HKLM:SOFTWAREIBMADSMCurrentVersionNodes | % {$_.access}
After the Group Policy change, the command will only return the following ACL entries.
A regular user browsing the chosen registry key (e.g. with regedit.exe), will receive an "Access is denied" error message - and so the IBM TSM Node Password is responsibly secured.
I hope this helps someone out there...