Onboarding a Mixed Linux Estate After Discovery
A financial services firm has 300 RHEL servers across three data centers. A discovery scan returns 420 privileged accounts: 300 local root, 90 personal sudo-enabled admin accounts, and 30 service accounts that authenticate with SSH keys. The security team wants all 420 onboarded to the Vault within two weeks using the out-of-the-box Unix via SSH platform, with a 30-day CPM rotation. During automatic onboarding, 35 accounts are rejected as invalid because the username does not exist on the target, and 18 root accounts show a password mismatch. Twenty servers have PermitRootLogin no, and the service accounts have no password to rotate. The DBA team shares 45 root accounts and objects to per-person accountability. The project sponsor asks whether to fix the discovery data or onboard everything now.
1. What onboarding sequence and triage criteria would you use for the 420 accounts? State what you would not onboard automatically and why.
Read the worked answer
Start by treating onboarding as a data-quality and risk-classification problem, not a bulk import. Build a reconciliation list keyed on safe, platform, machine, username, and account type. Onboard automatically only accounts whose target is reachable, username exists, and credential is verified. Do not auto-onboard the 35 invalid accounts until discovery is corrected; force them through manual review because auto-onboarding wrong machine-username pairs creates duplicates and false rotation. For the 45 shared root accounts, onboard under a restricted safe and use PSM Use accounts with session recording, but do not grant Retrieve accounts; require access requests or dual control. For the 20 root-disabled hosts, onboard only after a Logon Account with sudo can manage root; otherwise they will fail rotation. For the 30 SSH-key service accounts, use a key-based platform, not the password platform, and treat key rotation as a separate workflow. The sequence should be: fix discovery, onboard verified root first, configure logon accounts, onboard service accounts, then remediate shared root. This prevents a two-week deadline from creating unmanageable duplicates.
2. For the 18 password-mismatch root accounts, compare Verify, Reconcile, and Logon. What is the safe order of operations and what failure mode would make you stop?
Read the worked answer
Verify is non-destructive: it tests whether the Vault password works. Run it first and capture the exact failure. If it fails, use Logon to confirm whether the credential is wrong or the platform cannot reach the prompt. Reconcile is not a retry button: it uses a working privileged logon account to reset the target password to the Vault value, so it can lock or overwrite an account if the logon account is wrong. For root-disabled hosts, reconcile may be impossible because no account can reset root. Safe order: verify, then logon, then fix or attach a logon account, then reconcile once in a change window. Stop if the logon account itself locks, if the target has account lockout thresholds, or if root login is disabled. Repeated reconcile attempts are how you turn a mismatch into an outage.
3. How would you model the 20 PermitRootLogin no servers and the 30 SSH-key service accounts in platforms and safe design?
Read the worked answer
Model root-disabled servers by cloning the Unix platform and setting Use Sudo plus a Logon Account that is a personal or service sudo account; the managed root account then has no direct SSH login and rotation is delegated through sudo. Do not use a shared root password as the logon account. For SSH-key service accounts, use an SSH-key platform with the private key as the secret and rotate keys on a separate schedule; do not pretend they are password accounts. In safe design, split by environment and account type: a root safe with dual control and no contractor retrieve; a service-account safe where the application team has Use accounts but not Retrieve accounts; and an automation safe for key material. Use account groups or dependencies only where the application really shares a credential, and document the dependency so CPM does not rotate one side blindly.