PAM documentation supplement: Use Case Steps for PAM integration with RSA
Article ID: 187483
CA Privileged Access Manager (PAM)
Broadcom documentation lists the necessary steps to integrate the use of RSA SecurID provided below. This KB provides a use case example and documentation supplement to further assist with the PAM integration with RSA.
Register CA PAM as an Authenticating Device on the RSA ACE server This is crucial. The PAM documentation is not specific on exactly what needed to be done as this configuration can be subjective depending on the specific use case.
As of RSA Authentication server 8.2: Security Domain: Same Security domain Hostname: As the documentation suggests, this has to be exactly like the Hostname configured in CA PAM network settings. We used FQHN for both. IP Address: This has to be the exact IP address of the appliance which will reach out to the RSA Authentication Server: Note: We originally made the mistake of just putting the VIP hostname/IP. All appliances which may authenticate to the RSA Authentication Server need to have an entry. Protect IP Address: Yes Agent Type: Standard Agent Disabled: No User Group Access Restriction: No Trusted Realm Authentication: No Trusted User Authentication: open to all trusted users
** Node Secret: Do not add a node secret !!! ***
Configure the RSA SecurID 800 Hybrid Authenticator This was a confusing step. I Interpreted this as to ensure the soft token configuration was setup in a specific way. Type: SecurID Software Token, 8 digits, changes every 60 seconds (AES-TIME) Displayed value: Passcode (PIN incorporated into tokencode)
Testing Create a local test PAM id that matched my id in RSA. Set the Authentication to "RSA". At the PAM login, use my RSA ID, Authentication type "RSA", and the current Passcode from the RSA soft token. Once this has been verified as working, move onto the next step.
Configure LDAP+RSA Authentication Migrating from LDAP to LDAP+RSA Authentication. In this specific use case, the entire employee organization unit was linked to AD. For instance, "employees" OU (with LDAP authentication) and then created local PAM groups for association with policies,
We moved to AD Groups imported (with LDAP+RSA Authentication) which served as the PAM groups for association with policies. This allowed PAM access control to be managed by our IDM tool ie move users in / out of AD groups.
In this case, we had to remove the single AD link ("LDAP" authentication) before linking the individual AD groups (LDAP+RSA Authentication) Note: we tried having them exist in parallel which didn't work.
This procedure caused all the policy mappings to be erased. We had anticipated that effect and had a backup of the original policy mappings. Note: I had the PAM USRSYNC patch handy as doing this procedure in development revealed some database inconsistency issues.
Perform this on one node to test first before restarting the cluster.