Using browsers for credential management in PAM
search cancel

Using browsers for credential management in PAM

book

Article ID: 199783

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

Sometimes, due to limitations in the environment or to business requirements, it is impossible to use the CA PAM Client to access a PAM appliance.

If the browser must be used, as of September 2020, the only one still supporting javascript is Internet Explorer 11. Javascript must be enabled in order for the java applets to work, so that RDP and SSH access can be made from the local browser to the remote systems in PAM. So, if this access part is required and there is any problem loading initial access page, troubleshooting must be made involving Internet Explorer behaviour, deployment of the jre, etc.

However, there may be a use case where CA PAM is basically used for password vaulting. The credential management part of the product does not require java to function and access to such functionality as password rotation, credential groups, schedule jobs, etc should be possible from any browser.

Unfortunately any newly defined user is assigned, by default, the Standard User role which, on logging in in the initial page of PAM will try to load the applets and will remain there forever or error out if the browser is other than Internet Explorer.

This document describes the general procedure for setting up a user which will access just credential management functions and will not try to load the applets when it logs in into PAM.

Environment

PRIVILEGED ACCESS MANAGEMENT, all versions

Cause

Every user when defined is automatically assigned the Standard User role, which will attempt to load the applets on log in, thus preventing browsers other than internet explorer from being used to access the product, even if it is only the credential management functionality

Resolution

These are generic instructions on how to carry out this task. No detailed listing of rights and actions can be given because it will depend on each case of what kind of functionality we want to keep, but following the guidelines in this general use case should help. The procedure below describes how to limit certain users to just being able to log in and manage certain target accounts and applications. The use case may be made much less restrictive with no effort.

  1. Define a new role, LimitAccess, in the Access Management part of the product, which has only some of the rights. For instance remove from it all rights related to access to devices, management capabilities, and leave to it just the actual ability to view the users (as otherwise it might not have the right to log in). Leave some other access rights, fundamentally those related to connecting to the credential management part of the product. 
  2. Next assign to the User Group containing the users you would like to have this role as, the LimitAccess role. Let's call it LimitAccessGroup. If the product version is below 3.4 the role must be assigned to individual users as well, as this is required so that they can be assigned to Credential Management groups; if the product is version 3.4 or later, Credential Management groups may be mapped directly to Access Management groups and this step is not necessary. Make sure that the Standard User and other roles have been removed from the User Group and, if necessary, from the individual users, as having the Standard User role assigned will cause the applets to be loaded. 
  3. For the Credential management part, the users we want to enable to just manage their passwords and devices should not be able to delete their target applications, accounts or servers or manage other users. To this effect we have done the following
    • Created a new role LimitCredRole with Credential Management rights pertaining only to listing, viewing and updating passwords, target accounts and target applications. Reporting, A2A, deletion and addition rights can been removed from this new Credential Manager role. Assigned this role to a new Credential Manager Group, for instance let's call it LimitCredGroup
    • Create a static Target Group LimitCredTargetGroup containing the target account(s), targetserver(s) and targetapplication(s) which require management, and assign the LimitCredGRoup to the LimitCredTargetGroup
    • In User management, assign the LimitCredGroup to the users considered before (or if you are on version 3.4 and later, directly to the LimitAccessGroup), so that they can only manage the LimitCredTargetGroup with the rights defined by the role.

 

Powered by Wolken Software