PAM-CMN-0900 and PAM-CMN-1798 Renamed LDAP user cannot access PAM with old or new UPN or short name

Products

• CA Privileged Access Manager (PAM)

Issue/Introduction

An Active Directory (AD) user whose first and/or last name, and the User Principal Name (UPN) was updated in AD no longer is able to log on to PAM using either the old or new UPN, or the old or new short name, where the short name is the part of the UPN preceding the "@" character. If sAMAccountName did not change, it can be used for a successful logon. The user is member of a user group with a Secrets Management role in PAM.

The PAM session logs show messages similar to the following when the user group is refreshed:

PAM-CMN-1798: Could not rename user <new UPN>. Error was PAM-CM-0873: Invalid user group ID. User group ID ##### does not exist.
 
Followed by:
PAM-CMN-2262: PA User <user distinguished name>.  Error message: PAM-CM-0620: No data found for specified User..

An attempt to resolve the problem by temporarily removing the user from the user group in AD and refreshing the group again fails as well with similar errors, and the user remains a member of the user group in PAM.

The user will see the same "PAM-CMN-0900: Bad User ID or Password." error with either the old or the new name.

The PAM session logs will show a "PAM-CMN-0979: LDAP authentication failed ..." error when attempting to logon with the old name, and a "PAM-CMN-0967: The Active Directory user with user principal name <new UPN> ..." error when trying with the new name.

Environment

• Privileged Access Manager 4.3.1 and lower, with upcoming release 4.3.2 likely to be affected as well.
• Integration with Active Directory for PAM user access
• Secrets Management vaults configured in PAM

Cause

The user group is configured as owner of a Secrets Management (SM) vault in PAM. When a user group is assigned ownership of an SM vault, PAM creates an internal Credential Management (CM) user group that is used to control access rights to the vault and secrets in it. The workflow of renaming the user fails over a conflict between two calls it makes, where one gets a list of assigned user group IDs that includes the internal group IDs, and one gets a list of groups filtering out the internal groups.

Resolution

The problem is expected to be fixed in future releases. Look for identifier DE684886 in release notes of PAM releases after 4.3.2.

On product releases that have this problem you can work around it by temporarily removing the user group(s) the user is in from any vault ownership lists:

1. Go to PAM UI page Secrets > Manage Vaults
2. Edit each vault that the group might be assigned to, go to the Vault Managers tab and check the list of selected groups in the lower right quadrant. Remove any group that the renamed user is a member of. Note that at least one owner or owner group needs to be assigned.
3. Refresh the LDAP user group. Now it should be successful and the user should get renamed to the new settings in AD.
4. Restore previous vault ownerships.

Additional Information

You can check on vault ownerships programmatically using Rest API resource "GET /cspm/ext/rest/vaults" to get a list of vaults including their IDs, and then resource "GET /cspm/ext/rest/vaults/{id}" for each vault ID to get the list of configured owners and owner groups.

There is no call to get details on the CM group based on the ID seen in the PAM-CM-0873 message. Since this is an internal group, it will NOT be included in the output of a "GET /api.php/v1/passwords/userGroups.json" call.