Password management not working for AIX target accounts
Article ID: 110127
Updated On:
Products
CA Privileged Access Manager - Cloakware Password Authority (PA)
PAM SAFENET LUNA HSM
CA Privileged Access Manager (PAM)
Issue/Introduction
We publish new devices, target applications and target accounts using the PAM Rest API. We have two administrative accounts on each device with one being used to change the password of all other accounts, and the second one being used to change the password of the first admin account. This works for most Linux/UNIX devices, but doesn't work for some of them. The problem devices are AIX hosts.
Cause
There are two aspects that typically are different from Linux and other UNIX flavors on AIX:
1) When one user runs "sudo passwd <otheruser>" to update the password of another user, the other user will have to change the password on next login. This would not work with PAM managing the password and using accounts for auto-login. We would not want the PAM user to enter a new password. To avoid this problem the UNIX target application type has additional logic for AIX devices and runs a "sudo pwdadmin -c <otheruser>" after changing the password for another user. This will avoid the new password prompt on next login. But this logic only kicks in when the target application is configured with UNIX variant "AIX".
2) The new password confirmation prompt may different.
Typical Linux/Unix passwd command dialog:
[[email protected] ~]# passwd capamusr
Changing password for user capamusr.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Here the password confirmation prompt is "New password: ". Another typical form is "Re-enter <user>'s new password:"
These will match the default regex PAM uses to verify that the passwd command responds as expected and doesn't report an error.
But on AIX devices you may see a confirmation prompt like
Enter the new password again:
This will not match the default regex in PAM releases 3.1.1 and older. It will match the default regex in PAM 3.2 and up.
1) When one user runs "sudo passwd <otheruser>" to update the password of another user, the other user will have to change the password on next login. This would not work with PAM managing the password and using accounts for auto-login. We would not want the PAM user to enter a new password. To avoid this problem the UNIX target application type has additional logic for AIX devices and runs a "sudo pwdadmin -c <otheruser>" after changing the password for another user. This will avoid the new password prompt on next login. But this logic only kicks in when the target application is configured with UNIX variant "AIX".
2) The new password confirmation prompt may different.
Typical Linux/Unix passwd command dialog:
[[email protected] ~]# passwd capamusr
Changing password for user capamusr.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Here the password confirmation prompt is "New password: ". Another typical form is "Re-enter <user>'s new password:"
These will match the default regex PAM uses to verify that the passwd command responds as expected and doesn't report an error.
But on AIX devices you may see a confirmation prompt like
Enter the new password again:
This will not match the default regex in PAM releases 3.1.1 and older. It will match the default regex in PAM 3.2 and up.
Environment
PAM 2.8.4.1, but part of the discussion applies to all supported releases as of August 2018 with PAM 3.2 being the latest release at this time.
Resolution
For problem 1 above, make sure to set the UNIX Variant to AIX in the target application.
For problem 2, either upgrade to 3.2 or customize the password entry prompt in the script processor section of the target application. A regex like "(?si)(.*?password.*:.*)" should cover all cases. Note that the UNIX connector uses the Password Entry Prompt regular expression for the second new password prompt rather than the Password Confirmation Prompt regex.
There was another problem in PAM 2.8, 3.0.X and 3.1.1: When a target application was created using the Rest API, the target application could not be edited from the UI. In this case you can use the Rest API to update existing target applications as follows:
1. Use "GET /api.php/v1/devices.json" to get the device ID (field deviceID) if needed. Use e.g. "deviceName" as a filter.
2. Use "GET /api.php/v1/devices.json/{id}/targetApplications", with {id} being the device ID from the previous call, to get the target application ID (field id).
3. Now use "PUT /api.php/v1/devices.json/{id}/targetApplications" with the same device ID to update the target application with a body similar to the following:
{
"attributes": {
"unixVariant": "AIX",
"passwordEntryPrompt": "(?si)(.*?password.*:.*)"
},
"id": "1007"
}
Here 1007 is the target application ID retrieved with the second GET.
For problem 2, either upgrade to 3.2 or customize the password entry prompt in the script processor section of the target application. A regex like "(?si)(.*?password.*:.*)" should cover all cases. Note that the UNIX connector uses the Password Entry Prompt regular expression for the second new password prompt rather than the Password Confirmation Prompt regex.
There was another problem in PAM 2.8, 3.0.X and 3.1.1: When a target application was created using the Rest API, the target application could not be edited from the UI. In this case you can use the Rest API to update existing target applications as follows:
1. Use "GET /api.php/v1/devices.json" to get the device ID (field deviceID) if needed. Use e.g. "deviceName" as a filter.
2. Use "GET /api.php/v1/devices.json/{id}/targetApplications", with {id} being the device ID from the previous call, to get the target application ID (field id).
3. Now use "PUT /api.php/v1/devices.json/{id}/targetApplications" with the same device ID to update the target application with a body similar to the following:
{
"attributes": {
"unixVariant": "AIX",
"passwordEntryPrompt": "(?si)(.*?password.*:.*)"
},
"id": "1007"
}
Here 1007 is the target application ID retrieved with the second GET.
Feedback
Yes
No
Powered by
