One of the challenges we face is getting users on board with turning over their credentials so they can entered by a password admin.
What does the community think about the idea of the tool natively allowing self service password vaulting?
Are these users being added as Local Users accounts on PAM or as AD users?
Hello - thanks for the reply...
Credentials for servers.
Our organization lacks a centralized repository for credentials. I've seen teams utilize multiple "Key Pass" databases, sharepoint sites, sticky notes, cryptic white board writing to document credentials.
The challenge is team credentials have to be loaded into CA PAM. Natively, it appears that process requires a central individual to have access to the sensitive information.
Teams are pretty proprietary and don't like to share. Ideally, the tool would natively allow self-service credential management (by group), so teams can share management to a group set of credentials.
I understand the need.
One alternative may be to provide end users with a temporary credential to allow them to log into PAM at which point PAM would prompt them to update to a new password. That way they don't have to share their credentials with any administrators.
Actually, it is not about logging into PAM...
It's about credentials for servers, etc across the enterprise..
If you want continuous password management by teams, you could consider using dynamic target groups for privileged accounts. This could be based on, say, the value in the "descriptor 1" field of the target account. Then create a credential management role for password management (or use the existing role). Then create credential management user groups (not to be mixed up with access management user groups) for the different areas across the enterprise. Each user group contains the password management role and the corresponding target group.
When adding new target accounts, users need to be disciplined and add the correct text string to descriptor 1. If they do this, then only their team (and system administrators) can subsequently view the password or update. If they get it wrong, then only system admins can view the password, and a system admin would need to update the descriptor 1 field to make it visible to the team again.
Alternatively, you could give teams the permission to just create target accounts, but not manage them. Then you may not need to worry about scoping via the descriptor 1 field. Standard access policies would be used to view the passwords. This may require system admins to set up the access policies. Note, I haven't tried out this variant, so may require some tweaking.
Retrieving data ...