Access Control, Authentication and Authorization
What this domain tests
The split between authentication (proving identity) and authorization (what the identity may do). Questions often describe a user who can log in but sees nothing, or who sees accounts but cannot connect - and expect you to name the missing layer.
Core rules
- Authentication methods include CyberArk (Vault) passwords, Windows integrated authentication, LDAP, RADIUS, and SAML. They are configured for the relevant interface (PVWA versus the Vault/PrivateArk), not globally.
- Directory mapping maps an AD/LDAP group to a Vault group, so AD group membership becomes Vault authorization and Safe membership. A mapping mistake looks like an authorization bug.
- Vault-level authorizations (administrator, auditor, CPM, PSM, privileged account user) decide whether a user can enter the interface and perform system functions. Safe-level permissions decide which accounts they can act on.
- A Vault administrator is not automatically a Safe member. Admin rights over the system do not imply the right to retrieve a specific account's password.
- Dual authentication/MFA adds a second factor; caching windows reduce prompts but do not change the underlying authorization.
- User type matters: directory users are authenticated externally, while Vault users hold credentials in the Vault. Disabling or expiring the wrong one produces different failures.
Worked example
An AD user authenticates successfully to PVWA but sees no Safes. Reasoning: authentication succeeded, so MFA, LDAP bind, and directory mapping for logon are working. The empty view points to authorization: the user is not a member of any Safe, or the AD group was never mapped to the Vault group that the Safe authorizes. Check Safe membership first, then directory mapping - not the user's password.
Traps that cost marks
- Diagnosing an authorization symptom as an authentication failure (or the reverse).
- Assuming a Vault administrator can see all accounts; they cannot unless they are Safe members.
- Forgetting that removing a user from an AD group changes access only at next logon/token refresh.
- Testing with an account that has broad Vault authorization and concluding the mapping works for everyone.