5.5 Vault Users, Predefined Groups & Vault-Level Authorizations

5.5 Vault Users, Predefined Groups & Vault-Level Authorizations

Quick Answer: CyberArk enforces two independent permission planes. Safe-level authorizations (section 5.2) decide what a member may do with the contents of one Safe. Vault-level authorizations — Add Safes, Audit Users, Add/Update Users, Reset Users' Passwords, Activate Users, Add Network Areas, Manage Directory Mapping, Manage Server File Categories, Backup All Safes, Restore All Safes — decide what a user may do to the system itself, and they are set on the user object in the PrivateArk Administrative Client. The Vault ships with predefined users and groups for these tasks, and every predefined user except Master is created disabled and must be explicitly activated.

---

Two Permission Planes, Not One Ladder

Candidates routinely assume permissions form a single hierarchy, then fail scenario questions because the two planes do not inherit from each other.

The consequence worth memorizing: a user with Add Safes can create a Safe but has no ability to read credentials in Safes they are not a member of, and a user with full Safe permissions on a production Safe cannot reset another user's Vault password. Separating them is what makes the Vault administrator role distinct from the credential consumer role.

The Vault Authorizations Catalog

Two authorization combinations are tested directly because neither task works with a single permission:

• Editing a user account requires Audit Users and Add/Update Users.
• Resetting a user's password or activating a suspended user requires Audit Users, Reset Users' Passwords, and Activate Users.

Note also the recurring phrase "at the same level or lower on the Vault hierarchy." Vault users sit in a hierarchy, and an administrator cannot act on a user positioned above them — which is why the Administrator user, sitting at the highest level, is the only identity that can manage users at every level.

---

Predefined Users and Groups

The Vault automatically creates several users and groups during installation and upgrade for administrative purposes. Predefined groups are added automatically to every Safe in the Vault, with the corresponding predefined user added as a member, so anyone you add to one of these groups immediately becomes an owner of all Safes according to that group's authorizations. That is a powerful and frequently misused shortcut.

Activating the Predefined Users

Although these accounts are created automatically, all of them except Master are disabled. The activation procedure is short and frequently examined:

1. Log on to the PrivateArk Client as the Master user.
2. In the General tab of the User properties window, clear the Disable User checkbox.
3. In the Authentication tab, change the default password.

A Vault where the CPM will not start, the backup never runs, or ENE sends nothing is very often a Vault where the corresponding predefined user was never activated.

---

Provisioning an Internally Authenticated User

Not every Vault user comes from Active Directory. An internally authenticated (CyberArk-authenticated) user has its credential stored and validated by the Vault itself, which is exactly what you want for break-glass identities that must still work when the directory is unreachable — the failure mode covered in section 12.4.

To provision one from the PrivateArk Administrative Client: create the user object, place it in the appropriate Location in the Vault hierarchy, set CyberArk as the authentication method with an initial password and User Must Change Password at Next Logon, assign the user type the license defines for the interfaces it needs, set any Vault-level authorizations on the Authorizations tab, and add it to the relevant groups.

User type matters more than candidates expect. The license defines user types that control which interfaces a user may access, including EPVUser (PVWA, PrivateArk Client, PACLI), PVWA, CPM, PSM, PSMUser, ENE, AppProvider, and AIMAccount. Assigning the wrong type produces an authentication failure that looks like a password problem but is really an interface restriction, and it also consumes the wrong license bucket.

---

Adding Users and Directory Groups to Vault Groups

Group membership is the supported way to grant authorizations at scale; assigning permissions directly to individual users does not survive staff turnover.

• Adding a Vault user to a Vault group: open the group in the PrivateArk Client and add the user as a member, or add the group membership from the user object. The user inherits the group's Safe ownership and authorizations immediately.
• Adding an LDAP user or group to a local Vault group: external (directory) identities can be made members of internal Vault groups, which is how an Active Directory group such as PAM-Auditors is granted the rights of the built-in Auditors group without duplicating membership by hand. The directory remains the source of truth for who is in the AD group; the Vault group supplies what they can do.
• Directory mapping order still governs Vault authorizations. When a directory user matches more than one mapping, the first matching mapping in the priority list wins — so a help-desk mapping listed above a Vault Admins mapping silently downgrades administrators to the help-desk subset. Section 12.1 covers mapping rules in full; the point here is that Vault-level authorizations can be granted by a directory map as well as by a local group.

Because external users' general details are maintained in the directory, they cannot be edited in the PrivateArk Client — a change of surname or email is made in Active Directory and flows in, while authorizations and group membership remain a Vault-side decision.