6.4 Bulk Onboarding: Password Upload Utility, Bulk Upload REST API & AccountUploader

6.4 Bulk Onboarding: Password Upload Utility, Bulk Upload REST API & AccountUploader

Quick Answer: Discovery finds accounts, but large migrations still need a way to create thousands of account objects from a list an organization already holds. CyberArk offers three bulk paths, and the exam expects you to pick the right one. The legacy Password Upload Utility is a command-line tool that reads a prepared CSV and can build the Safe environment as it goes. The modern bulk upload of accounts REST API posts an accountsList to the PVWA and returns an upload ID you poll for per-account results. AccountUploader is a separate Linux utility shipped with the PSM for SSH installation package, and it is the one designed to onboard accounts whose secret is an SSH private key file.

---

Why Bulk Onboarding Exists Alongside Discovery

Sections 6.1 through 6.3 covered the discovery-driven path: the CPM Scanner sweeps the network, populates Pending Accounts, and onboarding rules or an administrator promote those accounts into production Safes. That path is ideal for accounts nobody has inventoried.

Bulk onboarding solves the opposite problem — the organization already knows the accounts, typically because they are being migrated out of a spreadsheet, a retiring password manager, a CMDB export, or a competitor PAM product. Re-discovering them would be slower and would lose the curated metadata (owner, environment, ticket reference) the existing inventory already carries. Bulk upload also covers targets discovery cannot reach at all, such as network appliances on an isolated management VLAN.

---

Method 1: The Password Upload Utility

The Password Upload utility works with the Password Vault to create accounts from a passwords list and store them in the Vault, making an initial implementation dramatically faster. It is run from a command line whenever an upload is required, reading a pre-prepared file of passwords and their properties.

Its distinguishing capability is that it creates the required Vault environment when necessary. Rather than failing because a destination Safe does not exist, it will:

• Create new Safes named in the file,
• Add the CPM user as a Safe owner so the new accounts become manageable immediately, and
• Share the Safe with the Password Vault Web Access so the accounts are visible in the PVWA.

The input file is a CSV whose first line is the header describing the columns. A representative header and record look like this:

Password_Name,TemplateSafe,CPMUser,Safe,Folder,Password,DeviceType,PolicyID,UserName,Address,CPMDisabled,ResetImmediately
Operating System-UnixSSH-1.1.1.250-Root,ExclusivePasswordsTemplate,PasswordManager,UnixPasswords,Root,asdf,Operating System,UnixSSH,Root,1.1.1.250,,NO_VALUE

Key columns to recognize on sight:

The literal token NO_VALUE is used to explicitly blank a column rather than inherit a default — a detail that trips up candidates who assume an empty cell and NO_VALUE are equivalent.

---

Method 2: The Bulk Upload of Accounts REST API

Modern deployments prefer the REST path because it is scriptable, idempotent to re-run, and returns structured per-account results. Three endpoints form the workflow:

1. Create bulk upload of accounts — posts a payload containing an accountsList array. The response contains the ID of the bulk account upload.
2. Get all bulk account uploads for user — checks the status of every bulk upload a user has performed.
3. Get bulk account upload result — returns the summary for a specific upload: which accounts succeeded and which failed, with reasons.

Each object inside accountsList carries the account parameters. Only two are mandatory:

• platformId — a valid platform ID such as WinServerLocal.
• safeName — the destination Safe.

Optional members include username, address, secret (a password or a private SSH key), platformAccountProperties as key-value pairs defined by the platform, secretManagement.automaticManagementEnabled (default true), and remoteMachinesAccess.

Authorization is the exam-relevant constraint: the caller must hold Add accounts, Update account content, and Update account properties authorization in at least one Safe. A service identity that can only add accounts will be rejected before a single object is created.

Because the API is asynchronous, the correct operational pattern is: submit, capture the ID, then poll the result endpoint — not assume success from the HTTP 200 on submission.

---

Method 3: AccountUploader for SSH Keys

SSH keys can be provisioned in the Vault manually through the PVWA, automatically through the Accounts Feed onboarding wizard, through the AddAccount web service, or with the AccountUploader utility. The utility exists because an SSH key account's secret is a file, not a typed string, and bulk CSV columns do not carry private key material well.

Facts worth memorizing about AccountUploader:

• It is included as part of the PSM for SSH installation package — not the CPM, Vault, or PVWA installer.
• It is supported on Linux, and is run from a local Unix machine.
• Two files are copied to the run directory: AccountUploader and icudt42l.dat.

Its usage is:

accountuploader -VaultFile VaultFile -CredFile CredFile -SafeName SafeName \
  -KeyFile KeyFile -DeviceType DeviceType -PolicyId PolicyId \
  -Address Address -UserName UserName [-SubnetMask SubnetMask] [-ObjectName ObjectName]

-KeyFile points at the private key being onboarded; -VaultFile and -CredFile supply the Vault connection and the credential file identifying the uploading user, exactly as they do for the Vault's other command-line utilities.

One discovery interaction is commonly tested: SSH keys that already exist in the Vault are not rediscovered. Keys added through the PVWA, onboarded via the Accounts Feed, or provisioned with AddAccount will not reappear in Pending Accounts. Re-running the CPM Scanner against keys that are still pending refreshes their details so the Pending Accounts list reflects current state.

---

Choosing the Right Tool