Account Onboarding and Management
What this domain tests
The exam checks whether you can take a privileged account from 'known but unmanaged' to 'managed, rotating and auditable' - and whether you can tell which onboarding decision caused a later failure. Most questions here are diagnostic: a password never changes, a change fails with an authentication error, or the wrong plugin is in play.
Core rules
- An account object is more than a password: username, address (or SPM host and key for SSH), platform, Safe, and CPM settings. Each of these can change CPM behavior independently.
- There are three onboarding routes: manual Add Account in PVWA, bulk CSV import, and automatic detection/discovery. Discovery and auto-detection propose candidates; they do not complete management on their own.
- Match the platform to the account type and protocol, not to the operating system. A domain administrator needs a domain-aware platform; a local administrator needs a local one; an SSH key needs the key/SPM-style platform.
- CPM must authenticate to the target with the current password before it can change it. If the vault copy is stale, CPM cannot fix it by itself - the account needs reconcile or a manual set to a trusted password.
- Onboarding alone rotates nothing. Rotation requires an enabled change policy (interval, immediate/first-use change, or a manual change operation) plus a CPM user with enough rights on the target.
- Account state matters: managed, unmanaged, and reconcile-required. Reconcile-required means vault and target disagree, and CPM has no trusted credential to work from.
Worked example
An engineer onboards a new Windows domain administrator using the 'Windows Local Account' platform because the target machine runs Windows. CPM fails nightly with 'user not found'. Reasoning: the platform's plugin edits the local SAM database, but the account lives in Active Directory, so the plugin looks in the wrong store. The Safe and CPM user are fine. Re-onboard under a domain platform (or change the platform on the existing account) and the same CPM user succeeds.
Traps that cost marks
- Choosing a platform by OS family instead of account type and authentication protocol.
- Assuming discovery onboards accounts automatically; it only surfaces them for approval.
- Forgetting the CPM user itself can be locked out, which halts every change in its scope.
- Leaving imported accounts unmanaged and expecting rotation.