What to do if you use IBM DataStage, but changed the password to root

It so happened that due to the interesting architecture of the entire system (which is called the Information Server), the DataStage is very sensitive to such a banal procedure as changing the user's password, which, for example, is used to edit etl procedures ( so-called jobs ) or other operations.

This confusion also arises because there are many different places in the product where you can log in, create users, assign roles and specify their passwords. This is at least WAS - the WebShere application server, the Information Server Web Console , and the Designer , Director, and Administrator clients themselves. Authentication procedures on the application server can be different and are selected based on the security policy of the company on whose servers DataStage is deployed. Problems arise when authentication is performed via the local operating system (roughly speaking, the username and password in the OS coincides with the usernames when entering the administrative console).



So, in this small post I will try to talk about how to restore the system to work after the procedure for changing the password of the OS user has been implemented.

Step 1

We force WebSphere to change all user password hashes that have changed.

For this in the catalog



%ISHOME%/ASBServer/bin



run the script

')

./AppServerAdmin.sh -was -user _ -password _



(if the DataStage server is running on Windows, then .sh, of course, turns into .bat)

After running this script, it is necessary to suffer some time, the script does not suddenly work.



By the way, it will probably be interesting to you that any passwords stored in any configuration files can be turned into hashes using the utility %WASHOME%/AppServer/bin/PropFilePasswordEncoder.sh ,

which syntax is simple



./PropFilePasswordEncoder.sh _ _



in this case, the value of the specified property must be unhashed password.

For example, if you need to change the value of the com.ibm.SOAP.loginPassword field in the soap.client.props file, then you need to do the following:

• Delete the previous password hash. The hashes in the WAS configuration files are stored as {} . The default is XOR encryption, which will be reported by the {xor} line before the hash. It is safe to write the required password in open form instead of this line;
• Run the script, in this example, like this: ./PropFilePasswordEncoder.sh "/opt/IBM/WebSphere/AppServer/profiles/default/properties/soap.client.props" com.ibm.SOAP.loginPassword

Run another script, depending on how access to IS is configured once or twice:



./DirectoryAdmin -user -userid -password



and \ or



./DirectoryAdmin -user -admin -password

Step 2

You need to go to WAS in the Security-> Global Security-> Authentication section and change the password for the type of authentication that is used in your case. (For example, LTPA). Do not forget to save the changes in the Master Configuration.

Step 3

After these actions, you need to the Information Server Web console (usually it is available at servername:9080 servername:9080 ) in the tab Administration-> Users & Groups-> Users change the password for the desired user and, of course, save the changes.

If after these actions the Designer, Director or Administrator clients still cannot connect to the server, in this case you need to share the Information Server & DataStage users repository (also using the Web console and the Administration-> DataStage credentials tab).