Identity and Access Management in CyberArk
Users, Groups, and Directories
CyberArk distinguishes between vault users (created locally) and users sourced from directories (LDAP/Active Directory). Directory users authenticate externally, while vault users authenticate against the vault. A frequent exam trap is assuming a directory user's group membership in AD automatically maps to safe permissions; in reality, directory groups are added as safe members and CyberArk resolves membership, but the authorization still lives in the safe. Also remember that a user can be a member of many safes with different roles.
Authentication and Authorization
Separate authentication (proving identity: password, PKI, RADIUS, SAML SSO) from authorization (what the identity may do). Questions often describe a user who can log in but cannot see an account; that is an authorization problem (safe membership), not an authentication problem. Conversely, a user who cannot log in at all points to authentication methods or directory configuration.
Roles and Least Privilege
Safe member roles include levels such as retrieve, use, manage, and audit. Granting manage when retrieve suffices violates least privilege. Another trap: assuming the Vault admin can read every password. Administrative roles manage configuration but are not automatically authorized to retrieve account contents; access to credentials still flows through safe membership and policy.
Worked Example and Rule of Thumb
A new engineer needs to connect to a server through PSM but must never see the password. The correct grant is the use permission (connect via PSM) rather than retrieve. Rule of thumb: retrieve exposes the secret; use lets the session happen without revealing it. Prefer use wherever PSM is available.
Auditing Access
Access reviews should confirm that safe memberships match job roles. Periodic recertification and removing stale memberships are core IAM hygiene tasks in PAM.