- Ease of use.
- The way in which it can learn about the connectivity to systems, e.g., VMware vCenter Console; it can wrap that into its internal Java-based shell. Therefore, one does not need a terminal server solution.
- The non-Java based client.
- Two integration options with AD using SAML and the AD GC ports.
- The API explorer.
This system comes with a built in Java client which handles the connectivity to remote systems, e.g. the VMware vCenter Console Web Interface.
When you add the system to the CA PAM, you can put the connection into “learn mode” where you map out where the username and the password and submit fields are. You can then configure the system in PAM with the relevant credentials and then based on the information it “learned” about where the username and password and submit fields are and what needs to go where, it presents you with a vCenter Web Interface and logs you onto vCenter automatically based on your PAM permissions. This vCenter Web Console is effectively proxied via this Java Client that CA PAM has available and happens through the PAM system – the end user does not make a direct connection to vCenter.
In other PAM solutions that we tested, one had to setup a Microsoft Remote Desktop Server (TS) and publish the vCenter Web Interface and integrate that published app with the PAM solution so that when a user wants to access the particular vCenter server, PAM initiates the Remote Desktop Server published app – inserts the credentials – to provide you with access to vCenter.
When integrating with Active Directory for authentication purposes – most vendors support LDAP. For larger AD environments, the LDAP integration supports the Microsoft MSFT ports (3268 & 3269) that allows one to look for nested group memberships across multiple child domains. Another way to integrate with AD is to use SAML.
We were able to use both methods with the CA PAM solution. With another vendor we tested, they did not support SAML.