It's generally a good idea to configure one account to manage another, actually several others. Doing so makes recovery easier when you have a bunch of accounts out of sync. To do so, configure your users on the target server and make sure that the control account can change the password of the controlled account when logged into the unix server directly. You may need to do some work on the target in order for this to work. In my tests with an aix server I had to add the control user to the "security" group. With this done, I was then able to change the controlled account's password when logged into the aix system directly. It still didn't work in within CA PAM. This did not work. I reviewed the catalina.out, collected after reproducing the problem with Tomcat Log Level = Info on the Config --> Diagnostic page. Take a look at these messages I extracted from from the file and you will see the problem:
Aug 11, 2016 6:24:16 PM com.cloakware.cspm.server.plugin.CSPMClientChannel readUntil
INFO: received data 'sudo passwd user2
$ ksh: sudo: not found
$ ' does NOT MATCH any of the pattern(s): '[(?si)(.*?new password:.*?)]'
Aug 11, 2016 6:24:16 PM com.cloakware.cspm.server.plugin.BeanShellScriptProcessorImpl executeScript
INFO: stopping script processor
You can see that CA PAM is trying to use Elevate Privileges, sudo, in order to change the password for user2. The only problem with this is that sudo is not installed by default on many unix systems, maybe all. That was the case on the test system I was using. I chatted with Engineering about this and it appears that this is a bug. When you configure an account to manage it's own password you have the option of selecting the Privilege Elevation. The options are: Do not use elevated privileges, Use elevated privileges, Use elevated privileges with authentication and This account is a root account. When you configure CA PAM to use another account to manage this one you will see that the Privilege Elevation section is grayed out. It appears that CA PAM is expecting that the user is either root or that sudo will be used.
Since I couldn't avoid using sudo, I asked my colleague Ralf to help me install it. As expected, CA PAM was now able to change the password of user2 with user1. I've opened a ticket with Engineering, as I believe we need to have the Privilege Elevation section active, even when using one account to control another. In the meantime, following this example should get you past most of the problems.
There is one more thing that could come into play. If you look at the Script Processor tab in the Target Application you will see that you can override the default regular expressions for the various prompts. Pay attention to these prompts when you go through the password change test when directly logged into the target server. Make sure that the regular expressions are correct for these prompts. You also have to select the correct unix variant on this page, as the various defaults may change with the selection. An example of this is that with aix the Policy Management field has a default of pwdadm, which is not the case for other variants. This command is used to tell aix not to require that the user change the password at the next login. Other versions of unix do not have this requirement.
I believe this covers this topic completely. Feel free to comment if you feel I missed something.