Documentation of every Command available in Keeper Commander
rotate (legacy)
Commands for importing and exporting vault records, folders and teams permissions.
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Import and Export Commands
Command | Explanation |
Import data from a local file or other password managers | |
Export vault records | |
Download shared folder memberships | |
Apply shared folder membership changes | |
Download custom record types | |
Load custom record type into Keeper |
Command: import
Detail: Import data to Keeper from a local file or other password managers.
Parameters:
Path of file to import from.
*note: in file paths, backslash "\" needs to be escaped by using two in a row "\\"
Switches:
--format <{json, csv, keepass, lastpass, myki, manageengine, 1password, bitwarden, thycotic, proton}> file format (required)
--folder <FOLDER PATH OR UID> import into a specified folder
--filter-folder <FOLDER NAME> only import the specific folder from the source vault
-s, --shared import folders from file as shared folders
-p, --permissions <PERMISSIONS> default shared folder permissions if importing folders as shared
folders
U - manage users permission granted
R - manage records permission granted
E - edit records permission granted
S - share permission granted
A - all permissions granted
N - no permissions granted
-dc
, --display-csv
show instructions for importing using the CSV format
-dj
, --display-json
show instruction for importing using JSON format
--record-type
<RECORD TYPE NAME> import all records as the specified type
--dry-run
display records to be imported without importing them
--show-skipped
display skipped records
--update
update records with common login, url or title
Examples:
Import records from a "records" CSV file into the vault
Import records from a "records" CSV file into the "social" folder
Import records from a "shared-records" json file, importing and folders as shared folders with all permissions granted
Import passwords from a Lastpass export file
Show instructions and example for importing using CSV
Import records from a "records" CSV file as login type records
Import records from Thycotic/Delinea Secret Server using full URL
Import records from Thycotic/Delinea Secret Server using username/hostname syntax
Additional import instructions are documented below.
Ensure that you upgrade to the latest version of Commander to support all import methods.
Command: export
Detail: Export vault data to a file or the console
Parameters:
File name to export to, or nothing to export to console stdout
Switches:
--format
<{json, csv, keepass}> file format
The keepass
format is encrypted and can not be exported to the CLI. Keepass exports must be output to file.
--max-size
<SIZE> maximum size of file attachment to export
format: number followed by "K","M","G" (Kilobyte, Megabyte, Gigabyte respectively)
e.g. "100k" , "10M" , "2G"
-kp
, --keepass-file-password
<PASSWORD> if exporting in keepass format, set the file's password
--zip
Create ZIP archive for file attachments. JSON only
--folder
<FOLDER NAME OR UID> select a folder as the export source
--store-in-vault
Stores exports file as a record attachment. Keepass only
Examples:
Export the vault in CSV format to a file named "my-vault"
Export the vault in JSON format to the console, ignoring any file attachments over 10 KB
Export the vault in keepass format to a file named "keeper" and set the file's password
Export the records in the "Socials" folder
Command: download-membership
Detail: Download shared folder membership to a local JSON file.
Switches:
--source <{keeper, lastpass, thycotic}> (required)
--folders-only Unload shared folder membership only. Skip team membership.
--sub-folder <{ignore, flatten}> (optional, default ignore) Thycotic/Delinea Secret Server allows shared folder permission to be overwritten by the subfolders. This option controls how these folders are imported.
ignore Subfolder permissions are ignored. Folder structure is preserved.
flatten Such subfolders are moved to the root of the vault. Folder permissions are preserved.
This command will reach out to the source password vault (either the current Keeper vault, remote LastPass vault or remote Thycotic/Delinea Secret Server), retrieve Team and Shared Folder file structure, and then create a local JSON file containing this structure. The filename generated locally will be called shared_folder_membership.json
.
This file can then be used for subsequently sharing folders with Keeper users and teams. The sharing operation is performed by executing the apply-membership
command.
Examples:
or
or
After executing download-membership, the resulting JSON file contains information about the teams, user-team assignments and shared folder permissions. An example file is below. This example file contains 3 teams, and 3 shared folders. The 3rd shared folder exists within a regular folder.
Command: apply-membership
Detail: Apply shared folder membership changes from a local JSON file. This command is used alongside the download-membership command.
Switches:
--full-sync force full sync of shared folder permissions. Permissions are only added by default
The apply-membership
command will look for a JSON file (defaults to shared_folder_membership.json) that contains sharing permissions.
The reason for separating the downloading and applying of membership, is so that you can apply the membership changes as new Keeper users or teams are onboarded. The apply-membership command can be run over and over, or whenever a new Keeper user account or team is created. Shared folder membership will be applied to any new corresponding user accounts and teams.
Folders can only be shared to users and teams that exist (because the public key must be used to encrypt the folder keys).
Examples:
or
Command: download-record-types
Detail: Download custom record types to a JSON file.
Switches:
--source <{keeper, thycotic}> (required)
This command will reach out to the source password vault (either Keeper or Thycotic/Delinea Secret Server), retrieve custom record types (Secret Server calls it secret templates), and then create a local JSON file containing this information. The filename generated locally will be called record_types.json.
This file can then be used for subsequently loading custom record types to Keeper. The record types loading operation is performed by executing the load-record-types
command.
--ssh-key-as-file
Thycotic/Delinea Secret Server stores SSH keys as file attachments. Keeper stores SSH keys on a record. If you would like to preserve Thycotic/Delinea Secret Server behavior (imported SSH keys from Secret Server will be stores as file attachments) use this option.
Examples:
or
Command: load-record-types
Detail: Load custom record types from a JSON file into Keeper.
Detail: Load custom record types from a local JSON file. This command is used alongside the download-record-types command.
The load_record_types
command will look for a JSON file (defaults to record_types.json) that contains custom record types and loads missing record types into Keeper.
Examples:
or
Step by step instructions are documented for migrating data and importing into Keeper from the following sources:
To export records from your vault, use the export
command. Supported export formats:
JSON
CSV
Keepass (see additional install instructions)
JSON export files contain records, folders, subfolders, shared folders, default folder permissions and user/team permissions. CSV import files contain records, folders, subfolders, shared folders and default shared folder permissions. Keepass files contain records, file attachments, folders and subfolders.
You can optionally provide the keepass encrypted file password through command line option --keepass-file-password
This flag will only apply when --format=keepass
is set. The Master Password is required for Keepass export - if none provided you will be asked during export, and your input will be masked.
Migration of CyberArk secrets to Keeper
Please see the documentation posted at the link below:
Automatic migration of your LastPass vault and shared folders
This document outlines the process for automatically and seamlessly migrating LastPass data into Keeper. Keeper supports automatic import of your LastPass vault with Master Password and MFA. Keeper also supports federated logins to LastPass from Okta/Azure/Google, and this is explained in detail below.
LastPass > Keeper Transfer Supported Data:
Transfer of Passwords
Transfer of Folders
Transfer of Shared Folders
Transfer of Shared Folder permissions (users and teams)
Transfer of custom fields, TOTP seeds
Transfer of File Attachments
The steps we recommend to importing an entire organization from LastPass to Keeper are the following:
Admin downloads the membership of the Shared Folders data to json file
Admin imports their shared folders and non-shared passwords
Admin applies shared folder membership (includes permissions) for users who already exist in Keeper
End-users migrate their vaults over using the Keeper Desktop application.
Admins continue to periodically apply membership as more users join Keeper
Note: Federated logins with SSO from Okta/Azure/Google are supported from the Keeper Desktop Application for the end-users to transfer their vaults. Keeper Commander CLI is used by the administrator and does not support federated login. Please use a LastPass admin account with a Master Password login for performing steps 1-3.
In Keeper Commander, the Keeper/LastPass Administrator will run the following:
This will perform the following 3 functions:
Download all Shared Folder information
Download Shared Folder permissions
This step downloads a file locally called "shared_folder_membership.json
" which contains the shared folder structure. The location of this file on Windows is typically C:\Users\username\shared_folder_membership.json. On Linux/Mac, it will be in the location where you run Commander.
The download-membership command basically produces a local file containing the share relationships. You can simply edit this file in a text editor and make any permission changes needed before proceeding to the next step.
In Keeper Commander, the Admin will run the following command to perform the import of shared folders and data.
The first time the import command is run, you may get the following notice that LastPass wants to verify the device from which you are connecting.
Check the email address associated with your LastPass account and click "verify" to allow Keeper to access the records in your LastPass account.
The import
command will migrate and populate regular folders, shared folders and records within the folders. This will NOT import the private folders of other users within LastPass. This step will only import the information available to the admin.
End-users will migrate their private LastPass data by using the Keeper Desktop automated import method. See this page for the end-user documentation.
Typed LastPass items are automatically imported as Keeper records with corresponding record types if your Enterprise environment has Record Types activated.
See the LastPass Item Type and corresponding Keeper Record Type in the table below.
LastPass Item Type | Keeper Record Type |
---|---|
Bank Account | Bank Account |
Credit Card | Bank Card |
Address | Address |
Driver's License | Driver's License |
Passport | Passport |
Social Security | SSN Card |
Health Insurance | Health Insurance |
Insurance | Health Insurance |
Membership | Membership |
Email Account | Login |
Instant Messenger | Login |
Database | Database Credentials |
Server | Server Credentials |
SSH Key | SSH Keys |
Software License | Software License |
See Record Types for more information about Keeper Record Types
If a folder is shared with another user or team in LastPass, the import will apply the same sharing permissions to Keeper teams with the same name, and Keeper users with the same email address.
Shared folder permissions can be re-applied and applied if a new Keeper user or team is added after the initial import.
To assign Share Permissions to your imported passwords from LastPass, use the apply-membership
command:
This will read the file called "shared_folder_membership.json
" from Step 1 and apply the shared folder permissions for any users and team which exist in the Keeper enterprise environment. This command is safe to run over and over again, and it will not generate duplicates.
Explanation: When users are invited/created through SSO or your invitation process, their public keys are created. Therefore, Keeper cannot apply membership until the users exist.
For this reason, the Keeper Admin needs to run the "apply-membership" command on a daily basis, hourly, or on demand, when users are created in Keeper.
If you would like to be notified as soon as users migrate to Keeper, use the Advanced Reporting & Alerts module in the Keeper Admin Console to set up an Alert when a user has been created.
The Keeper Admin will invite users through one of the following methods:
Just-in-time provisioning through SSO login
Invite through the Admin Console
SCIM
When the user registers to create their vault, they will generate a public/private key pair. At this point, they will be able to receive shared folders, as outlined in the next step.
For transferring the user's LastPass private folders and records, we recommend directing the user to install the Keeper Desktop application.
Here's the link to the public / latest version:
To automatically deploy Keeper Desktop to your users through group policy, see:
Once users create their Keeper vaults, they can then be added to a team and/or a folder. The next time that the Admin runs the apply-membership
command, any new Keeper users will receive access to their Shared Folders.
You can run apply-membership repeatedly as more users are onboarded to keeper. It will apply the memberships to users that exist in Keeper.
Due to the number of steps, we recommend performing a pilot test with a few users before rolling out to the entire organization.
If you have any questions please contact your Keeper sales engineer or email commander@keepersecurity.com.
If your LastPass email domain has changed and you would like to transition to a new email domain when transferring share permissions, you can use the --old-domain
and --new-domain
optional parameters. Example below:
The LastPass download-membership
applies the shared folder permissions from LastPass users to your Keeper shared folders, but the permission settings can be overridden during membership download.
To override the "manage records" and "manage users" permissions for all users on all imported shared folders, use the --permissions
or --restrictions
options.
--permissions
allows the permission(s) for all users on all imported shared folder.
--restrictions
denies the permission(s) for all users on all imported shared folders.
To set for "manage records" pass r
, for "manage users" pass u
for both use ru
You can optionally make all top level folders shared folders with specified permissions by passing the --shared
and --permissions=<PERMISSIONS>
flags.
The available permissions options are:
U - manage users permission granted
R - manage records permission granted
E - edit records permission granted
S - share permission granted
A - all permissions granted
N - no permissions granted
Use the letters corresponding to the permissions you want to grant with no spaces or characters in between.
Attachment files can be cached during import so that they do not have to be redownloaded if another import is performed.
To run the import with a file cache, add the --file-cache <DIR>
flag. Specify a directory to use as the cache.
To use the cache on a subsequent import, apply the --file-cache
flag with the same directory.
Cached attachment files are encrypted
Keeper records have a size limit of 5MB (excluding attachments). If a record from LastPass is larger than this limit, fields will be converted to a text file, starting with the largest field, until the record is smaller than the limit.
Created attachments are named in the following format:
<title of field>_<type of field>_field.txt
For example a "notes" field titled "Instructions" would be converted to an attachment titled:
Instructions_notes_field.txt
The contents of your LastPass vault can be imported into a specified folder in your Keeper vault. To do this, use the --folder
option.
You can limit the import of your LastPass vault to a specific folder in LastPass by using the --filter-folder
option. This filters the data from LastPass to ONLY the specific folder on the LastPass side.
If you believe there may be duplicate records in your vault after import, you can use the find-duplicate
feature in Commander to locate them.
If you wanted to locate duplicates based on title, login, password for example:
From the output of this report, you can gather a list of record UIDs to delete with the "rm
" command.
By default, records are imported into Shared Folders with "Can View" permission. This means that the record is only editable by the owner of the record, and any share admins that have been added to the folder.
To change the permissions of records inside a shared folder (after the import is complete), you can use the record-permission command. For example:
Automatic migration of your Delinea (Thycotic) Secret Server vault
This document outlines the process for automatically and seamlessly migrating Secret Server (Delinea/Thycotic) data into Keeper which includes private folders, shared folders, permissions, file attachments, TOTP codes. This process utilizes the Secret Server API to automate the process.
Note: A basic import capability is available on the Keeper Web Vault and Desktop App which supports Thycotic XML format. Visit the vault Settings > Import > Thycotic screen. The XML format does not include attachments or permissions. Therefore, we recommend using the automated method as described in this document.
In Secret Server admin settings, ensure Webservices are enabled
Admin -> Configuration -> Edit -> Enable Webservices
In Secret Server admin settings, ensure that "Session Timeout for Webservices" is set to a high enough value, since large vaults will take time to process. For example, 59 minutes.
In Keeper Commander, the Keeper/Thycotic Administrator will run the following:
Prior to running the above code snippet, make sure to:
Verify the base Thycotic URL in your browser
The Username is in the correct format:
If it's a AD user, the format is DOMAIN\username
otherwise username
Executing the above code snippet will perform the following 3 functions:
Download all Shared Folder information
Download Team Membership
Download Shared Folder permissions
This step downloads a file locally called "shared_folder_membership.json" which contains the team and shared folder structure.
Keeper does not yet support folders within shared folders that have different permissions than the parent.
download-membership
command provides an option --sub-folder
to control how these folders are imported.
--sub-folder=ignore
preserves folder structure. Folder permissions are ignored.
--sub-folder=flatten
folder will be moved to the root folder of the Keeper vault as its own shared folder.
Before importing records, we will first create the shared folder structure on the Keeper side. Run the below command:
The TOTP codes stored in Thycotic/Delinea Secret Server can only be retrieved by manually downloading a CSV file. The admin of Secret Server needs to go to Secret Server > Export Secrets and select the following options:
Export Type: Export All
Export Folder Path: Checked
Export TOTP Settings: Checked
Export Format: CSV
Export the file and save it to your home folder, or the folder where Keeper Commander is running. The file will be called "secrets-export.csv" by default.
In Keeper Commander, the Keeper/Thycotic Administrator will run the following command to perform the import of data using the Secret Server API:
This command will take several minutes (or more) to complete, depending on the number of vault records and users. A large Secret Server instance could take 20 minutes or more.
Commander will attempt to build the same folder structure as Secret Server in the admin's Keeper vault.
Commander will also look for the file "secrets-export.csv" in the user's home folder or current Commander folder, for the purpose of importing TOTP codes.
Note 1: This command will import and populate regular folders, shared folders and records within the folders. This will NOT import the private folders of other users within Secret Server. This step will only import the information available to the admin.
Note 2: If a Shared Folder is found within another shared folder with different permission, the shared folder will be moved to the root folder (since Keeper does not support subfolder permissions).
In Keeper Commander, the Keeper/Thycotic Administrator will run the following:
This will read the file called "shared_folder_membership.json" from Step 1 and apply the shared folder permissions for any users and team which exist in the Keeper enterprise environment. This command is safe to run over and over again, and it will not generate duplicates.
Explanation: When users are invited/created through SSO or your invitation process, their public keys are created. Therefore, Keeper cannot apply membership until the users exist.
For this reason, the Keeper Admin needs to run the "apply-membership" command on a daily basis, hourly, or on demand, when users are created in Keeper.
The Keeper Admin will invite users through one of the following methods:
Just-in-time provisioning through SSO login
Invite through the Admin Console
SCIM
When the user registers to create their vault, they will generate a public/private key pair. At this point, they will be able to receive shared folders, as outlined in the next step.
The next time that the Admin runs the apply-membership
command, any new Keeper users will receive access to their Shared Folders.
Due to the number of steps, we recommend performing a pilot test with a few users before rolling out to the entire organization.
If you have any questions please email commander@keepersecurity.com.
Automatic migration of your Keepass vault
Keeper Commander supports importing the record and folder structure directly from an encrypted Keepass file. File attachments are also supported. Make sure to first follow these instructions to install the necessary keepass modules.
You can optionally make all top level folders as shared folder object with default permissions.
For more options, see the help screen:
Automatic migration of your ManageEngine vault
Keeper supports importing the resources and connected accounts directly from a ManageEngine Password Manager Pro server. Importing file attachments from a File Store resource is also supported. You will need a ManageEngine user with API access and a generated token to use this import functionality.
Substitute https://localhost:7272
with your server URL and port. You will then need to enter your ManageEngine API token.
Automatic Migration of your Proton Pass Vault
This document outlines the steps required to seamlessly migrate your Proton Pass Vault data into Keeper.
By default, Proton Pass exports your data as a JSON File. Exporting on Proton Pass is only supported on the Proton Pass Browser Extension.
To export on Proton Pass:
Navigate to settings on your Proton Pass Browser Extension
Click on the Export tab and select Export.
This will export a zip file that contains the JSON file. Keeper commander gives you the option of providing either the zip file or the JSON file as input.
On Keeper Commander and with the exported zip file, executing the following command will import your Proton Pass Data:
Automatic migration of passwords from a CSV file
Keeper Commander supports .csv text file import using comma separated values. CSV import files can contain data for certain fields, folders, subfolders, shared folders and default shared folder permissions.
Use this order of fields shown below with commas separating each value (and no spaces around the commas). Not all fields are required; some can be left blank.
Position | Column | Value | Description / Format |
---|---|---|---|
1 | A | Folder | FolderName\Subfolder (optional) |
2 | B | Title | Name of the record (required) |
3 | C | Login (Username) | sampleuser |
4 | D | Password | samplepassword |
5 | E | Website Address (URL) | domain.com/login |
6 | F | Notes | notes about this account (optional) |
7 | G | Shared Folder Name | SharedFolderName (optional) |
8 | H | Custom Field 1 Name |
|
9 | I | Custom Field 1 Value | otpauth://totp/?secret=ABC123ABC123ABC123ABC123ABC123 |
10 | J | Custom Field 2 Name |
|
11 | K | Custom Field 2 Value | login |
Custom fields begin with the name in the 8th field, (column H). The custom field value goes in the next field (column I).
To specify subfolders, use backslash "\" between folder names
To set shared folder permission on the record, use the #edit or #reshare tags as seen below
Enclose fields in quotes for multi-line or special characters
Ensure files are UTF-8 encoded for support of international or double-byte characters
Below is an example csv file that showcases several import features including personal folders, shared folders, subfolders, special characters and multi-line fields.
To import this file as "login" records:
The resulting vault will look like this:
Here is a list of some record types (you may have more if you have custom record types, or less if you are restricting some record types):
Below is a list of all possible field types (including custom fields). You can use these as a custom field names such as $oneTimeCode
as shown below.
Folder | Title | Login | Password | Website Address | Notes | Shared Folder | Custom Field1 Name | Custom Field1 Value | Custom Field2 Name | Custom Field2 Value | Custom Field3 Name | Custom Field3 Value | Custom Field4 Name | Custom Field4 Value |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Folder1\subfolder | My Login Account | user@example.com | liu.W241Q<q$RGl9r;N1 | main google account | TeamFolder | $oneTimeCode | otpauth://totp/?secret=ABC123ABC123ABC123ABC123ABC123 | $type | login | $host | 10.0.0.1 | $url |
More advanced import options are available using the JSON Import format described in the next section.
Automatic migration of passwords from a JSON file
JSON import files can contain records, folders, subfolders, shared folders, default folder permissions and user/team permissions.
Below is a JSON import file with 2 records. The first record is added to a folder called "My Websites\\Online". The second record is added to "Social Media" and also added to a shared folder called "Shared Social".
The import file example below is an array of record objects which can import into private folders and shared folders. Note in the example that the Facebook record contains a TOTP seed which will render on the Vault user interface and Commander CLI.
Another example below first creates shared folders that are shared to users and teams, then imports records into the shared folders. The format of the file is slightly different and allows you to separate the creation of shared folder objects and records:
The format must be strict JSON or it will fail parsing. To import this file:
There are more complex import file examples that supports shared folders, folder permissions, user permissions and team permissions located in the sample_data/ folder. To import the sample JSON file into your vault, type this command:
Example 1: import.json.txt
Example 2: import_records_existing_folders.json.txt
Example 3: import_records_into_folders.json.txt
Example 4: import_shared_folders.json.txt
Example 5: import_shared_folders_and_records.json.txt
The sample file contains "permissions" objects that contain email address or team names. If the email or team name exists in your Keeper enterprise account, they will be added to the shared folder, otherwise the information is ignored.
Commands for audit logging and reporting capabilities
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Reporting Commands
Command | Explanation |
---|---|
Show users that haven't performed a specific action in a given number of days | |
Determine which record passwords have NOT been changed in X days | |
Export the enterprise audit and event logs | |
Show a customized report of audit events | |
See information about records in vaults of users across the enterprise | |
Display information about records shared with external accounts | |
Display information on managed company plans and available licenses | |
Show report of password security strength for each user in the enterprise | |
Show report of Breachwatch security scores for each user in the enterprise | |
Display information about shared records | |
Show a report of shared records | |
Show a report of user logins | |
Risk Management Reports |
command: audit-log
Detail: Download event data from the Advanced Reporting & Alerts Module ("ARAM") to your local Commander instance, and then push the events to a SIEM provider. For a fully automated process, we recommend using the cloud-based SIEM export available in the Keeper Admin Console. For more information about the automated export see this link.
The audit-log command provides a SIEM push capability if the Keeper backend servers are not able to access the target endpoint. It can also be useful if you would like to just export events locally to a JSON file. Note that a Keeper record is used for storing the state of event exports, so that repeated use of the audit-log command will pick up where it left off.
Running audit-log for the first time will take a long time to process if there is a lot of usage history with Keeper, since it's starting from the beginning of time.
Switches:
--anonymize Anonymizes audit log by replacing email and user name with corresponding enterprise user id. If user was removed or if user's email was changed then the audit report will show that particular entry as deleted user.
--target <{splunk, sumo, syslog, syslog-port, azure-la, json}> Choose export target
splunk - Export events to Splunk HTTP Event Collector
sumo - Export events to Sumo Logic HTTP Event Collector
syslog - Export events to a local file in syslog format
syslog-port - Export events in syslog format to TCP port. Both plain and SSL connections are supported
azure-la - Export events to Azure Log Analytics to custom log named Keeper_CL
json - Export events to a local file in JSON format
--record <RECORD NAME OR UID> Select a Keeper record to store the current export state. This will also contain the secrets needed to connect to the target endpoint, such as Splunk parameters.
--shared-folder-uid <SHARED FOLDER UID> Filter: Shared Folder UID(s). Overrides existing setting in config record and sets new field value.
--node-id <NODE ID> Filter: Node ID(s). Overrides existing setting in config record and sets new field value.
--days <DAYS> Filter: Max event age in days. Overrides existing "last_event_time" value in config record.
Examples:
Download all event data and push to Splunk endpoint HTTP event collector. Will be prompted to enter Splunk HEC endpoint.
Download all event data referencing the record UID and output in JSON format.
Get event data within the past 30 days for node with ID = 368009977790518, using the vault record named audit-log-json to obtain additional query parameters and update them as necessary.
Get event data for the shared-folder with UID = 8oGAJPplH2DFUQ0obwox7Q and export to Splunk HTTP Event Collector, using the custom field values set in the Splunk-Log record to both populate event-data query parameters and to provide info (e.g. HEC endpoint, credentials) needed to export to the appropriate Splunk account.
Running reports requires the ARAM add-on.
Command: audit-report
Details: Generate advanced ad-hoc customized audit event reports in raw and summarized formats.
Event Properties:
Parameters:
Limit results to rows containing specified string. Optional.
Switches:
--report-type <{raw, dim, hour, day, week, month, span}> type of report to show (Default raw)
raw - all audit events. Optionally use --report-format
to change the format (Default list)
hour - show a report summarized by hour
day - show a report summarized by day
week - show a report summarized by week
month - show a report summarized by month
span - show a table of audit events with only number of occurrences shown by default. use --columns
to add additional columns
dim - see list of all available values and details for a specified column. Include multiple columns to show detail lists one after the other. Must use --columns
--report-format <{message, fields}> choose output format (for "raw" reports only)
message - (default) show columns:
created
audit_event_type
username
ip_address
keeper_version
geo_location
message
fields - show columns:
created
audit_event_type
username
ip_address
keeper_version
geo_location
record_uid
--columns <COLUMN> decide what columns to show (ignored for "raw" reports)
available columns:
audit_event_type
username
ip_address
keeper_version
geo_location
message
created
record_uid
record_name (Requires Compliance Reports module *)
Usage: use the full switch for each column
--aggregate <{occurrences, first_created, last_created}> aggregated value. Can be repeated. (ignored for raw reports)
occurrences - show number of times the event type took place
first_created - show the time the first occurrence of the event type took place
last_created - show the time the most recent occurrence of the event type took place
Usage: use the full switch for each aggregation you would like to show
--timezone <TIMEZONE> return results for specific timezone
--limit <NUMBER OF ROWS> maximum number of returned rows (default 50, -1 for unlimited)
--order <{desc, asc}> sort order. Sorts based on the first returned column
--created <CREATED DATE> filter results by created date
Format:
use a predefined filter value from the list below:
today
yesterday
last_7_days
last_30_days
month_to_date
last_month
year_to_date
last_year
or use the following format for a custom date range:
"between %Y-%m-%dT%H:%M:%SZ and %Y-%m-%dT%H:%M:%SZ"
example: "between 2022-01-01 and 2022-06-01"
--event-type <EVENT CODE> filter by event type. See a list of all available event types here
--username <USERNAME> filter by username
--to-username <TARGET'S USERNAME> filter by event's target
--record-uid <RECORD UID> filter by record
--shared-folder-uid <SHARED FOLDER UID> filter by shared folder
--geo-location <GEO LOCATION> filter by geo location. Run the following command to get the list of available geo locations
--ip-address <IP Address> filter by IP Address
Geo location filter has format "[[City, ] State,] Country"
Example:
"El Dorado Hills, California, US"
"Bayern,DE" - Bavaria, Germany
"CA" - Canada
--ip-address <IP Address> filter by the user's IP Address. For example, to find the last 5,000 events coming from a particular IP:
--device-type <DEVICE TYPE> Keeper device/application and optional version
Device type filter has format "DeviceType[, Version]"
Example:
"Commander" Keeper Commander all versions
"Web App, 16" The Web Vault application versions "16.x.x"
--format <table, csv, json> format of the output, table is default
--max-record-details allow retrieval of additional record-detail data if not found in local cache
Examples
Display an audit report with all events, including messages for each event, showing the last 5000 events.
Display an audit report with all events, including the record UID for each event
Show all available audit event types
Display an audit report that includes the event type and username, summarized by day
Display an audit report of the number of each event type that was performed per hour today
Display UIDs of all records created or updated by user@mydomain.com within the last 30 days.
Display all occurrences of opened record events that occurred today, including the decrypted record title.
Display the last time each user accessed each record (w/ its title and associated URL) and force additional retrieval -- a potentially time- and resource-intensive process -- of each record's details (e.g., title, URL) if that data is not available locally via cache.
Command: user-report
Details: Generate ad-hoc user status report
Switches:
--format <{table,json,csv}> format of the report
--output <FILENAME> output to the given filename
--days <NUMBER OF DAYS> number of days to look back for last login date
--last-login show the last time each user logged in
Examples:
Show user login report for the past 365 days
Create a user report of the last 30 days and output it in csv format to a file named "logins.csv"
Create a report of the last time each user in the enterprise logged in and save it to the file "last-logins.csv"
Command: security-audit-report
Details: Generate a password security strength report for users of your enterprise
Report Columns:
Switches:
--format <{table,json,csv}> format of the report
--output <FILENAME> output to the given filename
--syntax-help display description of each column in the report
-n, --node name(s) or UID(s) of node(s) to filter results by
-b, --breachwatch display a BreachWatch security report (Commander v16.5.5+). Ignored if BreachWatch is not active
-su, --show-updated calculate current security audit scores for each vault and display locally (preview)
-s, --save similar to --show-updated
above, but with an additional push of the updated scores to Keeper
-st, --score-type <{strong_passwords,default}> define how users' security scores are calculated (note: setting --score-type=strong_passwords
will result in the report's summary security scores to be based solely on the number of each user's passwords deemed to be strong, identical to the value calculated and shown in the corresponding vault's Security Audit page)
--attempt-fix do a "hard" sync for vaults found to have invalid security-data. Associated security scores are reset and will be inaccurate until affected vaults can re-calculate and update their security-data
-f, --force skip confirmation prompts (non-interactive mode)
For backward-compatibility, this command does not calculate updated security scores (based on recent vault changes) by default. Subsequently, it also does not save updated security scores by default.
To change the above behavior, include either the --show-updated
flag or the --save
flag in your command call (note: if the latter flag is included, there is no need to also include the former).
Examples:
Show security audit report - password strength for each user in the enterprise
Create a security audit report and output it in json format to a file named "security_score.json"
Show a Breachwatch security report
Recalculate security audit scores, then show security audit report. Do not push changes to Keeper.
Recalculate security audit scores, show security audit report, and push changes to Keeper.
Show security audit report (using the command abbreviation), limiting the results to accounts assigned to enterprise node Node1
Show security audit scores based on the number of each user's passwords deemed to be strong and push the results to Keeper
Command: breachwatch report
or bw report
Details: Run a Breachwatch security report for all users in your enterprise
Switches:
--format <{table,csv}> format of the report
--output <FILENAME> output to the given filename
Examples:
Show Breachwatch-specific security scores
Export a Breachwatch security report to a CSV file breachwatch_report.csv located in Commander's current working directory (run the command v -v
to get this folder's full path)
Command: share-report
Details: Show a report of shared records (shared both with and by the caller)
Parameters:
Path or UID of folder containing the records to be shown in report. Optional (w/ multiple values allowed).
Switches:
--format <{table,csv}> format of the report
--output <FILENAME> output to the given filename
-r, --record <RECORD NAME OR UID> identify a specific record to show report for
-e, --email <USER'S EMAIL OR TEAM NAME> identify user or team to show shared record report for
-o, --owner display record's owner
--share-date display date when record was shared. Only used with owner report ( --owner
switch). Only available to users with permission to execute reports for their company
-sf, --shared-folders display display shared folder detail information. If omitted then records.
-v, --verbose show record UID with report
-f, --folders limit report to shared folders (excludes shared records)
-tu, --show-team-users expand team-share info to include individual members for each shared folder or record in the report
Examples:
Display shared records report
Display share report for the record with the given UID
Output a shared records report in csv format
Display a report of records shared with "john.doe@gmail.com" and show the original owner, as well as when it was shared
Show a report that includes ownership information and detailed share permissions for each shared record contained within the folder named "Team1_Folder" and the folder w/ UID = Za2aspMQG9De5In28sc3KA
Display a list of shared-folders in the current user's vault, along with the teams and other users who have access to each shared-folder
Command: shared-records-report
or srr
Details: Display information about shared records (Note: the displayed information is limited to records shared by the caller with other users, i.e., this excludes records shared with the caller by other users. To include both types of records, see share-report
command)
Parameters:
Path or UID of folder containing the records to be shown in report. Optional (w/ multiple values allowed).
Switches:
--format
<{json,csv,table}> format of the report
--output <FILENAME>
output to filename provided. Ignored for "table" format
--all-records
include all records into report. Only owned records are reported by default
--show-team-users
or -tu
show members of team for records shared via share team folders
Examples:
Display information about shared records in table format
Display information about shared records in csv format
Display information about records shared with individual members of all teams with whom those records are shared (via shared-folders)
Export information about shared records found in folders "My Shares", "Team1/Shares" (folders identified by their paths) and "_qsA0AA0XwJkeTVQdijmEg" (folder identified by its UID) to a JSON-formatted file named shared_records.json. In this case -- because containing folders are explicitly provided in the command call -- the records included in the resulting report will be limited to only those found within the specified folders (either as a child of the folder, or as a child of a subfolder, etc.)
Command: external-shares-report
Details: Display folders and records shared with users that are outside of the enterprise. Optionally, delete all external shares.
Switches:
--format {table,json,csv} output format
--output FILENAME output to filename. Ignored when using table format
-a, --action {remove,none} action to apply to external shares; use 'remove' to delete the shares with confirmation, 'none' if omitted
-t, --share-type {direct,shared-folder,all} show only individually shared records (direct) or shared folders, 'all' if omitted
-f, --force apply action w/o confirmation
-r, --refresh-data Sync and fetch latest data before running report
Examples:
Display all externally shared folders and records
Output all externally shared folders and records as share_report.csv
Remove all externally shared folders and records (with confirmation prompt)
Remove all externally shared individual records, but not shared folders
Remove all externally shared folders, but not individual records
Remove all externally shared folders and records without confirmation prompt
Sync with Keeper to fetch latest data, then generate the share report
Command: msp-legacy-report
Details: Display information about available managed company licenses
Switches:
--format <{json. table, csv}> format of the report
--range <{today, yesterday, last_7_days, last_30_days, month_to_date, last_month, year_to_date, last_year}> timeframe of license usage
--from <FROM DATE> start date of time range to display license usage. Use with audit type ( --type audit
), and without --range
flag
format: YYYY-mm-dd
ex. 2021-07-08
--to <TO DATE> end date of time range to display license usage. Use with audit type ( --type audit
), and without --range
flag
format: YYYY-mm-dd
ex. 2021-07-08
--output <FILENAME> file to output the report to
Examples:
Show a report of the currently allocated and remaining company licenses
Show a report of licenses usage over the last 30 days
Show a report of licenses usage from the first of February to the first of March 2021
Output a report of current licenses usage to a file named "licenses.csv" in csv format
This advanced report requires the Advanced Reporting & Alert module, and Compliance module. For more information see the dedicated Compliance Reports Page
Command: aging-report
Details: Determine which record passwords have NOT been changed in a specific amount of time. This report takes advantage of the advanced reporting capabilities of the Enterprise platform, as well as the compliance data which is able to decrypt record title for privileged admins.
Switches:
-r, --rebuild rebuild the record database
--delete deletes the local database cache containing encrypted compliance record data
-nc, --no-cache remove any local non-memory storage of data upon command completion
-s, --sort <{owner, title, last_changed}> sort output by chosen field
--format <{table,json,csv}> format of the report
--output <FILENAME> output to the given filename
--period <TIME PERIOD> look for records that have a password that hasn't changed in this period. Not valid with --cutoff-date
switch
--cutoff-date <DATE> limit report to records whose passwords have not been changed since this date. Not valid with --period
switch
--username <USERNAME> report expired passwords for the given user
--exclude-deleted omit deleted records from the report (note: adding this flag may result in the need for additional data to be retrieved and subsequent longer command execution times)
--in-shared-folder Limit report to records in shared folders
Examples:
Rebuild the audit and compliance data locally
Generate password aging report for passwords not updated in over 1 year period
Generate password aging report for a specific user's passwords not updated in over 3 month period
Generate password aging report that ignores any records currently in each vault's trash bin
List all shared-folder records whose passwords have not been changed in the last 3 months
List all records whose passwords were last modified prior to December 31, 2020
Command:
risk-management
Details: Generate Risk Management reports
Switches:
--format <{
table,json,csv
}>
format of the report
--output <FILENAME>
if you want to save the results to a file
Examples:
Requires ARAM add-on
Command: action-report
Details: Generate a report and/or take action on users in a particular status or that have not performed an action within in a given time period. The default timeframe is the last 30 days unless otherwise specified using --days-since
.
Switches:
--format <{
table,json,csv
}>
format of the report
--output <FILENAME>
if you want to save the results to a file
-d <NUMBER OF DAYS>
or --days-since <NUMBER OF DAYS>
look back this many days for targeted action (default value of 30 days is used if omitted)
-t
or --target <no-logon, no-update, locked, invited, no-security-question-update, blocked>
user status that you want to report or act on
--columns
comma-delimited list of columns to show on report. Supported columns: {2fa_enabled, team_count, status, transfer_status, alias, role_count, node, teams, name, roles}
-a
or --apply-action <lock, delete, transfer, none>
used after target, the action to take on each user account that matches the target user status
--target-user
(used with transfer action above) the destination account to which vaults are transferred
-n
or --dry-run
show accounts that fall into the action-status category specified via the --target/-t
switch and the corresponding administrative action to be applied (specified via the -a/--apply-action
switch) without actually applying the action
-f
or --force
perform the administrative action specified via the -a/--apply-action
option without being prompted for confirmation (applies only to "delete" and "transfer" administrative actions)
Show a list of users that haven't logged in within the last 45 days
Show a list of user accounts that have remained in a locked status for 60+ days
Show a list of users who have been in an invited status for 15+ days.
Show a list of users that haven't updated any records in the last 35 days
Show users that have not set/changed their account security questions within the default timeframe (the last 30 days)
Generate a report of users who have not logged in to their account within the last 30 days (the default timeframe when none is specified) that includes the 2fa status, # of teams assigned, # of roles assigned, assigned node, and full name for each user in the report.
Delete any users whose accounts have been in invited status for more than 90 days:
Transfer the vaults of all users that have been locked for 90 days to a designated vault.
Lock all users who haven't logged in within 180 days.
Requires Compliance Reporting add-on
For more information see the dedicated Compliance Reports Page
Command: compliance-report
Details: Generate a report of the sharing status of records across the enterprise.
This report relies on a cache which is built the first time the command is called. It may take some time for the first command in a session to complete depending on the size of your enterprise.
Switches:
--format <{table,json,csv}> format of the report
--output <FILENAME> output to the given filename
-u, --username <USERNAME> filter to records of the given user. Use multiple times for multiple users
-n, --node <NODE NAME or ID> filter to records in vaults in the given node
-jt, --job-title <JOB TITLE> filter to records in vaults owned by users with the given job title. Use multiple times for multiple titles
--record <RECORD NAME OR UID> show only the given record. Use multiple times for multiple records
--team <TEAM NAME> show only users in the given team. Use multiple times for multiple teams
--url <URL> show only records with the given URL. Use multiple times for multiple URLs
--shared show only shared records
--deleted-items show only deleted records (not valid with --active-items
flag)
--active-items show only active records (not valid with --deleted-items
flag)
-r, --rebuild refresh the cached records used for this report
-nr, --no-rebuild prevent stale cache refresh if cache exists (invalid with --rebuild
flag)
-nc, --no-cache disable persistent local caching of underlying report data
Examples:
Show the sharing status of all records for all users in the enterprise
show the sharing status of records in the vault of user: "user@company.com"
Show the sharing status of records in vaults owned by managers in Chicago
Show the sharing status of only shared records owned by "user@company.com"
Show the sharing status of record w/ title "AWS MySQL Administrator" based on cached data if present
Show the sharing status of all active records in the enterprise
Requires Compliance Reporting add-on
For more information see the dedicated Compliance Reports Page
Command: compliance team-report
Details: Generate a report of teams with access to each shared-folder containing at least 1 record, along with their corresponding edit and share permissions
Switches:
--format <{table,json,csv}> format of the report
--output <FILENAME> output to the given filename
-n, --node <NODE NAME or ID> filter to records in vaults in the given node
-r, --rebuild refresh the cached records used for this report
-nr, --no-rebuild prevent stale cache refresh if cache exists (invalid with --rebuild
flag)
-nc, --no-cache disable persistent local caching of underlying report data
-tu, --show-team-users show individual members of each team in the report
Examples:
Show the compliance team report
Save a CSV file output of the compliance team report
Show individual users assigned to each team in the report
Requires Compliance Reporting and ARAM add-ons
For more information see the dedicated Compliance Reports Page
Command: compliance record-access-report
or compliance rar
Details: Generate a report showing all records that each specified user has accessed or can currently access
Parameters:
Username(s) or ID(s). Set to "@all" to run the report for all users
Switches:
--format <{table,json,csv}> format of the report
--output <FILENAME> output to the given filename
-n, --node <NODE NAME or ID> filter to records in vaults in the given node
-r, --rebuild refresh the cached records used for this report
-nr, --no-rebuild prevent stale cache refresh if cache exists (invalid with --rebuild
flag)
-nc, --no-cache disable persistent local caching of underlying report data
--report-type select type of record-access data to include in report (Optional. Defaults to "history" if omitted). Set to "vault" to view currently-accessible records, "history" to view only records previously-accessed
--aging include aging data (e.g., last modified, created) for each record in the report
Examples:
Show list of all records that user@company.com has ever accessed
Export a CSV file listing all records currently in each user's vault for all users
Generate report of all records currently accessible by user1@company.com and user2@company.com, showing when each record was created, last modified, and last rotated
Commander supports integration with popular SIEM solutions such as Splunk, Sumo and general Syslog format. For more general reporting of events, we recommend using the audit-report
command. For pushes of event data into on-prem SIEM, the audit-log
command is a good choice because it automatically tracks the last event exported and only sends incremental updates. The list of over 100 event types is documented in our Enterprise Guide:
https://docs.keeper.io/enterprise-guide/event-reporting
Using Commander for SIEM integration works well in an on-prem environment where the HTTP event collector is only available within your network. The Keeper Admin Console version 13.3+ is capable of integrating our backend event data into your SIEM solution but it requires that you are utilizing a cloud-based SIEM solution. If you need assistance in integrating Keeper into your SIEM solution without Commander, please contact our business support team at business.support@keepersecurity.com.
Commander can export all event logs to a local file in syslog format, or export data in incremental files. A Keeper record in your vault is used to store a reference to the last event
To export all events and start tracking the last event time exported:
This creates a record in your vault (titled "Audit Log: Syslog" in this example) which tracks the timestamp of the last exported event and the output filename. Then the event data is exported to the file in either text or gzip format.
Each subsequent audit log export can be performed with this command:
or from the shell:
To automate the syslog event export every 5 minutes, create a JSON configuration file such as this:
Then run Commander using the config parameter. For example:
Keeper can post event logs directly to your on-prem or cloud Splunk instance. Please follow the below steps:
Login to Splunk enterprise
Go to Settings -> Data Inputs -> HTTP Event Collector
Click on "New Token" then type in a name, select an index and finish.
At the last step, copy the "Token Value" and save it for the next step.
Login to Keeper Commander shell
Next set up the Splunk integration with Commander. Commander will create a record in your vault that stores the provided token and Splunk HTTP Event Collector. This will be used to also track the last event captured so that subsequent execution will pick up where it left off. Note that the default port for HEC is 8088.
You can find the record UID of the Splunk record for subsequent audit log exports:
Each subsequent audit log export can be performed with this command:
or from the shell:
To automate the push of Splunk events every 5 minutes, create a JSON configuration file such as this:
Then run Commander using the config parameter. For example:
Keeper can post event logs directly to your Sumo Logic account. Please follow the below steps:
Login to Sumo Logic
Go to Manage Data -> Collection
Click on Add Collector -> Hosted Collector then Add Source -> HTTP Logs & Metrics
Name the collector and Save. Any other fields are default.
Note the HTTP Source Address which is the collector URL
Login to Keeper Commander shell
Next set up the Sumo Logic integration with Commander. Commander will create a record in your vault that stores the HTTP Collector information. This will be used to also track the last event captured so that subsequent execution will pick up where it left off.
When asked for “HTTP Collector URL:” paste the URL captured from the Sumo interface above.
After this step, there will be a record in your vault used for tracking the event data integration. You can find the record UID of the Sumo record for subsequent audit log exports:
Each subsequent audit log export can be performed with this command:
or from the shell:
To automate the push of Sumo Logic events every 5 minutes, create a JSON configuration file such as this:
Then run Commander using the config parameter. For example:
Commander can export all event logs to a local file in JSON format. The local file is overwritten with every run of Commander. This kind of export can be used with conjunction with other application that process the file. A Keeper record in your vault is used to store a reference to the last event.
To export all events and start tracking the last event time exported:
This creates a record in your vault (titled "Audit Log: JSON" in this example) which tracks the timestamp of the last exported event and the output filename. Then the event data is exported to the file.
Each subsequent audit log export can be performed with this command:
or from the shell:
To automate the JSON event export every 5 minutes, create a JSON configuration file such as this:
Then run Commander using the config parameter. For example:
Keeper can post event logs directly to your Azure Log Analytics workspace. Please follow the below steps:
Login to Azure Portal and open Log Analytics workspace
Go to Settings -> Advanced settings
Note the Workspace ID and Primary or Secondary key
Login to Keeper Commander shell
Next set up the Log Analytics integration with Commander. Commander will create a record in your vault that stores the Log Analytics access information. This will be used to also track the last event captured so that subsequent execution will pick up where it left off.
When asked for “Workspace ID:” paste Workspace ID captured from the Advanced settings interface above. When asked for “Key:” paste Primary or Secondary key captured from the Advanced settings interface above.
After this step, there will be a record in your vault used for tracking the event data integration. You can find the record UID of the Log Analytics record for subsequent audit log exports:
Each subsequent audit log export can be performed with this command:
or from the shell:
To automate the push of events to Azure Log Analytics every 5 minutes, create a JSON configuration file such as this:
Then run Commander using the config parameter. For example:
Learn about reporting with Commander
Commander provides the ability to run a variety of reports using event data and compliance data.
A few examples of the types of reports that Commander can run include the following:
Find users that have not logged in for X days
See the last time each user last logged in
Find users that have not created or updated any records in X days
See all record UIDs that have been accessed by a user
Determine which shared folders that a team has access to
Determine which record passwords have NOT been changed in X days
All reports in Commander can be saved to a file. To do this, add the following options to any report command:
--format
This option tells Commander what form to return the report in. The options are json
, csv
, and table
(which is the default view)
--output
This option tells Commander the name of the file to save the report output to. If the given file does not exist, it will be created.
Save a report as a CSV for use with Microsoft Excel or Google Sheets.
Save a report as a json file for use with scripts
Learn more about the reports that Commander can run. Click an option from this list to see the command documentation.
Command | Explanation |
---|---|
Show users that haven't performed a specific action in a given number of days | |
Display a report of password changes and search for records that have NOT been changed | |
Export the enterprise audit and event logs | |
Show a customized report of audit events | |
See information about records in vaults of users across the enterprise | |
Display information on managed company plans and available licenses | |
Show report of password security strength for each user in the enterprise | |
Display information about shared records | |
Show a report of shared records in the logged-in Keeper vault | |
Show a report of user logins |
Requires the ARAM add-on
By default this looks back 30 days (results are all users that have not logged in in 30 days). The number of days to look back for can be changed with the flag: --days X
where "X" is the number of days to use.
To include more details, such as the user's team(s) and Node run user-report
without --last-login
Requires the ARAM add-on
By default this looks back 30 days (results are all users that have not created or updated records in 30 days). The number of days to look back for can be changed with the flag: --days X
where "X" is the number of days to use.
Requires ARAM add-on and Compliance Reports add-on
Replace <USERNAME> with the username or email address of the user to see access history of.
Requires Compliance Reports add-on
Requires Compliance Reports add-on
Commands related to Admin Console and Enterprise Management functions
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Enterprise Management Commands
Command | Explanation |
| Display enterprise information |
| Manage enterprise users |
| Manage enterprise roles and policies |
| Manage enterprise teams |
| Manage enterprise nodes |
Populate user and team vaults with predetermined records | |
| Download & decrypt enterprise data |
Approve queued teams and users provisioned by SCIM or Active Directory Bridge | |
Approve SSO Cloud devices that are pending from end-users | |
Create a new user and vault, and add a record to the current vault with that user's credentials | |
Transfer an account to another user | |
Manage SSO Cloud Automator for Device Approvals | |
Manage SCIM endpoints | |
Manage Audit Alerts |
Command: enterprise-info
or ei
Detail: Display information about your enterprise in a tree structure
Parameters:
Text to search for. Can apply to users, teams, and roles
Switches:
-n
, --nodes display nodes
--node
<NODE> show tree structure from a specified node
-u
, --users display user list
-t
, --teams display team list
-r
, --roles display role list
-v
, --verbose show ids with output
--format
<{table, csv, json}> format to show output
table - show information in a table layout
csv - output information in CSV format
json - output information in JSON format
--output
<OUTPUT FILE> a file to write the output to
--columns
<COLUMNS> columns to include in the output. Given as comma separated list. Available columns depends on type of data being viewed
Users
name
status
transfer_status
node
team_count
teams
role_count
roles
alias
2FA status
Teams
restricts
node
user_count
users
queued_user_count
queued_users
Roles
is_visible_below
is_new_user
is_admin
node
user_count
users
Nodes
parent_node
user_count
team_count
teams
role_count
roles
provisioning
Examples:
Display the enterprise name and node structure
Search the enterprise for users named "John Doe"
Output a list of teams in the enterprise to a CSV file
Display a list of roles, and only show if they are an admin role and how many users are in the role
See the node tree structure starting from the Node named "Keeper Security" Give this the root node to see the entire organization's node tree
Command: enterprise-user
or eu
Detail: Manage an enterprise user
Parameters:
User's UID or email address.
Note: you can use the following command to see a list of users in the enterprise:
ei --users
Switches:
--expire
expire the user's master password
--extend
extend vault transfer consent for 7 days. Supports the following pseudo users: @all
--lock
lock the user's account
--unlock
unlock the user's account. Supports the following pseudo users: @all
--disable-2fa
disable 2fa for the user
--add
invite the given email address to create a vault in the enterprise (only works with email as parameter)
--invite
send an invite to the given email address. Can be sent to previously invited users
--delete
delete the user from the enterprise. Be careful as this will also delete all of their records, both owned and shared to others.
--name
<NAME> set a name to be used as the user's display name
--node
<NODE NAME OR UID> add the user to a node with the specified name or UID. To view a list of your nodes, use enterprise-info --nodes
--add-role
<ROLE NAME OR UID> add the user to a role with the specified name or UID. To view a list of roles, use enterprise-info --roles
. Supports the following pseudo users: @all
--remove-role
<ROLE NAME OR UID> remove the user from the role with the specified name or UID
--add-team
<TEAM NAME OR UID> add the user to the team with the specified name or UID. To view a list of teams, use enterprise-info --teams
--remove-team
<TEAM NAME OR UID> remove the user from the team with the specified name or UID. To view a list of teams, use enterprise-info --teams
--add-alias
<EMAIL> Add an alias, in the form of an email address, to a user. The alias added will become the "primary" email for the user. Applying the command to an existing alias will set it as primary. Note that this command is only permitted on reserved domains.
--delete-alias
<EMAIL> delete an email alias for a user
-f
, --force do not prompt for confirmation
-v
, --verbose debug output which includes IDs and other data
Examples:
Show details of user "John.Doe@gmail.com"
For the user with the given UID, add them to the Chicago node and the "Chicago Engineering" team
Send an invite to "Jane.Doe@gmail.com" to open a vault in the enterprise
Lock the account with the given UID
Add an alias for a user who changed their name and set as primary
Add all enterprise users to the "Employee" role
Command: enterprise-role
or er
Detail: Manage an enterprise role or enforcement policy
Note: you can use the following command to see a list of roles in the enterprise:
ei --roles
Usage: er <ROLE>
Parameters:
<ROLE> Name or UID of role(s). Separate with space to use multiple
Switches:
--add
add a new role to the enterprise
--delete
delete the role
--add-user
<USER NAME OR UID> add a user to the role. Use with --add
--remove-user
<USER NAME OR UID> remove a user from the role
--visible-below
<{on,off}> make a role visible or invisible to roles beneath it
--new-user
<{on,off}> make new users assigned to this role
--node
<NODE NAME OR UID> the node to add the role to
--name
<NAME> name the role
--add-admin
<NODE> set node to be administered by the specified role(s)
--remove-admin
<NODE> unset node administered by the specified role(s)
--cascade
<{on,off}> use with --add-admin
to extend admin-privileges for the specified role(s) to child nodes as well (if 'on')
--enforcement <POLICY>:<VALUE>, --enforcement <POLICY>:$FILE=<PATH TO FILE WITH VALUE>
set the enforcement policy for the given role (using either the literal policy value -- e.g., "True", "e", 10 -- or a reference to a file containing that value). See the list of available enforcement policies in the 2nd tab of the table below.
--copy
make a duplicate role with no users
--clone
make a duplicate role with the same users as the original
--add-team
, -at <TEAM NAME> add a team to the given role
--add-privilege
, -ap <PRIVILEGE NAME> add an admin privilege to the role
--remove-privilege
, -rp <PRIVILEGE NAME> remove an admin privilege to the role
-v
, --verbose show ids with output, including all available enforcement policies
-f
, --force
do not prompt for confirmation (non-interactive mode)
Examples:
Show details about the "Keeper Administrator" role including all enforcements
Show details about the role with the given UID and the "Engineer Team Lead" role
Add a new role named "Onboarding" and make new users automatically assigned to this role
Make user John Dow admin of the role with the given UID and all child roles
Rename the "PM" role to "Product Manager"
Add the three nodes with given UIDs to the "Chicago" node
Create a copy of the role in the "Chicago" node
Use the --enforcement
switch to edit enforcement policies on the given role. Pass a policy key and corresponding value to the switch in order to change the enforcement.
Alternatively, set a role enforcement policy to the value specified in an external file.
Example restricting the "Engineering" role to access import records.
The available enforcement policies are listed below.
Enforcement Policy Key | Type |
MASTER_PASSWORD_MINIMUM_LENGTH |
|
MASTER_PASSWORD_MINIMUM_SPECIAL |
|
MASTER_PASSWORD_MINIMUM_UPPER |
|
MASTER_PASSWORD_MINIMUM_LOWER |
|
MASTER_PASSWORD_MINIMUM_DIGITS |
|
MASTER_PASSWORD_RESTRICT_DAYS_BEFORE_REUSE |
|
REQUIRE_TWO_FACTOR |
|
MASTER_PASSWORD_MAXIMUM_DAYS_BEFORE_CHANGE |
|
MASTER_PASSWORD_EXPIRED_AS_OF |
|
MINIMUM_PBKDF2_ITERATIONS |
|
MAX_SESSION_LOGIN_TIME |
|
RESTRICT_PERSISTENT_LOGIN |
|
STAY_LOGGED_IN_DEFAULT |
|
RESTRICT_SHARING_ALL |
|
RESTRICT_SHARING_ENTERPRISE |
|
RESTRICT_SHARING_ALL_OUTGOING |
|
RESTRICT_SHARING_ENTERPRISE_OUTGOING |
|
RESTRICT_EXPORT |
|
RESTRICT_FILE_UPLOAD |
|
REQUIRE_ACCOUNT_SHARE |
|
RESTRICT_SHARING_ALL_INCOMING |
|
RESTRICT_SHARING_ENTERPRISE_INCOMING |
|
RESTRICT_SHARING_RECORD_WITH_ATTACHMENTS |
|
RESTRICT_IP_ADDRESSES |
|
REQUIRE_DEVICE_APPROVAL |
|
REQUIRE_ACCOUNT_RECOVERY_APPROVAL |
|
RESTRICT_VAULT_IP_ADDRESSES |
|
TIP_ZONE_RESTRICT_ALLOWED_IP_RANGES |
|
AUTOMATIC_BACKUP_EVERY_X_DAYS |
|
RESTRICT_OFFLINE_ACCESS |
|
SEND_INVITE_AT_REGISTRATION |
|
RESTRICT_EMAIL_CHANGE |
|
RESTRICT_IOS_FINGERPRINT |
|
RESTRICT_MAC_FINGERPRINT |
|
RESTRICT_ANDROID_FINGERPRINT |
|
RESTRICT_WINDOWS_FINGERPRINT |
|
LOGOUT_TIMER_WEB |
|
LOGOUT_TIMER_MOBILE |
|
LOGOUT_TIMER_DESKTOP |
|
RESTRICT_WEB_VAULT_ACCESS |
|
RESTRICT_EXTENSIONS_ACCESS |
|
RESTRICT_MOBILE_ACCESS |
|
RESTRICT_DESKTOP_ACCESS |
|
RESTRICT_MOBILE_IOS_ACCESS |
|
RESTRICT_MOBILE_ANDROID_ACCESS |
|
RESTRICT_MOBILE_WINDOWS_PHONE_ACCESS |
|
RESTRICT_DESKTOP_WIN_ACCESS |
|
RESTRICT_DESKTOP_MAC_ACCESS |
|
RESTRICT_CHAT_DESKTOP_ACCESS |
|
RESTRICT_CHAT_MOBILE_ACCESS |
|
RESTRICT_COMMANDER_ACCESS |
|
RESTRICT_TWO_FACTOR_CHANNEL_TEXT |
|
RESTRICT_TWO_FACTOR_CHANNEL_GOOGLE |
|
RESTRICT_TWO_FACTOR_CHANNEL_DNA |
|
RESTRICT_TWO_FACTOR_CHANNEL_DUO |
|
RESTRICT_TWO_FACTOR_CHANNEL_RSA |
|
TWO_FACTOR_DURATION_WEB |
|
TWO_FACTOR_DURATION_MOBILE |
|
TWO_FACTOR_DURATION_DESKTOP |
|
RESTRICT_TWO_FACTOR_CHANNEL_SECURITY_KEYS |
|
TWO_FACTOR_BY_IP |
|
RESTRICT_DOMAIN_ACCESS |
|
RESTRICT_DOMAIN_CREATE |
|
RESTRICT_HOVER_LOCKS |
|
RESTRICT_PROMPT_TO_LOGIN |
|
RESTRICT_PROMPT_TO_FILL |
|
RESTRICT_AUTO_SUBMIT |
|
RESTRICT_PROMPT_TO_SAVE |
|
RESTRICT_PROMPT_TO_CHANGE |
|
RESTRICT_AUTO_FILL |
|
RESTRICT_CREATE_FOLDER |
|
RESTRICT_CREATE_FOLDER_TO_ONLY_SHARED_FOLDERS |
|
RESTRICT_CREATE_IDENTITY_PAYMENT_RECORDS |
|
MASK_CUSTOM_FIELDS |
|
MASK_NOTES |
|
MASK_PASSWORDS_WHILE_EDITING |
|
GENERATED_PASSWORD_COMPLEXITY |
|
GENERATED_SECURITY_QUESTION_COMPLEXITY |
|
RESTRICT_IMPORT |
|
DAYS_BEFORE_DELETED_RECORDS_CLEARED_PERM |
|
DAYS_BEFORE_DELETED_RECORDS_AUTO_CLEARED |
|
ALLOW_ALTERNATE_PASSWORDS |
|
RESTRICT_CREATE_RECORD |
|
RESTRICT_CREATE_RECORD_TO_SHARED_FOLDERS |
|
RESTRICT_CREATE_SHARED_FOLDER |
|
RESTRICT_LINK_SHARING |
|
RESTRICT_SHARING_OUTSIDE_OF_ISOLATED_NODES |
|
RESTRICT_SHARING_RECORD_TO_SHARED_FOLDERS |
|
DISABLE_SETUP_TOUR |
|
RESTRICT_PERSONAL_LICENSE |
|
DISABLE_ONBOARDING |
|
DISALLOW_V2_CLIENTS |
|
RESTRICT_IP_AUTOAPPROVAL |
|
SEND_BREACH_WATCH_EVENTS |
|
RESTRICT_BREACH_WATCH |
|
RESEND_ENTERPRISE_INVITE_IN_X_DAYS |
|
MASTER_PASSWORD_REENTRY |
|
RESTRICT_ACCOUNT_RECOVERY |
|
KEEPER_FILL_HOVER_LOCKS |
|
KEEPER_FILL_AUTO_FILL |
|
KEEPER_FILL_AUTO_SUBMIT |
|
KEEPER_FILL_MATCH_ON_SUBDOMAIN |
|
KEEPER_FILL_AUTO_SUGGEST |
|
RESTRICT_PROMPT_TO_DISABLE |
|
RESTRICT_HTTP_FILL_WARNING |
|
RESTRICT_RECORD_TYPES |
|
ALLOW_SECRETS_MANAGER |
|
REQUIRE_SELF_DESTRUCT |
|
MAXIMUM_RECORD_SIZE |
|
ALLOW_PAM_ROTATION |
|
ALLOW_PAM_DISCOVERY |
|
RESTRICT_IMPORT_SHARED_FOLDERS |
|
REQUIRE_SECURITY_KEY_PIN |
|
DISABLE_CREATE_DUPLICATE |
|
Examples for each value type
Command: enterprise-team
or et
Detail: Manage enterprise teams
Parameters:
Team name or id
Note: you can use the following command to see a list of teams in the enterprise:
ei --teams
Switches:
--add
add a new team to the enterprise
--delete
delete the team
--add-user
<USER NAME OR UID> add a user to the team
--remove-user
<USER NAME OR UID> remove a user from the team
--node
<NODE NAME OR UID> the node to add the team to
--name
<NAME> name the team
--approve
approve a queued team. Queued teams are typically created by SCIM requests which still need encryption keys to be created. Therefore they remain in a queued state until the admin logs into the Admin Console or this command is executed.
--restrict-edit
<{on,off}> decide if users in this team can edit records
--restrict-share
<{on,off}> decide if users in this team can share records
--restrict-view
<{on,off}> decide if users in this team can view record passwords
--hide-shared-folder
, -hsf <{on,off}> flag to determine if users in this team can see shared folders
--add-role, -ar <ROLE NAME> add a role to the given team
-v, --verbose show ids with output
Examples:
Show details of "Chicago Engineering" team
Show details for "Chicago Engineering" and "Legal" teams
Add a new team named "Chicago Product" in the "Chicago" node, and restrict users in the team from editing records
Change the name of the team with the given UID to "El Dorado Hills Engineering"
Command: enterprise-node
or en
Detail: Manage enterprise nodes
Parameters:
Node name or UID
Note: you can use the following command to see a list of nodes in the enterprise:
ei --nodes
Switches:
--add
add a new node to the enterprise
--delete
delete the node. Note this won't be allowed until all objects from the node are deleted.
--parent
<NODE NAME OR UID> make given node the parent of this node
--name
<NAME> set node's display name
--wipe-out
delete all nodes, roles, users, and teams under the node. Does not delete the node itself. Be careful with this command.
--toggle-isolated
make node visible or invisible to people in other nodes
--invite-email
<FILE_NAME> Sets invite email template from file. Saves current template if file does not exist. dash (-) use stdout. See Custom Emails section below.
--logo-file
<FILE_NAME> Sets company / node logo using local image file (max size: 500 kB, min dimensions: 10x10, max dimensions: 320x320)
Examples:
Show details for the "Chicago" node
For the three nodes: "Chicago", "El Dorado Hills" and node with the given UID, change the parent node to node "NA"
Add a new node named "Cork" under the "EMEA" node
Delete all nodes, roles, users, and teams from under the "APAC" node
Make the "Chicago" node invisible (if currently visible) or visible (if currently invisible) to people in other nodes
Customize the appearance of invite emails and vault UI by using the "chicago_logo.jpg" file in the current user's $HOME directory as the logo image for the "Chicago" node.
The --invite-email
switch allows you to set the custom email template per node.
Similar to how email templates can be customized on the web admin console, custom email templates on the CLI supports customization of the following four attributes:
Subject
Message Heading
Message Body
Download Button Text
Custom email templates can be defined in a .txt
file in the following format:
Custom Emails can also be formatted using markdown syntax, for more information please refer to this page.
Suppose there are company branches in Chicago and Tokyo with its respective nodes Chicago
and Tokyo
. Ideally, you want the invitation emails to be in its native language:
Invitation emails sent to the Chicago Branch should be in its native language English
Invitation emails sent to the Tokyo Branch should be in its native language Japanese
The --invite-email
switch makes this possible by enabling you to set the desired email template per node.
First, I define the custom email templates for both of my branches: Chicago
and Tokyo
Next, I set the appropriate email template for each node:
On windows, file paths can be specified either in quotations or double backslash. Either of the following file paths are valid:
"C:\users\file.txt"
or c:\\users\\file.txt
When sending invitation emails, users will receive the following emails based on their branch location:
Command: enterprise-push
Detail: Populate a vault with a set of default records
Parameters:
File name of file with template records. File must be JSON format.
Switches:
--syntax-help
show example file format and template parameters
--team
<TEAM NAME OR UID> team to assign records to
--email
<USER EMAIL OR UID> user to assign records to
Examples:
Send records templated in the "office-codes.json" file to every user in the "Chicago Office" team
Send records templated in the "default.json" file to user "Jane.Doe@gmail.com"
See the syntax help
File Format
The "enterprise-push" command uses Keeper JSON record import format.
Example JSON file:
Supported template parameters:
An easy way to find the proper JSON structure is to export some data from your Keeper vault in JSON format. Then, modify the file as required for creating an import file.
To export JSON data for creating a template:
Create an empty folder for storing templates. e.g. "Templates"
Create records in that folder
export
the folder as JSON using the below command
Optional: edit the JSON file to delete the following properties: "uid", "schema", "folders" not used by enterprise-push
command
The template JSON file should be either array of records or an object that contains a property "records" containing an array of records.
Command: enterprise-down
or ed
Detail: Download & decrypt enterprise data locally.
When there is an active instance of Commander running and a change is made on the admin console or another instance of commander, the enterprise-down command can be used to download & decrypt the latest enterprise data locally.
Example:
Suppose a new user is added on the Admin Console while an active commander session is running, executing the following command on the running commander session will download and decrypt the latest changes locally:
Command: team-approve
Detail: Enable or disable automatic team approval or user approval to teams
When using a provisioning method such as Keeper Bridge or SCIM, new teams and users that have not yet activated their vault are queued for approval. Use this command to enable or disable automatic approval of provisioned teams or users.
Switches:
--team
approve teams
--email
approve team users
--restrict-edit
<{on, off}> restrict or allow editing records in approved teams
--restrict-share
<{on, off}> restrict or allow sharing records in approved teams
--restrict-view
<{on, off}>restrict or allow viewing record passwords in approved teams
Examples:
Sync down any pending Enterprise Team approvals
Automatically approve queued provisioned teams
Automatically approve queued provisioned users
Automatically approve queued provisioned teams and don't allow users in those teams to edit records
Command: device-approve
Detail: Approve cloud SSO devices
Parameters:
User's email or device ID to approve or blank to see a list of pending devices
Switches:
-r
, --reload load current list of pending approvals
-a
, --approve approve the device for the given user email or device id
-d
, --deny deny the device for the given user email or device id
--trusted-ip
approve devices from a trusted ip address
--format
<{table, csv, json}> format to show output in
--output
<FILE NAME> file to send output to (must use json or csv format)
Examples:
Show list of pending device approvals
Approve user "John.Doe@gmail.com"
Refresh list of pending device approvals
Write list of pending device approvals to a file in csv format
Command: create-user
Detail
Create a new account and vault for the given email address and create a record for the new user's credentials in the current Keeper vault.
To invite new users to an enterprise see the enterprise-user command
Parameters:
User's email address
Switches:
--name <Name>
user's name
--node <NODE>
name or ID of node to add user to
--record <RECORD UID>
UID of record that holds password for the new account
--folder <FOLDER NAME OR UID>
folder to store created user credentials in
Examples:
Create a new user account and vault for John.Doe@gmail.com
Send an invitation to John Doe to join Keeper, name the new user "John Doe" and add him to the "Chicago" node
When the create-user command is used to create a new user in the Keeper account, a record is created in the current logged in account with the new user's username and temporary password. Once the new record is created, it can be shared with the new user with a one-time share URL.
The new user will follow this url to receive their temporary credentials and perform the first login.
Command: transfer-user
Detail: Lock account, then transfer a vault from one user to another.
Parameter:
Email or user ID of the vault to be transferred. More than one can be provided, separated by spaces.
Switches:
--target-user <USER EMAIL>
email address of user account to transfer the vault(s) to
--force, -f
do not prompt for confirmation
Account Transfer must be enabled for the account or role the account is in.
The contents of the transferred vault are placed in a folder in the recipient's vault.
Example:
Transfer the vault of keeperuser1@keepersecurity.com to recipient@keepersecurity.com.
To perform a bulk transfer of user accounts, use the command:
transfer-user @filename
This will look for the file named filename that contains a FROM and TO mapping. For example:
Command: automator
Detail: Configures SSO Cloud device automators.
An Automator is a program running at a customer site that can perform some Keeper administrative actions such as performing device approvals or team approvals. More information about the Keeper Automator service is found at this link.
Only the root-level Keeper Administrator role can manage the Automator configuration
When the automator
command is executed without parameters it displays the list of available automators as well as a command help.
Examples:
Create automator with name "Cloud SSO Device Approval".
Edit automator to set the Webhook URL. The Webhook URL is provided by the Automator application.
Skills (Team Approvals, Team-User Approvals, Device Approvals) can be set with the "skill" argument. For example:
Initialize the automator instance using "setup", "init" and "enable" commands. The backend verifies that the Automator is configured and ready to process requests.
For more information about the Keeper Automator for SSO device approvals, see the Automator Service documentation.
Command: scim
Detail: Configures SCIM endpoints
When scim
command is executed without parameters it displays the list of available SCIM endpoints as well as a command help.
Examples:
Create SCIM endpoint for node SCIM Node
Edit SCIM endpoint configuration. Editing SCIM endpoint generates a new provisioning token
Delete SCIM endpoint
Push group and user data to SCIM endpoint
Switches
--source
Source of SCIM data. Available values: google, ad
--record
Record UID with SCIM configuration
Command: audit-alert
Detail: Manages Audit Alerts
When audit-alert
is executed without parameters it displays the list of available alerts as well as a command help
To get help on command run
list
options
view
options
history
options
delete
options
add
options
edit
options
reset-counts
options
recipient
options
recipient enable,
disable. or delete
options
recipient add or edit
options
Methods for creating user account with Commander
There are two methods for creating user accounts with Commander:
Invite users to an enterprise with the enterprise-user --add
command
Create new user accounts and vaults with the create-user
command
This page will go over the usage of each method.
In most cases the best method to use is to invite new users with enterprise-user --add
which will send vault creation instructions to new users' email.
create-user
may be useful in special circumstances where it is necessary for an administrator to have immediate access to a new vault, or when records need to be shared to a new vault right away.
Enterprises that require MFA or SSO Login will need to have these credentials available for each new user if using the create-user
command.
Use Commander to invite users to an enterprise by their email address.
To invite users to your enterprise using Commander, use the enterprise-user
command with the --add
flag.
The invited user's display name can be pre-set by adding the --name
flag followed by the desired name.
The invited user can be automatically put into a designated node with the --node
flag followed by the name of a node in the enterprise.
Hint: You can use the shortened version of the command as well: eu
e.g. eu John_Smith@example.com --add
Find more information in the command documentation.
To join the enterprise, the invited user will need to accept an invite emailed to them.
When the user clicks "Set Up Your Account Now" they are taken to the Keeper Web Vault to proceed with account creation.
Until the invited user logs into their Vault, their Vault is not setup or accessible and records cannot be shared with them.
In this example, we will take a file with a list of email addresses and send an invite to each email address.
Update Commander
Before getting started, be sure that you have the most up-to-date version of Commander. Find the most recent release on the GitHub releases page.
Set Persistent Login
Persistent login will allow Commander to run commands without needing you to login between each call. To enable persistent login, run the following commands in Keeper Commander:
For more information on persistent login and options, see the documentation page.
First gather the email addresses into a file. In this example the file will look like this:
For this example, each email address is on its own line. The file can contain any number of email addresses.
Now that the file is ready, we can use a simple script to cycle through each email and send an invite.
Run the script for your operating system from the examples above to send an invite to each email address from the file.
To expand upon the above example, we can include a user's display name and node in the file then apply these details to the user's account when sending them an invite.
For this example the file will now look like this:
Each line now has each user's email address, display name, and node separated by commas.
The given nodes must match an existing node name in the Keeper Enterprise. The nodes must exist before sending invites to new users.
To include these details in the invitation command, we simply need to add the relevant flags to the script.
Notice that the shortened version of the enterprise-user command eu is used here
Run the script appropriate for your OS and each user from the file will get an invite in their email, their display name will be set, and they will be placed in the correct node.
This example could be altered to only supply the display name or node, or to perform other tasks like adding a list of users to a specified team or role.
Sometimes it is necessary to create a new user account and vault which are setup and ready to go before the user logs in. To do this, another command can be used: create-user
When the create-user
command is used Commander will create a new user account, and set the enterprise data key required for the account to share records with other accounts in the enterprise. To do this Commander must login to the new account once when it is created.
When the account is run, you will be prompted to create a password for the new user. Alternatively you can provide a record from your vault with a password already set to use as the account's password.
See more information about this command in the command documentation
When using the create-user
command Commander needs to login to the new account. This means that if the enterprise requires MFA or SSO Login, Commander will need the corresponding credentials for the new account in order to complete vault creation.
It is recommended that enterprises only use create-user
in special circumstances, or on initial enterprise creation before MFA or SSO login is setup and required.
The create-user
command differs from the enterprise-user --add
method in the following ways:
create-user
requires a password for the new account be set by the Commander user
(Users invited be enterprise-user --add
will set their own passwords at account creation)
create-user
requires Commander to login to the new account
When creating a user account with create-user
the vault is created immediately, and can be accessed or have records shared to it right away
create-user
should only be used in special circumstances or when first creating a new enterprise.
To use the create-user
command with a list of email addresses from a file, follow the steps above for the enterprise-user
command and swap out that command with create-user
For example:
Keeper Commander compliance reporting commands
Requires Compliance Reporting add-on
Compliance reports let account administrators adhere to regulations by providing on-demand visibility to access permissions on records and credentials across the enterprise.
Using Commander, compliance reports can be scheduled and automated, and results can be exported to a CSV file or JSON.
For more information about Compliance Reports, see the Compliance Reports documentation:
compliance-report
commandThe compliance-report
command allows you to run reports just as you would in the Keeper Admin Console. See record permissions by node, user and title, filter by owned or shared records and output results to a file.
The compliance-report
command relies on a cache in order to improve performance across multiple report queries.
This means that the first call to compliance-report
may take several minutes as the system pulls in the required data.
During this time, Commander will display messaging explaining the current step.
Additionally, a manual rebuild of the cache can be performed with the -r
flag. Do this to see recent changes in the compliance data.
compliance-report -r
By default (so that the generated report reflects reasonably current and accurate data), locally-cached data older than 1 day are automatically refreshed via the process described above. As a result, any call to compliance-report
that occurs more than 1 day after a previous call to the same command will result in another data-fetching operation that may take some time to finish (as described above for first-time calls) .
To manually override this default behavior, see the next section.
Conversely, if you would like to circumvent the automatic cache-refresh behavior described above and generate a report based solely on previously cached data (resulting in possibly stale results but nevertheless useful for avoiding the possibly long loading times required to refresh the cache), you can do so with the -nr
or --no-rebuild
flag. Do this to quickly perform queries on compliance data in cases where you can be fairly confident that the relevant data have not changed significantly since the last command call / cache refresh.
compliance-report -nr
Removing the Cache
The compliance report cache can be removed manually with the --no-cache
flag. When run, this completely removes all cached compliance report information from your machine.
compliance-report --no-cache
Alternatively, you can delete the cache file locally on disk from the location where you ran Commander. Delete the file called sox_<ID>.db
which contains the encrypted compliance data.
The compliance report can be filtered by Node, User, Job Title and if the record is shared, deleted, or active.
Like many Commander reports, the compliance report results can be saved to a file. To do this use the --output
and --format
options.
Output
--output [FILE PATH]
Tells Commander to write results to a file at the given location. If no file exists it will be created.
Format
--format [csv, json, table]
Tells Commander the format to write the report results as. The default result is in table format, which displays a formatted table of results. The other options are Comma Separated Values (CSV), JavaScript Object Notation (JSON).
If the --format
flag is added without the --output
flag, the results will be shown in Commander in the the given format
compliance
commandIn addition to enabling users in generating custom reports, Commander also provides users the ability to generate specific reports with the compliance
command. These specific reports can be generated by invoking the compliance
command's supported sub-commands.
The compliance
command supports the following sub commands:
Refer to the sub command's section for more information.
Shared folders can be shared to Keeper Teams as well as individuals. The compliance report can display a report of the access that each team has to these shared folders.
To run the Compliance Team Report, use the following command in Commander:
compliance team-report
This report uses the compliance report cache described above.
The report shows each team that has access to a shared folder, and what access it has to that shared folder.
If you would like to include team-membership information (i.e., which users belong to each team) in the report, you can include the optional flag --show-team-users
/-tu
in your command call, as illustrated in the following example:
compliance team-report -tu
Please note that, as a result of the additional flag in the above command call, a column titled "Team Users" (in which the usernames of all members of each relevant team can be found) will be added to the generated report.
The compliance record-access report displays a list of all records that either a) have been accessed by, or b) are currently accessible to any given user(s), along with other relevant information (e.g., app used, IP address, event timestamp, etc.).
To run the Compliance Record-Access Report and show a user's record-access history, run the following command in Commander:
compliance record-access-report user1@company.com
where user1@company.com
is the user whose record-access activity we'd like to audit, with the resulting output being something like the following:
Similarly, to show a list of all records that are currently accessible by that same user (i.e., all records currently in the user's vault), run the following command:
compliance record-access-report --report-type=vault user1@company.com
The output of the above command should look similar to the previous example, but will exclude records that are not currently in the user's vault and may include records that have never been accessed by that user.
Additionally, if you would like to run this report for multiple users, you may do so by either specifying each username / ID in a space-delimited list in the command call or by using the "@all" shorthand to indicate that you would like to run the report for all users, as illustrated in the following examples:
compliance record-access-report user1@company.com user2@company.com
compliance record-access-report @all
The compliance summary report displays aggregate information about records within the enterprise (grouped by record-owner by default for now, but support for grouping by other entities may be added to this feature later)
To run the Compliance Summary Report, run the following command in Commander:
compliance summary-report
or
compliance stats
with the resulting output being something like the following:
Similar to compliance team-report
, this command outputs a report detailing the access that all entities (teams as well as individual users) have to all shared folders within the enterprise.
To run the Compliance Shared-Folder Report, run the following command in Commander:
compliance shared-folder-report
or
compliance sfr
with the corresponding output:
Similar to the compliance team-report
command described above, this command also accepts an optional --show-team-users
/-tu
flag indicating that team-membership data be included (where appropriate) in the resulting report. Here is an example of its usage:
compliance sfr -tu
Please note that, in contrast to the output of compliance team-report -tu
, the resulting report generated by the above command will include the appropriate additional team-membership data in the existing column named "Email" and each username associated with a team will by preceded by "(TU)" to denote it as such.
See the Reporting Documentation for other reports available in Commander
How to use Breachwatch Dark Web scanning in Keeper Commander
Command | Description |
---|---|
| Run a Breachwatch dark web scan of your records or password |
Requires the Breachwatch addon
Command: breachwatch
or bw
Detail: Run a Breachwatch dark web scan of your records or password
Actions:
list
Displays a list of breached passwords
--all
, -a
display all breached passwords (including ignored) -- note: if this flag is omitted, only the first 30 records are shown if the total count exceeds 32
--owned
, -o
display only breached records owned by user
ignore <UID>
Ignores breached passwords. Accepts multiple passwords separated by a space
password <password>
Check a password against our database of breached accounts. Accepts multiple passwords separated by a space
scan
Perform a Breachwatch scan
report
Run a Breachwatch security report for users in your enterprise (Equivalent to security-audit-report --breachwatch
; Valid only for enterprise admin accounts)
Examples:
See a summary of Breachwatch commands
Run a Breachwatch dark web scan and show which passwords are breached
List any records which have been marked as breached (and not ignored)
Check the passwords "n5@x85tG#gH7&" and "mydog21" for breaches using Breachwatch
Ignore the breached record with the given UID
Run a Breachwatch security report on users in your enterprise (only for admin accounts)
If Breachwatch is enabled for your Keeper account, a Breachwatch scan is performed automatically when you login to Keeper Commander.
Additionally, if you create or edit a record, a scan is automatically performed on the record.
Use Commander to push SCIM messages to the Keeper backend API
For identity providers that don't support SCIM, customers can utilize the Keeper Commander scim push command to provision users and teams.
Prerequisites: please be familiar with User and Team provisioning
Create a SCIM provisioning for your enterprise with the Admin Console or Commander
Create a record in Keeper with login
record type to store the SCIM configuration
Paste the SCIM URL to the Website Address
field of the Keeper record
Paste the SCIM Token to the Password
field of the Keeper record
The setup steps in this section allow you to provision users and teams from your Google Workspace account.
Prerequisites: Active Google Workspace subscription and Google Cloud Platform account
Commander installed with pip:
Make sure Google API Client Python package is installed
Google Cloud Platform: Create a project or chose an existing one
Google Cloud Platform: Enable Admin SDK API
for your project
in the APIs & Services
click +ENABLE APIS AND SERVICES
in the Search for APIs & Services
enter Admin SDK API
click ENABLE
Google Cloud Platform: Create a Service Account
In the IAM and Admin
menu select Service accounts
click +CREATE SERVICE ACCOUNT
with suggested service account name: keeper-scim
For newly created service account click Actions
/dots and select Manage Keys
click ADD KEYS
-> Create New Key.
Choose JSON key type then CREATE
A JSON file with service account credentials will be downloaded to your computer
Rename this file to credentials.json
and add this file as attachment to your Keeper configuration record that was created in the Setup Steps above.
Grant the Service Account access to your Google Workspace Directory
Navigate to your Service Account and select DETAILS
tab
in the Domain-wide delegation
section copy the Client ID
. You will need to grant this Client ID access to the Google Workspace Directory
Google Workspace Admin Console
Navigate to Security
-> API controls
Under the Domain wide delegation
click MANAGE DOMAIN WIDE DELEGATION
Click Add new
in API Clients
Paste Client ID
Paste the following text into OAuth scopes (comma-delimited)
https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly,https://www.googleapis.com/auth/admin.directory.user.readonly
Click AUTHORIZE
- These scopes grant Service Account read-only access to Google Workspace Directory Users, Groups and Membership
Google Workspace Admin Console: Provider Keeper with the Service Account
In Google, navigate to Account
-> Account settings
Copy the Primary admin
email into the clipboard (upper right area)
Paste this email into the login field of your Google SCIM configuration record in Keeper
Google Workspace Admin Console: create a group that holds users to be exported to Keeper.
Optional: skip this step if you want all user accounts to be imported
Navigate to Directory
-> Group
Click Create group
Assign all users that need to be provisioned to Keeper to this group
The Google SCIM configuration record in Keeper should now contain the following fields:
Field | Section | Value |
---|---|---|
Login | Google #5 | Google Workspace admin email |
Password | Common #4 | SCIM Token generated in the Keeper Admin Console |
Website Address | Common #3 | SCIM URL pasted from the Keeper Admin Console |
SCIM Group | Google #6 | Google group name or empty to import all users |
credentials.json | Google #3 | File attachment with Google Service Account credentials |
To perform a push of the Google users and Teams into Keeper, use the below command:
The SCIM ID can be found in the Admin Console or using Commander. For example:
Keeper has created a Google Cloud Function to automatically perform provisioning of Google Workspace users and teams. The step by step instructions can be found here:
The setup steps in this section allow you to provision users and teams from Active Directory using the scim push
command.
Prerequisites:
In your Active Directory browser, create a Group and add AD users and groups that need to be provisioned in Keeper.
Get the Active Directory connect URL, e.g. ldap(s):<domain controller host or IP
>
Pick a user that can read Active Directory
The Active Directory configuration record in Keeper should now contain the following fields:
Field | Section | Value |
---|---|---|
Password | Common #4 | SCIM Token generated in the Keeper Admin Console |
Website Address | Common #3 | SCIM URL pasted from the Keeper Admin Console |
SCIM Group | AD # 1 | AD group name that lists all users and groups to import |
AD URL | AD #2 | AD Connect URL
|
AD User | AD #3 | AD User login or distinguished name
|
AD Password | AD #3 | AD Password |
To perform a push of the Active Directory users and Teams into Keeper, use the below command:
All the commands related to Manipulating records
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Command | Explanation |
| List all records or search via a regular expression. |
| Search all records via a regular expression. |
| List folder contents |
| Display entire folder structure as a tree |
| Change current folder |
| Retrieve and display a Keeper Record/Folder/Team in printable or JSON format. |
Display the specified Keeper Record password field to the system output | |
Copy the specified Keeper Record password field to the clipboard or send to stdout | |
| Show the history or a record's modifications |
Display the Two Factor code for a given record, or show a list of records with Two Factor codes if no record is specified | |
Download all attachments of a specified record | |
Upload and attach a file to a given record | |
Delete an attachment from a given record | |
| Show a report of all the files that you have access to in the vault |
| Show details about all shared folders in the vault |
| List all teams that you have access to |
| Deprecated: use record-add |
| Add a record |
| Deprecated: use record-update |
| Edit an existing record |
Remove a record | |
| Append notes to a record |
Create a folder or shared folder | |
| Remove a folder or shared folder and its contents |
| Move a record to or folder |
| Create a link between records or folders |
Locate duplicate records in the vault (or several) based on specified attributes and fields. | |
| List or manage record shortcuts |
| Transform a folder from a shared folder to a personal folder and vice versa |
| List and manage deleted records in the trash |
Display password report | |
List (and, optionally, claim) records in the vault that currently do not have an owner |
Command: list
or l
Detail: List all records or search via a regular expression
Switches:
-v
, --verbose
verbose output (if record names are too long for the column)
Examples:
List all records
List all records with the string twitter
List all 'Azure' records that do not contain the string 'FTP" (Using regex)
Command: search
or s
Detail: Search the vault using a regular expression
Parameters:
Regular expression to use with search
Switches:
-v
, --verbose
verbose output
Examples:
Search for records containing "dropbox"
Search for records with a string of numbers and letters only ending in ".org"
Command: ls
Detail: List folder contents
Switches:
-l
, --list
show detailed list
-f
, --folders
display folders
-r
, --records
display records
-v
, --verbose
verbose output
-R
, --recursive
show subfolder contents
Examples:
Detailed list of folder contents
List of only records in a folder (No sub folders)
Detailed list of records, and show long titles even if they skew the table
Show detailed list of all records and folders found in "Folder1" and its subfolders
Command: tree
Detail: Display the entire folder structure as a tree, using specified folder or the current location (if no folder specified) as the root
Parameters:
Full path, UID, or name (if current location is parent folder) of folder to use as tree root (optional)
Switches:
-r
, --records
display records in each folder in tree (shown in slightly dimmer text)
-s
, --shares
display shared-folder share permissions (symbols denoting permission-types shown in legend/key by default)
-hk
, --hide-shares-key
hide permissions legend (valid only when--shares
flag is specified)
-t
, --title <TITLE>
show optional title for the folder-structure display
-v
, --verbose
verbose output (display record/folder UID in addition to name)
Examples:
Display entire folder structure as a tree, using the current location as the root
Display entire folder structure starting at sub directory "Office Codes" folder as the root
Display folder structure titled "My Folder Structure w/ Records (UIDs shown)" showing records in each folder (w/ corresponding UID for each folder/record), using current location as root
Display folder structure with share-permissions (as abbreviated symbols) for each contained shared-folder without displaying the corresponding permission symbols legend/key, with the displayed folder-structure root being the subfolder named Team1 in the folder named Work Folders found in the vault's root folder (note: because the target folder's full path is provided in this example, this command can be called from any location)
Command: cd
Detail: Change current directory
Parameters:
Location to move to.
Quotation marks can be used to move to folders with spaces or slashes in their name.
backslash (\) can be used to escape quotation marks in a folder's name
Examples:
Move to a folder named "social" in the current directory
Move to a folder named 'banks' inside a folder named 'financial'
Move to the vault root
Move to a folder named "folder/with/slashes"
Move to a folder named 'folder"with"quotes'
Command: find-password
Detail: Display a specified Keeper record's password to the system output, given that record's UID or path
Parameters:
Path or UID of a record
Switches:
--username <USERNAME>
match the login name using regex (optional). The given title or UID must also match to find the record
--output <{
clipboard, stdout}
>
choose the destination of the output
stdout - display password to system output (default)
clipboard - copy password to clipboard
-l
, --login
output login name instead of password
Examples:
Show the password of a specific record with the given UID
Show the password of a record with the title "Zoom" in the "office" folder
Copy the password of a specific record to the clipboard
Show the login of a record with the title "Twitter" in the "social" folder
Show the password for a record with a title that starts with "reddit", and "second" as part of the username
Command: clipboard-copy
Detail: Copy a specified Keeper record's password to the clipboard, or send the password to stdout, given that record's UID or path.
Parameters:
Path or UID of record
Switches:
--username <USERNAME>
match the login name using regex (optional). The given title or UID must also match to find the record
--output <{
clipboard, stdout, stdouthidden}
>
choose the destination of the output
clipboard
- copy password to clipboard (default)
stdout
- display password to system output
stdouthidden
- display password to system output but hidden
-l
, --login
output login name instead of password
--field <FIELD NAME>
output custom field
-r
, --revision
record revision
-t
or --totp
output TOTP code
Examples:
Copy the password of a specific record with the given UID to the clipboard
Copy the password of a record with the title "Zoom" in the "office" folder to the clipboard
Show the password of a specific record with the given UID
Copy the login of a record with the title "Twitter" in the "social" folder to the clipboard
Copy the password for a record with a title that starts with "reddit", and "second" as part of the username to the clipboard
Command: get
or g
Detail: Retrieve and display a Keeper Record/Folder/Team in printable or JSON format, given a corresponding UID.
Parameters:
UID of a record, folder, or team
Switches:
--unmask display hidden field content as plaintext
--format<{detail, json, password}> choose the format of the output
detail - a detailed view of the Record/Folder/Team (default)
json - json formatted details
password - only the password
--legacy JSON output only. Display typed records in legacy json format
Examples:
Show the details of a specific record
Show the details of a specific record in JSON format
To only retrieve the password as output, see the clipboard-copy
command
Command: record-history
or rh
Detail: Show the history of a record's modifications, given that record's UID
Parameters:
UID of record
Switches:
-a, --action <{list, diff, show, restore}> perform an action on the record
list - show revisions
diff - show changes made at each revision
show - show details about the current revision
restore - restore back to a previous revision (requires -r
or --revision
argument)
-r, --revision <REVISION NUMBER> only show details for a specific revision
Examples:
List of specific record's modification history
List of the changes made in each version of the specific record
Details of the 4th revision of the specific record (V.4)
Revert the specified record to its 2nd version
Command: totp
Detail: Display the Two Factor code for a record, given its path or UID. Show a list of records with Two Factor codes if no path or UID is given
Parameters:
Path or UID of record (optional)
Switches:
--details
display 2FA details
--range <RANGE>
display last and next [x] codes
Examples:
List of records with TOTP Two Factor codes
Show a Two Factor code with timer for the "Dropbox" record
Show a Two Factor code with timer for the record with the given UID
Display the last, current, and next Two Factor codes for the "Dropbox" record
Display the TOTP token details for the record with the given UID
Command: download-attachment
Detail: Download all files attached to the specified record(s), given that record's path or UID
Parameters:
Path or UID of record or folder
-r
or --recursive
Download recursively through subfolders
--out-dir <LOCAL DIRECTORY>
Local folder for downloaded files
--preserve-dir
Preserve vault folder structure
--record-title
Append record names to title of downloaded attachments
Naming Convention for downloaded attachments:
Naming Convention | Description |
---|---|
| By default, all downloaded attachments will retain their original name.
If a record contains the attachment "file.txt", the name of the downloaded attachment will be: |
| This is the naming convention for duplicates.
If a record contains two attachments with the same name (i.e "file.txt") or the output directory already contains a file with the same name, the naming convention of the downloaded attachments will be:
|
| For duplicates, if the naming convention in the above row is used, then the |
| If the switch |
Examples:
Download all attachments of the record titled "Financial Records" in the "documents" folder
Download all attachments of the record with the given UID
Download all attachments in the vault recursively to the specified output location: "C:\Attachments"
Append the record name "Financial Records" to the name of all downloadable attachments for the record titled "Financial Records" in the "documents" folder
Command: upload-attachment
Detail: Upload a file and attach it to a specific record, given that record's path or UID
Parameters:
Path or UID of record
Switches:
--file <FILENAME>
file name to upload (required)
Examples:
Attach a pdf file to the "Financial Records" record in the "documents" folder
Attach an image to the record with the given UID
Command: delete-attachment
Detail: Delete a file attached to a specified record, given that record's path or UID
Parameters:
Path or UID of record
Switches:
--name <FILE>
name or ID of the file to delete (required)
Examples:
Delete a pdf file named "June_2021.pdf" from the "Financial Records" record in the "documents" folder
Delete an image named "5_15_21.jpg" from the record with the given UID
Delete all orphaned file attachments in the vault
Command: file-report
Detail: Show a report of details of all files that you can access in the vault. Report consists of: Title, Record UID, and File ID
Switches:
-d
, --try-download
attempt to download all the attachments in the vault
Examples:
Show a report of all the files attached to records in the vault
Attempt to download all the files attached to records in the vault
Command: list-sf
or lsf
Detail: Display the UID, Name, Default Permissions, Record Permissions, User Permissions, and Team Permissions for all shared folders in the vault
Examples:
Show details for all shared folders in the vault
Command: list-team
or lt
Detail: Display the UID and Name for each Team that you have access to
Examples:
Show details for all teams you have access to
Command: record-add
or record-update
Detail: Adds a record to the vault or update an existing record. This is the recommended command for adding and updating records. This supports all record types, custom types, standard fields and custom fields. See --syntax-help
for detailed examples.
Parameters:
A space separated list of field values. A field has the following syntax:
<FIELD_NAME>=<FIELD_VALUE> see ...
Switches:
-t
, --title
Record title
-n
, --notes
Record notes
-rt, --record-type
Record type. See the list of standard record types.
-f,
--folder
<FOLDER PATH or UID>
Folder for the record. Applies to record-add
only.
--self-destruct
<NUMBER>[(mi)nutes|(h)ours|(d)ays|(mo)nths|(y)ears]
Time period record share URL is valid. The record will be deleted from your vault 5 minutes after opening. Applies to record-add
only.
-r,
--record
<RECORD PATH or UID>
Path or UID of the record to edit. Applies to record-update
only.
-f
, --force
Ignore warnings.
--syntax-help
Displays detailed information on usage for these commands.
Examples:
Command: rm
Detail: Remove record(s) with given path(s) or UID(s)
Parameters:
Path or UID of record(s)
Switches:
-f
, --force
do not prompt
Examples:
Remove the "Twitter" record in the "social" folder. Will be prompt to enter "y" to approve.
Remove the record with the given UID and don't prompt to approve.
Remove the "Bank" record and purge it from the trash (record will not be recoverable)
Remove records "rec1" and "rec2"
Command: append-notes
or an
Detail: Append to the notes of a record with a given path or UID
Parameters:
Path or UID of record
Switches:
--notes <NOTES>
notes to append
Examples:
Append to the notes of the "Twitter" record in the "social" folder. Will be prompted to enter notes to add
Append to the notes of the record with the given UID with the message "Outdated as of June 2021"
Command: mkdir
Detail: Create a folder or shared folder at the given path
Parameters:
Path/name of new folder
Switches:
-sf
, --shared-folder
create a shared folder
-uf
, --user-folder
create a user folder (not shared)
-a
, --all
set default folder permissions to allow any user to manage users, manage records, share records, and edit records
-u
, --manage-users
set default folder permissions to allow all users to manage user access
-r
, --manage-records
set default folder permissions to allow all users to manage records
-s
, --can-share
set default folder permissions to allow all users to share records
-e
, --can-edit
set default folder permissions to allow all users to edit records
--color <
{none, red, green, blue, orange, yellow, gray}
>
sets folder color
When adding other users or teams to a shared folder, they will be given the default permissions of that folder, unless the permission is specifically revoked or added when sharing. See the share-folder command for more details.
Examples:
Create a folder named "personal" in the existing "finance" folder. Will be prompted to create a shared folder or user folder
Create a user folder named "social"
Create a shared folder named "office-codes" with the default permissions set to allow all users to share the records in the folder
Command: rmdir
Detail: Delete a folder or shared folder given the folder's path or UID
Parameters:
Path of folder
Accepts patterns, which will remove all matching folders.
*
matches everything
?
matches any single character
[seq]
matches any character in seq
[!seq]
matches any character not in seq
Accepts multiple parameters separated by a space
Switches:
-f
, --force
Delete folder without prompting
-q
, --quiet
returns no output when used in conjunction with -f
Examples:
Delete the folder named "temporary" in the "social" folder. Will be prompted to confirm
Delete the folder with the given UID and don't prompt to confirm
Delete all folders with only letters in the name, ending in '2'
Delete the folder 'secrets' in the 'DevOps' folder, and the 'MyFolder' folder
Delete the folder with the given UID and don't show any output
Remove all folders from the Keeper Vault
Command: mv
Detail: Move a record or folder to another folder, given the record or folder's path or UID and the path or UID of the destination folder
Parameters:
Path or UID of record followed by path or UID of destination folder
mv SRC DST
SRC: the source path to folder or record. Accepts title paths, search patterns, and UIDs
DST: the destination folder name or UID to move to
Switches:
-f
, --force
move record or folder without prompting
-s
. --can-reshare
anyone can reshare records
-e
, --can-edit
anyone can edit records
Examples:
Move the "Twitter" record into the "social" folder
Move the record with the given UID to the root folder
Command: ln
Detail: Link a record or folder to another folder, given the record or folder's path or UID and the path or UID of the destination folder
Parameters:
Path or UID of record followed by path or UID of destination folder
ln SRC DST
SRC: the source path to folder or record. Accepts title paths, search patterns, and UIDs
DST: the destination folder name or UID to link to
Switches:
-f
, --force
move record or folder without prompting
-s
. --can-reshare
anyone can re-share records
-e
, --can-edit
anyone can edit records
Examples:
Link the "Twitter" record with the "social" folder
Link the record with the given UID to the root folder
Command: find-duplicate
Detail: Useful tool to help locate duplicate records in the vault based on one or more record fields.
Parameters:
Provide a list of fields to use for comparison.
Switches:
--title
Match the title field to locate a duplicate
--login
Match the login field to locate a duplicate
--password
Match the password field to locate a duplicate
--url
Match the URL field to locate a duplicate
--shares
Match on share-permissions
--full
Match all fields to locate a duplicate
--merge, -m
Consolidate duplicate records (Note: when this flag is included, duplicate records are automatically matched on all fields, including shares)
--ignore-shares-on-merge
Ignore share-permissions when matching duplicate records for merging
--force, -f
Delete duplicates w/o being prompted for confirmation (valid only w/ --merge option)
--quiet, -q
Suppress screen output (valid only w/ --force/--merge
options)
--dry-run, -n
Simulate removing duplicates (no records are ever removed or modified). Valid only w/ --merge
flag
--scope,
-s <enterprise, vault>
Define the scope of the search (default is vault). Enterprise scope available only to enterprise account administrators with compliance data-access prvileges.
--refresh-data
, -r
Populate local cache with latest audit data. Valid only when used with the --scope=enterprise
option.
--format
<{csv, json, table}>
Chose the format of the output
--output
<FILENAME> Export search results to a file
Examples:
Find duplicate records based on matching titles
Find duplicate records based on matching logins and passwords
Find duplicate records based on matching logins, passwords, and website addresses
Find duplicate records by matching on all relevant fields (including custom fields and share-permissions that apply for each record)
Find duplicate records -- matching on all relevant fields (and shares) -- and consolidate them into one (i.e., delete all but one record for each set of records deemed to be duplicates of each other) per set of duplicates without prompting for confirmation prior to record deletion
Find duplicate records (matching on all fields) and simulate consolidating the results
Find duplicate records across vaults within the entire enterprise and export the search results to a CSV-formatted filed named enterprise_duplicates.csv
Command: shortcut
Detail: List or manage record shortcuts. Shortcuts are links to records in a folder other than the folder that record belongs to.
Parameters:
Command:
list <RECORD UID, FOLDER UID, PATH (optional)>: Show a list of all shortcuts. Filtered to record or folder if given
keep <RECORD OR FILE PATH> : Remove all but one shortcut
Switches:
list switches:
--format <{
csv, json, table}
>
choose the format of the output
--output <FILENAME>
file to write output results to
Examples:
Display a list of record shortcuts
Output a list of record shortcuts to a file
Output a list of record shortcuts that exist in the folder with the give UID
Remove all record shortcuts other than record at the given location
Use Case: Deleting all but one shortcut with command keep
Suppose there are multiple shortcuts for the following record, and you only want to keep the record
To keep this record only in the "key-folder2" and remove all other shortcuts, you can execute the following command:
Running the above command will prompt you to confirm the deletion of the extra shortcuts
To verify that the additional shortcuts have been deleted, you can do one of the following:
Access your web vault and observe that the shortcuts have been deleted.
Example:
In the above scenario & example, I will find only one instance of the record ksm-key1
in key-folder2
Running the shortcut list <Record UID>
command will output that the record has no shortcuts
In the above scenario & example, after deleting the unwanted shortcuts, running the list
command will give me the following:
Command: transform-folder
Detail: Transform a folder from a shared folder to a personal folder and vice versa
Parameters:
Folder UID or path/name (accepts multiple values)
-c
, --children
Apply transformation to target folder's children only (target folder will remain unchanged).
-n
, --dry-run
Preview the folder transformation without updating
-f
, --force
Skip confirmation prompt and minimize output
Examples:
For these next examples, let's assume we have a vault with the following contents and folder-structure (as shown in Keeper Shell by executing the command tree -s -r -v
):
Executing the following command (from within the vault's root folder)
gives us the following transformed folder-structure (displayed tree limited to transformed folder and its contents):
2. Transform a shared-folder into a user folder
Executing the following command (from within the vault's root folder)
transform-folder "Shared Folder (Team3, Admin)"
gives us the following transformed folder-structure (displayed tree limited to transformed folder and its contents):
3. Transform a folder's children
Executing the following command (from within the vault's root folder)
transform-folder --children "Shared Items"
gives us the following transformed folder-structure (displayed tree limited to transformed folder and its contents):
For security reasons and because of current limitations on the type of folders that any given shared-folder can contain, not every folder in a given vault is necessarily eligible for transformation using the command described above. Consequently, there are certain types of folders for which this command will fail to execute. These include
user folders that contain -- either in the folder itself, or in any of its subfolders, or in any of its subfolders' subfolders, etc. -- any 1 of the following items:
a shared-folder for which the user does not have either of the following:
share-admin privileges
full share permissions ("Can Manage Users", "Can Manage Records")
a direct-share record for which the user does not have either of the following:
share-admin privileges
re-share permissions ("Can Share")
user folders contained within a shared-folder (i.e., any user folder whose parent folder, or parent folder's parent folder, etc., is a shared-folder)
Command: trash <sub command>
Detail: List or manage deleted records in the trash. Deleted records remain in the trash until purged.
Parameters:
Sub-command:
list <SEARCH PATTERN>
: Show a list of all deleted records in the trash can. Filtered to record or folder if given
get <RECORD UID>
: show information about deleted record with the given UID
restore <RECORD UID(S)>
: restore a previously deleted record or records. Can be given several UIDs separated by a space
unshare <RECORD UID(S)>:
remove shares from deleted records
purge
: permanently delete all records in the trash
Switches:
list switches:
--format <{
csv, json, table}
>
choose the format of the output
--output <FILENAME>
file to write output results to
--reload
refresh the list of deleted records
list examples:
Display a list of deleted records
Output a list of deleted records to a file named 'deleted.csv'
Display a list of deleted records that have a title starting with "Twitter"
get examples:
Display details of deleted record with the given UID
restore switches:
--force
don't prompt when restoring
list examples:
Restore the deleted record with the given UID
Restore the deleted records with all the given UIDs
Restore the deleted records with all the given UIDs and don't prompt
unshare example:
purge examples:
purge all deleted records from the trash
Command: password-report
Detail: Display password report
Switches:
--policy <comma separated integers>
Password complexity policy. Length,Lower,Upper,Digits,Special. Example: 12,2,2,2,0
--length <Number>
Minimum password length
--lower <Number>
Minimum lowercase characters
--upper <Number>
Minimum uppercase characters
--digits <Number>
Minimum digits
--special <Number>
Minimum special characters
Parameters:
folder
Optional. Scan for weak passwords in a folder
Examples:
Command: find-ownerless
Detail: List (and, optionally, claim) records in the user's vault that currently do not have an owner
Switches:
--format <{
csv, json, table}
>
choose the format of the output
--output <FILENAME>
file to write output results to (ignored for table format)
--claim
claim records found
-v, --verbose
output details for each record found
Parameters:
folder
path or UID of folder to search (optional, with multiple values allowed)
Examples:
Find all the records that do not have an owner and print additional details for each record found
Claim all found records without an owner
Commands for creating and managing Record Types and Custom Templates
The commands associated with Record Types are listed below. For more information on record types, including example usage, see the documentation
Creating Record TypesWhether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Command | Explanation |
| List record types or see information about a specific record type |
| Add, edit, or delete custom record types |
| Convert legacy records to record-typed records |
Command: record-type-info
or rti
Detail: List available record types. or details of a specific record type
Switches:
-lr
, --list-record <RECORD TYPE OR ID (optional)>
If record type name or ID is not given, lists all record type names and IDs
if a record type name or ID is given, displays the record type's details and fields
-lf
, --list-field <FIELD NAME>
show information about a specified field type. Can use "*" to show all fields.
-e
, --example
generate example json for a record type or field. *Must use with -lr or -lf
--syntax-help
display extended help on record type parameters
--format <{csv, json, table}>
choose the format to output in
--output <OUTPUT FILE>
output results to a given file *ignored if table format is used
Examples:
show list of record types
show details of the login record type
show details of the name field type
show details of all field types
display an example of the passport record type
display extended syntax help text
write the record type information as a CSV to a file
Command: record-type
or rt
Detail: Add, modify, or delete custom record types
Parameters:
Record type ID (if updating or deleting)
Switches:
-a
, --action <{add, update, remove}>
action to perform
add - create a new custom record type
update - modify an existing custom record type
remove - delete an existing custom record type
--data <DATA>
JSON formatted definition of the record type
Format:
Record types utilize the following formatting:
Example:
See a list of all field types here
Use the following command to see a list of available field types: rti -lf *
Examples:
Add a new record type named "My Record Type"
Update the "My Record Type" record Type (which has an ID of 102 in this example). Here, the 'Address' field was removed
Remove the record type with Id 102
Required Version: v16.5.9+
Command: convert
Detail: Convert legacy (General typed or untyped) records to typed records.
The convert command will only convert legacy, untyped records to typed records.
To convert the type of a typed record, use the edit command.
Parameters:
Pattern to match records in the current folder. Matches against UIDs and titles. Can use "?" to match any single character and "*" to match any number of characters
Switches:
-t
, --record-type <RECORD TYPE OR ID >
The type to convert records to
see record types documentation for a list of all standard record types
-q
, --quiet
Do not show info about matched and converted records
-u
, --url <URL Pattern>
Only converts records with URLs that match the given pattern. Can use "?" to match any single character and "*" to match any number of characters
-n
, --dry-run
Display the outcome of the conversion without converting any records
-r
, --recursive
apply conversion to all matching records in the current and child folders
--ignore-ownership
convert records even if they are not owned by the current account
Examples:
Convert the untyped record with the given UID to a login type record
Perform a dry-run of conversion of all records in the vault and display what records would be converted. (will match all records if performed at the root directory)
Convert all untyped records in the vault to login type (if performed at the root directory)
Convert any untyped record that contains 'sql' in its name to a database credential
Convert any record that ends in ssh-<anything> to a sshKey type record
e.g convert a record titled "Github ssh-1" and a record titled "Github ssh-2"
Description and examples for using and managing Record Types
Within the Vault and via the commander CLI, it's possible to create records of a specific type. And if this capability is enabled by your Keeper Administrator, you can even create custom record type templates. Record Types define the fields available to a record. They act as a record blueprint, which makes it easy to create and manage records for a variety of different uses.
There is a set of standard record types defined by Keeper, these include common types like Login, Passport, and SSH Keys.
It is also possible to define new record types to be used by your organization.
For a list of associate record type commands, see commands documentation
add type=login title='my login' f.login=John.Doe f.password=75vf@5JB@o f.url=https://www.example.com f.oneTimeCode=otpauth://totp/Label?secret=Secret
record-type-info
record-type-info -lr login
record-type-info -lr login -e
Field | Description |
| text field |
| number field |
| Login field recognized by the KeeperFill |
| Password field which is masked and allows for password generation |
| First, Middle and Last text fields which make up a name |
| Plain text company name |
| Phone number and type fields |
| Validated email address |
| Multiple fields which capture an address |
| Reference to another record which is a address |
| Calendar date with validations. stored as unix milliseconds |
| Calendar date with validations. stored as unix milliseconds |
| Calendar date with validations. stored as unix milliseconds |
| Validated card number, expiration, and security code fields |
| Plain text |
| Plain Text |
| Bank account information fields |
| Reference to a |
| Multiline text |
| URL text field. Can be followed as a link in the Vault |
| Reference to a file field in another record |
| Multiple fields which capture host information |
| Security Question and answer text fields |
| Pin which is masked |
| Given the TOTP seed, provides the TOTP code |
| Private and public keys in ASN.1 format |
| Multiline text input |
| A text input that is masked |
Record Type | ID |
| 1 |
| 11 |
| 19 |
| 20 |
| 21 |
| 22 |
| 23 |
| 24 |
| 26 |
| 27 |
| 28 |
| 29 |
| 30 |
| 31 |
| 32 |
| 34 |
| 40 |
Below you can see the fields in each record type, an example json representation, and and example of how to create a record of each type.
All record types have the following fields:
title
- what the record is named (required)
notes
- text
custom
- custom fields and values can be added to records. See add documentation for more information on adding custom fields
Name: login
Id: 1
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | ||
| Text | ||
| Text | ||
| |||
| Text |
Add Record Example:
Dot Notation add type=login title='my login' f.login=John.Doe f.password=75vf@5JB@o f.url=https://www.example.com f.oneTimeCode="otpauth://totp/Label?secret=Secret"
JSON Data add --data '{"type": "login", "title": "my login", "fields": [{"type": "login", "value": ["John.Doe"]}, {"type": "password", "value": ["75vf@5JB@o"]}, {"type": "url", "value": ["https://www.example.com"]}, {"type": "oneTimeCode", "value": ["otpauth://totp/Label?secret=Secret"]}], "custom": []}'
Name: bankAccount
Id: 11
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
| 'Checking | Savings | Other' | |
|
| Text | |
|
| Text | |
|
| Text | |
|
| Text | |
|
| Text | |
|
| Text | |
| Text | ||
| Text | ||
| Text | ||
| |||
| |||
| Text |
Add Record Example:
Dot Notation add type=bankAccount title='my bankAccount' f.bankAccount.accountType=Checking f.bankAccount.otherType=SomeText f.bankAccount.routingNumber=SomeText f.bankAccount.accountNumber=SomeText f.name.first=John f.name.middle=Danger f.name.last=Doe f.login=John.Doe f.password=75vf@5JB@o f.url=https://www.example.com f.oneTimeCode="otpauth://totp/Label?secret=Secret"
JSON Data add --data '{"type": "bankAccount", "title": "my bankAccount", "fields": [{"type": "bankAccount", "value": [{"accountType": "Checking", "otherType": "SomeText", "routingNumber": "SomeText", "accountNumber": "SomeText"}], "required": true}, {"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}]}, {"type": "login", "value": ["John.Doe"]}, {"type": "password", "value": ["75vf@5JB@o"]}, {"type": "url", "value": ["https://www.example.com"]}, {"type": "cardRef", "value": []}, {"type": "oneTimeCode", "value": ["otpauth://totp/Label?secret=Secret"]}], "custom": []}'
Name: address
Id: 14
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
| Text | |
|
| Text | |
|
| Text | |
|
| Text | |
|
| Text | |
|
| Text | |
|
Add Record Example:
Dot Notation add type=address title='my address' f.address.street1=SomeText f.address.street2=SomeText f.address.city=SomeText f.address.state=SomeText f.address.zip=SomeText f.address.country=SomeText
JSON Data add --data '{"type": "address", "title": "my address", "fields": [{"type": "address", "value": [{"street1": "SomeText", "street2": "SomeText", "city": "SomeText", "state": "SomeText", "zip": "SomeText", "country": "SomeText"}]}], "custom": []}'
Name: bankCard
Id: 18
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
| Text | |
|
| Text | |
|
| Text | |
| Text | cardholderName | |
| Text | ||
| |||
|
Add Record Example:
Dot Notation add type=bankCard title='my bankCard' f.paymentCard.cardNumber=SomeText f.paymentCard.cardExpirationDate=SomeText f.paymentCard.cardSecurityCode=SomeText f.text=SomeText f.pinCode=SomeText
JSON Data add --data '{"type": "bankCard", "title": "my bankCard", "fields": [{"type": "paymentCard", "value": [{"cardNumber": "SomeText", "cardExpirationDate": "SomeText", "cardSecurityCode": "SomeText"}]}, {"type": "text", "value": ["SomeText"], "label": "cardholderName"}, {"type": "pinCode", "value": ["SomeText"]}, {"type": "addressRef", "value": []}], "custom": []}'
Name: birthCertificate
Id: 19
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
| Text | |
|
| Text | |
|
| Text | |
| Number | ||
|
Add Record Example:
Dot Notation add type=birthCertificate title='my birthCertificate' f.name.first=John f.name.middle=Danger f.name.last=Doe f.birthDate=1624485827145
JSON Data add --data '{"type": "birthCertificate", "title": "my birthCertificate", "fields": [{"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}]}, {"type": "birthDate", "value": [1624485827145]}], "custom": []}'
Name: contact
Id: 20
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
| Text | |
|
| Text | |
|
| Text | |
| Text | company | |
| Text | ||
|
| Region | |
|
| Text | |
|
| Text | |
|
| Home | Mobile | Work | |
| |||
|
Add Record Example:
Dot Notation add type=contact title='my contact' f.name.first=John f.name.middle=Danger f.name.last=Doe f.text=SomeText f.email=SomeText f.phone.region=US f.phone.number=(555)555-5555 f.phone.ext=3 f.phone.type=Mobile
JSON Data add --data '{"type": "contact", "title": "my contact", "fields": [{"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}], "required": true}, {"type": "text", "value": ["SomeText"], "label": "company"}, {"type": "email", "value": ["SomeText"]}, {"type": "phone", "value": [{"region": "US", "number": "(555)555-5555", "ext": "3", "type": "Mobile"}]}, {"type": "addressRef", "value": []}], "custom": []}'
Name: driverLicense
Id: 21
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | dlNumber | |
|
| Text | |
|
| Text | |
|
| Text | |
| Number | ||
| |||
| Number | ||
|
Add Record Example:
Dot Notation add type=driverLicense title='my driverLicense' f.accountNumber=SomeText f.name.first=John f.name.middle=Danger f.name.last=Doe f.birthDate=1624485827145 f.expirationDate=1624485827145
JSON Data add --data '{"type": "driverLicense", "title": "my driverLicense", "fields": [{"type": "accountNumber", "value": ["SomeText"], "label": "dlNumber"}, {"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}]}, {"type": "birthDate", "value": [1624485827145]}, {"type": "addressRef", "value": []}, {"type": "expirationDate", "value": [1624485827145]}], "custom": []}'
Name: encryptedNotes
Id: 22
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | ||
| Number | ||
|
Add Record Example:
Dot Notation add type=encryptedNotes title='my encryptedNotes' f.note=SomeText f.date=1624485827145
JSON Data add --data '{"type": "encryptedNotes", "title": "my encryptedNotes", "fields": [{"type": "note", "value": ["SomeText"]}, {"type": "date", "value": [1624485827145]}], "custom": []}'
Name: file
Id: 23
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
Add Record Example:
Dot Notation add type=file title='my file'
JSON Data add --data '{"type": "file", "title": "my file", "fields": [], "custom": []}'
Name: healthInsurance
Id: 24
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | ||
|
| Text | insuredsName |
|
| Text | insuredsName |
|
| Text | insuredsName |
| Text | ||
| Text | ||
| Text | ||
|
Add Record Example:
Dot Notation add type=healthInsurance title='my healthInsurance' f.accountNumber=SomeText f.name.first=John f.name.middle=Danger f.name.last=Doe f.login=John.Doe f.password=75vf@5JB@o f.url=https://www.example.com
JSON Data add --data '{"type": "healthInsurance", "title": "my healthInsurance", "fields": [{"type": "accountNumber", "value": ["SomeText"]}, {"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}], "label": "insuredsName"}, {"type": "login", "value": ["John.Doe"]}, {"type": "password", "value": ["75vf@5JB@o"]}, {"type": "url", "value": ["https://www.example.com"]}], "custom": []}'
Name: membership
Id: 26
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | ||
|
| Text | |
|
| Text | |
|
| Text | |
| Text | ||
|
Add Record Example:
Dot Notation add type=membership title='my membership' f.accountNumber=SomeText f.name.first=John f.name.middle=Danger f.name.last=Doe f.password=75vf@5JB@o
JSON Data add --data '{"type": "membership", "title": "my membership", "fields": [{"type": "accountNumber", "value": ["SomeText"]}, {"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}]}, {"type": "password", "value": ["75vf@5JB@o"]}], "custom": []}'
Name: passport
Id: 27
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | passportNumber | |
|
| Text | |
|
| Text | |
|
| Text | |
| Number | ||
| |||
| Number | ||
| Number | dateIssued | |
| Text | ||
|
Add Record Example:
Dot Notation add type=passport title='my passport' f.accountNumber=SomeText f.name.first=John f.name.middle=Danger f.name.last=Doe f.birthDate=1624485827145 f.expirationDate=1624485827145 f.date=1624485827145 f.password=75vf@5JB@o
JSON Data add --data '{"type": "passport", "title": "my passport", "fields": [{"type": "accountNumber", "value": ["SomeText"], "label": "passportNumber"}, {"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}]}, {"type": "birthDate", "value": [1624485827145]}, {"type": "addressRef", "value": []}, {"type": "expirationDate", "value": [1624485827145]}, {"type": "date", "value": [1624485827145], "label": "dateIssued"}, {"type": "password", "value": ["75vf@5JB@o"]}], "custom": []}'
Name: photo
Id: 28
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
Add Record Example:
Dot Notation add type=photo title='my photo'
JSON Data add --data '{"type": "photo", "title": "my photo", "fields": [], "custom": []}'
Name: serverCredentials
Id: 29
Record Fields:
Field Name | Sub Field | Type | Field Label |
|
| Text | |
|
| Text | |
| Text | ||
| Text | ||
|
Add Record Example:
Dot Notation add type=serverCredentials title='my serverCredentials' f.host.hostName=https://www.example.com f.host.port=5000 f.login=John.Doe f.password=75vf@5JB@o
JSON Data add --data '{"type": "serverCredentials", "title": "my serverCredentials", "fields": [{"type": "host", "value": [{"hostName": "https://www.example.com", "port": "5000"}]}, {"type": "login", "value": ["John.Doe"]}, {"type": "password", "value": ["75vf@5JB@o"]}], "custom": []}'
Name: softwareLicense
Id: 30
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | ||
| Number | ||
| Number | dateActive | |
|
Add Record Example:
Dot Notation add type=softwareLicense title='my softwareLicense' f.licenseNumber=SomeText f.expirationDate=1624485827145 f.date=1624485827145
JSON Data add --data '{"type": "softwareLicense", "title": "my softwareLicense", "fields": [{"type": "licenseNumber", "value": ["SomeText"]}, {"type": "expirationDate", "value": [1624485827145]}, {"type": "date", "value": [1624485827145], "label": "dateActive"}], "custom": []}'
Name: ssnCard
Id: 31
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | identityNumber | |
|
| Text | |
|
| Text | |
|
| Text | |
|
Add Record Example:
Dot Notation add type=ssnCard title='my ssnCard' f.accountNumber=SomeText f.name.first=John f.name.middle=Danger f.name.last=Doe
JSON Data add --data '{"type": "ssnCard", "title": "my ssnCard", "fields": [{"type": "accountNumber", "value": ["SomeText"], "label": "identityNumber"}, {"type": "name", "value": [{"first": "John", "middle": "Danger", "last": "Doe"}]}], "custom": []}'
Name: general
Id: 32
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | ||
| Text | ||
| Text | ||
| Text | ||
|
Add Record Example:
Dot Notation add type=general title='my general' f.login=John.Doe f.password=75vf@5JB@o f.url=https://www.example.com f.oneTimeCode=SomeText
JSON Data add --data '{"type": "general", "title": "my general", "fields": [{"type": "login", "value": ["John.Doe"]}, {"type": "password", "value": ["75vf@5JB@o"]}, {"type": "url", "value": ["https://www.example.com"]}, {"type": "oneTimeCode", "value": ["SomeText"]}], "custom": []}'
Name: sshKeys
Id: 34
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | ||
| Text | ||
|
| Text | |
|
| Unknown - Text | |
| |||
| Text |
Add Record Example:
Dot Notation add type=sshKeys title='my sshKeys' f.login=John.Doe f.keyPair=SomeText f.host.hostName=https://www.example.com f.host.port=Unknown - Text f.secret=SomeText
JSON Data add --data '{"type": "sshKeys", "title": "my sshKeys", "fields": [{"type": "login", "value": ["John.Doe"]}, {"type": "keyPair", "value": ["SomeText"]}, {"type": "host", "value": [{"hostName": "https://www.example.com", "port": "Unknown - Text"}]}, {"type": "secret", "value": ["SomeText"]}], "custom": []}'
Name: databaseCredentials
Id: 40
Record Fields:
Field Name | Sub Field | Type | Field Label |
| Text | type | |
|
| Text | |
|
| Text | |
| Text | ||
| Text | ||
|
Add Record Example:
Dot Notation add type=databaseCredentials title='my databaseCredentials' f.text=SomeText f.host.hostName=https://www.example.com f.host.port=5000 f.login=John.Doe f.password=75vf@5JB@o
JSON Data add --data '{"type": "databaseCredentials", "title": "my databaseCredentials", "fields": [{"type": "text", "value": ["SomeText"], "label": "type"}, {"type": "host", "value": [{"hostName": "https://www.example.com", "port": "5000"}]}, {"type": "login", "value": ["John.Doe"]}, {"type": "password", "value": ["75vf@5JB@o"]}], "custom": []}'
Commands related to sharing records and shared folders
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Command | Explanation |
| Grant or revoke user access to a record |
| Change shared folder permissions |
Change record permissions of a folder | |
Manage one-time shares | |
| Display or revoke shares to external users |
Command: share-record
or sr
Detail: Grant or revoke user access to record(s) given that record or folder path or UID
Parameters:
Path or UID of record or folder
Switches:
-e, --email <EMAIL> email of account to edit permissions for (required)
-a, --action <{grant, revoke, owner, cancel}> permission to set for record
-s, --share allow user to share record
-w, --write allow user to modify record
-R, --recursive apply command to shared folder hierarchy
--dry-run display the permissions changes without committing them
--expire-at EXPIRE_AT share expiration: "never" or ISO date-time (yyyy-MM-dd[ hh:mm:ss])
--expire-in <NUMBER>[(mi)nutes|(h)ours|(d)ays|(mo)nths|(y)ears] share expiration: "never" or period
Examples:
Share the "Gym" record in the "memberships" folder with user John Smith
Share a record with the given UID with user John Smith and allow him to share the record with others
Transfer record ownership of the "Twitter" records from the "social" folder with user John Smith
Share all records found in shared-folder "My Shared Folder" (including any in its subfolders) with user John Smith
Share record "Gym" in the "memberships" folder with user John Smith, accessible until 1 second after the start of the year 2050 (GMT)
Give user John Smith time-limited read-only access (valid only for the next 3 days) to the "Twitter" record in the folder named "social"
Command: share-folder
or sf
Detail: Grant or revoke user default permissions for a given (set of) shared folder(s)
See the mkdir command for details on creating shared folders
Parameters:
Path(s) or UID(s) of folder(s)
Switches:
-a, --action <{grant, revoke, remove}> permission to set for folder(s) / record(s)
-e, --email <EMAIL, TEAM, *>
email - user's email to set folder permissions for
team - name of a team to set folder permissions for
* - apply relevant permissions for each new user with whom the folder(s) is/are shared
@currrent/@existing - apply to all users with existing access to folder(s)
-r, --record <{RECORD NAME, UID, *, @existing, @current}>
record name / UID - specific record to set permissions for
* - set default permissions for any new record added to the relevant folder(s)
@existing/@current - apply permissions to all records currently contained by the specified shared folder(s)
-p, --manage-records allow managing records. Users/teams only
-o, --manage-users allow managing users. Users/teams only
-s, --can-share allow sharing records. Records only
-d, --can-edit allow modifying records in the folder. Records only
-f, --force apply permissions changes ignoring default folder permissions
--expire-at TIMESTAMP share expiration: "never" or ISO date-time (yyyy-MM-dd[ hh:mm:ss])
--expire-in PERIOD share expiration: "never" or period (<NUMBER>[(y)ears|(mo)nths|(d)ays|(h)ours(mi)nutes])
Shared folder permissions are additive. If the default folder permissions allow a permission, all users and teams that folder is shared with will have that permission unless it is specifically revoked using -a revoke
Examples:
Share the "memberships" shared folder with user Jane.Smith@gmail.com. Allow the user to manage records
Revoke "Can Share" permission from the "gym" record in the "memberships" shared folder
Share the folder with the given UID with the "DB_ADMINS" team and allow them to manage records in the shared folder
Share a "Team Passwords" folder with a team called "Marketing Team" and give permission to manage users
Share all shared folders with the "DB_ADMINS" team and allow them to manage records in the shared folder
Remove all access to "memberships" shared folder for user Jane.Smith@gmail
Grant user read-only access to "memberships" shared-folder, valid only for the next 5 hours
The Default Folder Settings control the permissions on newly added users and records. To change the default permissions with the share-folder
command, use the [*] symbol.
For example, to set user defaults to "Can Manage Users & Records" and to set record defaults to "Can Edit & Share" on the Shared Folder based on a UID:
Hint: You can also apply the same permissions used to set a shared folder's default settings (as in the examples above) to records/users currently assigned to that shared folder within the same command call by simply specifying the value "@current" or "@existing" for the appropriate option/s (-r for records, -e for users). Using examples similar to the ones above, we have the following:
sf -e * --manage-user --manage-records
-e @existing
jdrkYEaf03bG0ShCGlnKww
sf -r * -r @existing --can-share --can-edit -e @existing jdrkYEaf03bG0ShCGlnKww
In the 1st example, we set both the default user permissions and the permissions granted to current users assigned to the shared folder to "can manage users" and "can manage records".
In the 2nd example, we set both default record permissions and permissions for already-existing records currently contained by the shared-folder to "can edit" and "can share' for users that currently have access to that shared-folder
Detail: Change the permissions for all records in a shared folder
Parameters:
Path or UID of folder
Switches:
-a, --action <{grant, revoke}> permission access to set for record
-s, --can-share allow sharing records
-d, --can-edit allow modifying records in the folder
-f, --force apply permissions changes without prompting
-R, --recursive apply permission changes to all sub folders
--dry-run Display permission changes made by command without actually changing the permissions
--share-record change a record's sharing permissions
--share-folder change a folder's sharing permissions
Examples:
Grant sharing permission to all records in the "memberships" shared folder
Revoke edit permission from all records in the folder with the given UID and all sub folders
See the changes that would be made by granting sharing permissions to the "social" folder but don't apply the permission change
Requires Commander version 16.6.3+
Command: one-time-share
Detail: Create, list, or remove a one-time shares for a given record. For more information about one-time share click here.
Sub Commands:
list
- show one time shares
create
- create a new one time share URL
remove
- remove a one time share
List
Switches:
-a
--all
show all one-time shares, including expired shares
--format <table, csv, json>
the format to show the one time shares in
-v
--verbose
Verbose output
-R --recursive
Traverse recursively through subfolders
Parameters:
name or UID of record or folder. Can be repeated
Create
Switches:
--output <clipboard, stdout>
choose to put the URL in the clipboard, or to stdout (default)
--name
name the one time share
-e <TIME>
--expire <TIME>
how long the one time share will remain active
format: <NUMBER>[(mi)nutes|(h)ours|(d)ays] e.g. 1h
for 1 hour
Parameters:
name or UID of record. Can be repeated
Remove
Parameters:
name or UID of record
one-time share name or ID
Examples:
List
Create
Remove
The external-shares-report requires the Compliance Reporting add-on. This command is only available for Enterprise admin accounts.
Command: external-shares-report
or esr
Details: Display and (optionally) revoke share-permissions granted to users outside of the enterprise
Switches:
--format <{table, json, csv}> format the output, default is 'table'
--output <FILENAME> output to a filename. Ignored with 'table' format
--action, -a <{remove, none}> action to perform on external shares, 'none' if omitted
--share-type, -t <{direct, shared-folder, all}> filter report by share type, 'all' if omitted
--force, -f, skip confirmation when removing shares
--refresh-data, -r refresh local user and record data before running
Examples:
Show records and shared-folders shared to users outside of the enterprise
Refresh locally-cached enterprise record/folder/user data prior to running and showing report
Run report and export results to a JSON-formatted file named external_shares.json
Run report, show results, and revoke external shares identified in the results
Same as #4 above but requires no additional user-interaction to complete execution (i.e., skips confirmation prompt prior to revoking the external shares identified in the report)
Run and show report, limiting results to records shared via direct-share (i.e., omit shared-folders from report)
By default, using the above command to revoke share-permissions previously granted to external accounts (via esr -a remove
) requires user-interaction -- via a confirmation prompt -- to complete.
Hint: If you need to perform this task in a non-interactive manner (e.g., if running from a Keeper script/batch file, or as part of an automated administrative tool), include the --force
flag in your command call (e.g., external-shares-report --force --action remove
)
In this example, we will recursively change the record permissions in a Shared Folder.
On Commander, you can use the "ls -l" command, similar to a Bash shell.
On the Vault user interface, you can click on the info dialog to get the Shared Folder UID.
With Commander, execute the record-permission
command with the --dry-run
option to simulate the command. In this example, the Shared Folder UID is "-FHdesR_GSERHUwBg4vTXw". The command is below:
record-permission --dry-run --recursive --action grant --can-edit -- -FHdesR_GSERHUwBg4vTXw
Since the Shared Folder UID beings with '-' in this example, '--' must be added before the identifier
Running this command produces the following output:
The "SKIP" section is saying that the current user on Commander cannot make those requested changes, because we are not the owner of the record. The "GRANT" section indicates the changes that will be allowed.
To execute the command, we remove the "--dry-run" portion:
Now, on the Vault UI, the permission of those affected records has been changed to "Can Edit".
If you are in a situation with many record owners in the same shared folder that require update, each of those users can simply run the above Commander action to change the permissions of their respective records.
Hint:
If you are an enterprise-user with share-admin privileges, you need only perform the steps outlined above once to change permissions for all records (regardless of who owns those records) in the shared-folder.
In such a case, there is no need for other record-owners to repeat the same steps, thus greatly simplifying the process.
Using steps almost identical to those of the previous example (in which we show how to change permissions for all records within a shared folder), it is also possible to transfer ownership of all records within a given shared folder to a single account.
For the following example (using the same vault and shared folder as the previous example), let's assume that we would like to transfer ownership of the records in that shared folder to user joe.smith@gmail.com. The steps are as follows:
See previous example for details on how to do this. For this example, we'll be using the shared folder with UID -FHdesR_GSERHUwBg4vTXw
Similar to the previous example, we can simulate the desired action prior to its actual execution by running the share-record
command with the --dry-run
option in Commander (Note: unlike the previous example, we will also need to specify the username -- john.smith@gmail.com in this example -- for the account to which ownership of records should be transferred). The command is as follows:
share-record --action owner --email john.smith@gmail.com --dry-run --recursive -- -FHdesR_GSERHUwBg4vTXw
Finally, as in the previous example, we remove the --dry-run
option from our command call to perform the desired action, like so:
share-record --action owner --email john.smith@gmail.com --recursive -- -FHdesR_GSERHUwBg4vTXw
Management of KeeperPAM functionality including Discovery, Rotation, Connections and Tunneling
KeeperPAM including discovery, password rotation, PAM Configuration and Keeper Gateway configuration can be controlled and managed through Commander using the pam
command and sub-commands. These commands support the Password Rotation capabilities of Keeper Secrets Manager.
command: pam
Detail: Perform KeeperPAM controls.
Detail: View, create and remove Keeper Gateway services. To learn more about the Keeper Gateway click here.
Detail: View, create, edit and remove Keeper PAM Configurations. To learn more about PAM Configurations and Keeper rotation capabilities, read the Password Rotation documentation.
Detail: View and create Keeper Rotation configuration for records. To learn more about PAM Configurations and Keeper rotation capabilities, read the Password Rotation documentation. For detailed command information, use the -help option.
Detail: Discovery of privileged accounts through the Keeper Gateway
Commander can use credentials from your vault to facilitate connections directly from the CLI.
See the nested pages for more information on Commander's connection capability.
SSHSSH AgentRDPConnect CommandSFTP SyncUsing Keeper Commander with SSH connections
For a full remote connection management tool that supports privileged sessions, session recording and other advanced capabilities, we recommend using our new product Keeper Connection Manager ("KCM").
KCM is an agentless remote desktop gateway that provides secure and effortless access to RDP, SSH, database and Kubernetes endpoints through a web browser.
Learn more:
Keeper Commander can launch SSH connections utilizing content and metadata stored in a Keeper Vault record. The ssh
command is used to make SSH connections. To use this command, pass it a record that holds the SSH connection details.
Command: ssh
Detail: Establishes connection to external server using SSH.
Parameters:
record UID or path to a record
The SSH command is compatible with "SSH Key" and "Server" type records.
optionally a SSH endpoint in the following format:
LOGIN@HOST
[:PORT]
If no record is provided to the ssh
command, all the compatible records in your vault will be listed
Make a connection
See compatible records
Commander can run an SSH Agent service for establishing remote connections.
The ssh-agent
command is used to load up all of the SSH keys in the vault and start an SSH Agent service. SSH connections can be seamlessly established directly using the Keeper Commander SSH Agent without having to store keys on the local filesystem. SSH connections can then be established using any standard terminal.
The SSH agent service scans all records in the Keeper Vault based on different criteria such as:
A record type "SSH Key" or "Server" with a private key and optional password/passphrase
Any record with a single SSH key file attachment
Command: ssh-agent
Detail: Starts a local SSH Agent process on the local computer using keys from the vault.
Options:
start
: Starts the SSH Agent service and loads up all keys
stop
: Stops the SSH Agent service
info
: Displays SSH Agent status
log
: Displays connection log history
Starting the SSH Agent Service from the Commander CLI
Directly starting the SSH Agent without the shell:
To use the SSH Agent from your favorite terminal or connection tool, the environmental variable SSH_AUTH_SOCK must be set in the terminal or in your startup file. For example.... export SSH_AUTH_SOCK=~/.keeper/me@demo.com.ssh_agent Then, simply SSH from your terminal: $ ssh <host>
Stopping the SSH Agent service
Using Keeper Commander with RDP connections
For a full remote connection management tool that supports privileged sessions, session recording and other advanced capabilities, we recommend using our new product Keeper Connection Manager ("KCM").
KCM is an agentless remote desktop gateway that provides secure and effortless access to RDP, SSH, database and Kubernetes endpoints through a web browser.
Learn more:
Keeper Commander can launch RDP connections utilizing content and metadata stored in a Keeper Vault record. The rdp
command is used to make connections. To use this command, pass it a record that holds the RDP connection details.
Command: rdp
Detail: Establishes RDP connection to remote Windows servers. This command is only available on Windows machines running Commander.
Parameters:
record UID or path to a record
The RDP command is compatible with "Server" type records on Windows machines.
If no record is provided to the rdp
command, all the compatible records in your vault will be listed
Make a connection
See compatible records
Connect to RDP and SSH servers from the Commander CLI
The connect command is deprecated from Commander versions 16.5.8 and later.
For a full remote connection management tool that supports privileged sessions, session recording and other advanced capabilities, we recommend using our new product Keeper Connection Manager ("KCM").
KCM is an agentless remote desktop gateway that provides secure and effortless access to RDP, SSH, database and Kubernetes endpoints through a web browser.
Learn more:
Using the connect
command, Keeper Commander can launch SSH, RDP or other types of connections utilizing content and metadata stored in the Keeper Vault record. Command-line parameters and environmental variables can be supplied through custom fields and file attachments.
The connect
command reads the record's custom fields with names starting with "connect:
".
Command: connect
Detail: Connect directly to a server Using SSH, RDP, or other protocol.
Parameters:
Endpoint name or full record path to endpoint
Switches:
--syntax-help see help for command and template parameters
-n, --new request per-user data
-s, --sort <{endpoint, title, folder}> choose field to sort by
-f, --filter <FILTER BY> filter output
In this example, we are showing how to connect to a server through a SSH gateway. The following custom fields are set inside a Keeper record:
Custom Field Name | Custom Field Value |
connect:xxx:description | Production Server via Gateway |
connect:xxx | ssh -o "ProxyCommand ssh -i ${file:gateway.pem} ec2-user@gateway -W %h:%p" -i ${file:server.pem} ec2-user@server |
File Attachment | gateway.pem |
File Attachment | server.pem |
xxx
refers to the friendly name which can be referenced when connecting on the command line.
To connect to a server, simply run the below command:
If the SSH private key is encrypted with a passphrase, you will be prompted every time to type in the passphrase. To avoid this, we recommend using the SSH Agent variation described in the next section.
Commander can integrate with the local SSH agent to register RSA private keys. This eliminates the need for you to type in the SSH passphrase every time you connect to the remote system. Commander uses the SSH_AUTH_SOCK
environment variable on Mac OS / Linux systems. The PowerShell OpenSSH implementation is supported on Windows systems.
To enable integration with ssh-agent ensure that SSH_AUTH_SOCK
environment variable is set on Posix compatible systems. For Microsoft Windows, ensure the SSH Agent
system service is running. Keeper's connect
command uses SSH Agent to temporarily store the private key used in the connection session. After the session disconnects, the private key is removed.
To utilize SSH Agent for connecting to a remote system, simply add one additional custom field to the Vault record:
Custom Field Name | Custom Field Value |
connect:xxx:ssh-key:yyy | ${zzz} ${password} |
or SSH key is stored in the file attachment
Custom Field Name | Custom Field Value |
connect:xxx:ssh-key:yyy | ${body:zzz} ${password} |
or Reference to the record of SSH Key Type
Custom Field Name | Custom Field Value |
---|---|
connect:xxx:ssh-key:yyy | <RECORD UID> |
Here, xxx
is the friendly name of the connection. yyy
is an optional key name used with the SSH agent. zzz
references either the custom field (see the first screenshot below) or file attachment (see the second screenshot).
In this example, the first parameter references the private key, the second parameter references the passphrase used to encrypt the private key.
${password}
references the value stored in the record's Password field.
Connecting to the remote system using an encrypted passphrase is easy. In our example, to connect to the server called "example2":
The ssh-agent command can be used to manage the ssh agent within Commander.
Sub-commands:
start - start the ssh agent
stop - stop the ssh agent
info - see the status of the ssh agent
log - see the ssh agent logs
To connect seamlessly to a remote windows server using the standard Microsoft Remote Desktop application, Keeper executes a command pre-login, login, and post-login via system calls. In this example, the "pre-login" command stores the password temporarily in the Windows credential manager for the current user. The "login" command initiates the connection using an RDP template file and the stored credentials (the RDP template file is optional). Upon session termination, the "post login" command is executed that deletes the password from the credential manager.
Vault Record Fields:
Custom Field Name | Custom Field Value |
connect:rdp_demo:description | Remote connection to Demo Server |
connect:rdp_demo:pre | cmdkey /generic:12.34.56.78 /user:${login} /pass:${password} > NUL |
connect:rdp_demo | mstsc ${file:Default.rdp} |
connect:rdp_demo:post | cmdkey /delete:12.34.56.78 > NUL |
File Attachment | Default.rdp |
Note: The Default.rdp file is saved from Remote Desktop Connection with your desired configuration.
Supported parameter substitutions
You can customize the commands with parameter substitutions described below:
Listing all available connections
To get a list of available connections, type:
Initiating connections
To initiate a connection (using the SSH/RDP examples) from Commander simply type:
or
Alternatively, you can execute the connection from the terminal without the interactive shell:
Notes:
A single vault record can contain any number of connection references, or the connections can be separated one per record.
If a system command requires user interaction (e.g. if a passphrase is included on an SSH key file), Commander will prompt for input.
Just like any other Keeper vault record, a connection record can be shared among a team, shared to another Keeper user or remain private.
Sync files from a SFTP server with credentials in the Keeper Vault
Use credentials stored in the Keeper Vault to facilitate a connection to your FTP server, then Commander can automatically download files from the server to a specified location on your machine.
Secure your SFTP credentials, or automate file download or backup with Commander.
To use the Commander SFTP sync, utilize the rsync
command
The first time you run the SFTP sync, you need to provide the plugin type, path to remote files, and credentials record to use.
--plugin
the plugin type to use (use SFTP)
--remote-path
path to files you want to download in the SFTP directory
--record
UID or path to record that holds the SFTP credentials
Example:
Once you have specified these options once, Commander will retain the settings by saving them to the record you provided. Subsequent SFTP syncs can be run by only providing the location to download files to.
Commander can be automated in a number of ways. See the Batch Mode documentation for more information. This section will cover an example of automating the SFTP sync.
Commander can be configured to run commands on a given cadence by editing the Commander configuration file.
After you have run the first time setup for the SFTP sync, Commander can be configured to sync on a given cadence.
To automate Commander to sync with your SFTP server every 24 hours, add the following fields to the configuration:
"commands": ["rsync"],
"timedelay": 86400
Complete configuration file example:
Once configured, run Commander with the edited configuration file to start the automation. This can be done from the command line/terminal.
$> keeper shell --config "/sync.conf"
Note that there may be additional fields in your configuration file. See the documentation for more information.
Commander will continue to run while it waits for the next command run. If Commander is terminated, or the machine is turned off, Commander will need to be started again to continue.
Commands to configure and manage the Keeper Secrets Manager platform
Keeper Secrets Manager is a cloud-based, Zero-Knowledge platform for DevOps and engineering teams to centrally manage and control access to privileged accounts. Common use cases for Secrets Manager include:
Removing hard-coded credentials from source code, configuration files and CI/CD systems
Protecting access to privileged passwords, API keys and other managed secrets.
Providing vault access to machines and applications.
In Keeper Secrets Manager, an "Application" is created for every target environment which needs access to a specific folder in the Keeper Vault. An Application can be granted access to one ore more Shared Folders or records within the vault. An Application can be utilized by one or more "Clients" which are individually authenticated and managed by the Secrets Manager infrastructure.
As an example, a Keeper "Application" might represent a production system, and each individual web server in your production system would represent a Client. Each Client authenticates and communicates to the Keeper Vault using a Client ID and a Private Key which is used to sign the request.
The commands in this document can be used to configure the Keeper Secrets Manager applications and client devices.
secrets-manager app create <APPLICATION NAME>
This can be done on the Vault user interface, but we'll create a Secret, create a Shared Folder, then move the Secret into the Shared Folder. Example commands are below:
To find the Shared Folder or Record UID, use the 'ls -l' command or Vault user interface in the "info" dialog.
The output of this command provides the One Time Access Token that will be used on the client.
secrets-manager app list
secrets-manager app get <APPLICATION NAME|APP UID>
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
secrets-manager Command Format
Keeper Secrets Manager commands follow the format:
secrets-manager <command> <sub command>
For example to list all apps use the following command:
secrets-manager app list
A list of all secrets-manager commands and details about each are below
Command | Explanation |
| Create an application |
| Display information about a specified application |
| Remove an application |
| List all applications |
| Add secrets (records or shared folder) to an application |
| Remove secrets (records or shared folder) from an application |
| Add client to an application |
| Remove a client from an application |
Command: secrets-manager app create
Detail: Create a new application that will be used to link clients to secrets
Parameters:
Name of the application
Example:
Command: secrets-manager app get
Detail: Display information about a specified application
Parameters:
Name or UID of the application
Examples:
Command: secrets-manager app remove
Detail: Remove an application
Parameters:
Name or UID of the application
Examples:
Command: secrets-manager app list
Detail: List all created applications
Example:
Command: secrets-manager share add
Detail: Add secret (record or shared folder) to an Application
Switches:
--secret , -s <SECRET'S UID> secret to share. can be folder or record UID
--app, -a <APPLICATION RECORD UID> application to share with
--editable, -e Allow edits to the records
Examples:
Command: secrets-manager share remove
Detail: Remove secret (record or shared folder) from an Application
Switches:
--secret , -s <SECRET'S UID> secret to share. can be folder or record UID
--app, -a <APPLICATION RECORD UID> application to share with
Examples:
Command: secrets-manager client add
Detail: Add a Client to an Application that will be used to connect to the application. The output of this command is a one-time token which is used for initializing the Client device through the Secrets Manager SDK.
Switches:
--name [CLIENT NAME] : Name of the client (Default: Random 10 characters string)
--first-access-expires-in-min [MIN] : First time access expiration (Default 60, Max 1440)
--access-expire-in-min [MIN] : Client access expiration (Default: no expiration)
--unlock-ip : Does not lock IP address to first requesting device
--count [NUM] : Number of tokens to generate (Default: 1)
--config-init [json, b64 or k8s] : Initialize configuration string from a one-time token
--name [NAME] name of the client
Example 1: Create a new device called "Test 1" and produce a One Time Access Token.
Example 2: Create a new device called "Test 2" and produce a fully initialized JSON config file without IP lock. This config file can be loaded into a device directly.
Example 3: Create a new device called "Test 3" and produce a fully initialized base64 config string without IP lock. This config file can be loaded into a device as a single string instead of using a JSON config file.
Example 4: Create a new device called "Test 4" and produce a fully initialized Kubernetes config without IP lock. The YAML output can be cut-n-pasted into a file and applied to create as a Kubernetes secret.
Command: secrets-manager client remove
Detail: Remove a client from an Application
Switches:
--client <CLIENT ID> client to remove from the application
--app, -a <APPLICATION RECORD UID> application
--force don't ask for approval
Examples:
Commands specific to Managed Service Provider (MSP) tenants
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
MSP Commands
Command | Explanation |
Display MSP details | |
Refresh local MSP data from server | |
| View and manage MSP licenses |
Creates Managed Company | |
| Removes Managed Company |
| Modify Managed Company licenses |
Generate MSP Billing Reports | |
Generate MSP Legacy Report | |
Switch context to run commands as a managed company | |
Switch context to run commands as MSP | |
Convert an enterprise node into a managed company | |
Copy role enforcements from MSP to MCs | |
Options for managed MSPs. Edit licenses and view msp and mc details. |
MSP Commands require a MSP type Keeper Account and MSP Admin privileges
Command: msp-info
or mi
Detail: Display MSP details such as licenses and managed companies
Examples:
Show MSP Information
Example Output:
Command: msp-down
or md
Detail: Refresh local MSP data from server
Examples:
Download current MSP data from the Keeper Cloud
Command: msp-license
or ml
Detail: View and Manage MSP licenses
Switches:
-a
, --action
<{add, reduce, usage}> Action to perform on the license
add - add seats to the license
reduce - remove seats from the license
usage - see the number of seats used in the license (default)
Displays a table showing License Plan ID, available licenses, total allocated licenses, and Stash
--mc
<MANAGED COMPANY NAME OR ID> managed company to perform action on
note: see a list of managed company names and ids with the msp-info
command
-s
, --seats
<NUMBER OF SEATS> number of seats to add or reduce
example:
Show a list of MSP plans and Licenses
Add 4 seats to the plan of the company with and ID of 3984
Show a table of the license usage of the company with ID of 3861
Command: msp-add
Details: Creates Managed Company
Switches:
--plan
or -p
<{business, businessPlus, enterprise, enterprisePlus}> MC plan or product
--seats
or -s
<NUMBER OF SEATS> number of seats to add
Parameters:
Managed Company name.
Example:
When a new managed company is created, Commander saves the new mc id as an environment variable last_mc_id
See the
documentation below
about using this variable
Command: msp-remove
Details: Removes Managed Company
Parameters:
Managed Company name or ID
Example:
Command: msp-update
or mu
Details: Modify/Update Managed Company license
Switches:
--node
<NODE> Node name of Node ID
--plan
or -p
<{business, businessPlus, enterprise, enterprisePlus}> MC plan or product
--seats or -s <NUMBER OF SEATS> number of seats to add
--file-plan
or -f
<FILE_PLAN> File storage plan: 100gb, 1tb, 10tb
File Plan Options:
100gb
1tb
10tb
--add-addon
or -aa
[ADDON NAME] allow the MSP to use the addon
--remove-addon
or -ra
[ADDON NAME] remove the addon from the msp
Addon options:
compliance_report
enterprise_audit_and_reporting
secrets_manager
enterprise_breach_watch
onboarding_and_certificate
msp_service_and_support
connection_manager
chat
Parameters:
Managed Company name or ID
Example:
Command: msp-billing-report
Details: Generate MSP Billing Reports
Switches:
--month YYYY-MM.
Month for billing report: 2022-02
-d
or --show-date.
Breakdown report by date
-c
or --show-company.
Breakdown report by managed company
--format {json, csv, table}
format to return the list as
--output [filename]
if supplied, the output is saved to the given file
Command: switch-to-mc
Detail: Change context to the given managed company, all commands will be run for that company
Parameters:
Managed company ID
note: see a list of managed company IDs with the msp-info
command
Examples:
Change context to managed company with ID 3987
Command: switch-to-msp
Detail: Change context back to MSP if previously switched to managed company context
Examples:
Change context to MSP
Command: msp-convert-node
Detail: Convert an enterprise node into a managed company
Remove SSO provisioning before converting an enterprise node into a managed company
Examples:
convert the given node into a managed company
Command: msp-copy-role
Detail: Copy role enforcements from MSP to MCs
msp-copy-role <MC NAME> --role <ROLE NAME>
Parameters: MC name (Required) the name of the MC to copy a role to
Switches:
--role
<ROLE NAME> the role to copy
Examples:
The distributor command is available to distributor accounts which manage MSPs.
The distributor command allows you to: list manage MSPs and their MCs, manage and edit the licenses available to MSPs, and view the overall usage of all MSPs being managed.
Sub Commands:
info
View all managed MSPs
msp-info
View information and usage of a specified MSP
license
View or edit the license options for a specified MSP
Command: distributor info
Detail: Lists all managed MSPs
Switches:
--reload
reload the list of MSPs
--format
{json, csv, table} format to return the list as
--output
[filename] if supplied, the output is saved to the given file
--mc-details
show the managed companies under each MSP
Examples:
List manage MSPs
Save a report of all managed MSPs and their managed companies to a file
Command: distributor msp-info <MSP NAME>
Detail: View information of a specified MSP
Parameters: MSP name or ID
Switches:
--reload refresh MSP details
--format {json, csv, table} format to return the information as
--output [filename] if supplied, the output is saved to the given file
Examples:
See information about MSP "Bob's MSP"
Command: distributor license [MSP NAME, ID, pattern, ...]
Detail: View or edit license availability for a MSP
Parameter: MSP name or ID
Switches:
--add-product
[PRODUCT NAME] add a product as an offering for the MSP
--remove-product
[PRODUCT NAME] remove a product as an offering of the MSP
Product options:
business
enterprise
enterprise_plus
--add-addon
[ADDON NAME] allow the MSP to use the addon
--remove-addon
[ADDON NAME] remove the addon from the msp
Addon options:
compliance_report
enterprise_audit_and_reporting
secrets_manager
enterprise_breach_watch
onboarding_and_certificate
msp_service_and_support
connection_manager
chat
--max-file-plan
[AMOUNT] set the maximum file plan the MSP can offer
--allocate-unlimited
{true, false} if true, allow MSP to allocate unlimited licenses
Examples:
add the business product to the available offerings of "Bob's MSP"
Set the maximum file plan offering of "My MSP" and MSP #3456 to 1 Terabyte
Turn off the unlimited licenses for all managed MSPs
Helpful commands for miscellaneous functionality.
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Set device logout and persistent login preferences | |
| login to Keeper |
information on logged in user | |
| logout from Leeper |
| documentation on a given Commander command |
| download, sync, and decrypt vault |
| display Commander version and path information |
| clear the screen |
| Execute commands sequentially from the provided file. |
Generate a secure password | |
| Verify the integrity of imported records |
| Verify the integrity of records in shared folders |
| Reset the master password |
| Calculate and update security data for all user-owned password records (enterprise only) |
| Add delay (in seconds) between batch commands |
Display or manage KeeperFill settings | |
2FA settings management |
Command: this-device
Detail: Set device logout and persistent login preferences
Parameters:
None
Switches:
rename <Name of Device>: Change the name of the device
register: Encrypts the user's data key with the device public key in order to utilize persistent login sessions
persistent-login <ON|OFF>: Turn on or off the "Stay Logged In" setting for your account
ip-auto-approve <ON|OFF>: Control the IP Address device auto-approval security setting for your account
no-yubikey-pin <ON|OFF>: Turn on or off the PIN usage on Security Key (Webauthn) devices.
timeout: Set inactivity duration before automatic logout. Default unit is minutes (can be set to hours or days by appending "h" or "d", respectively).
Examples:
Display the available options
Rename the device that shows up in access logs
Enable "Stay Logged In" on the account
Register the user's "encrypted data key" with the server, for use in persistent login sessions
Enables IP Address auto-approval (applies to master password logins only)
Set the inactivity timeout to 10 minutes
Set the inactivity timeout to 24 hours
Command: login
Detail: Login to Keeper
Parameters:
Email address of account to login to
Switches:
-p, --password password of Keeper account
You will be prompted to enter the password if it is not provided with the switch
Examples:
Login to John Doe's Keeper account. Will be prompted for password
Login to Jane Doe's Keeper account with the given password
Command: whoami
Detail: Display information about the currently logged in user
Switches:
-v, --verbose include current datacenter and Commander environment
Examples:
See detailed user information
See detailed user information with the current datacenter and environment
Command: logout
Detail: Logout of Keeper
Examples:
Logout of Keeper
Command: help
Detail: Display information about a given Commander command or a list of all available commands.
Parameters:
A Commander command to see information for. To see a list of all available commands, leave unspecified.
Examples:
See detailed information on add command
See detailed information on sync-down command
See list of all available commands
Command: create-account
Details: Create a Keeper Account. You will be prompted to enter a password for the account, and then a verification email code.
Parameters:
Email address to use for the account.
Examples:
Command: sync-down
or d
Detail: Download, sync, and decrypt vault
Examples:
Sync vault
Sync vault
Command: version
or v
Detail: Display Commander version and path information
Switches:
-v display information about the underlying SDK, OS, working directory, and configuration file
Examples:
Show current Commander version
Show current Commander version, as well as the SDK version, OS, working directory, and configuration file
Command: clear
or c
Detail: Clear all lines from the screen
Examples:
clear all lines from the screen
Command: run-batch
or run
Detail: Execute commands sequentially from the provided file.
Switches:
-d [seconds]
Specify a delay of this number of seconds in between commands. This will help in preventing throttling on the backend.
-q
Quiet mode
-n
or --dry-run
Preview the commands that will be run without execution.
Examples:
Requires Commander v16.5.10+
Command: generate
Detail: Generate a secure password
Switches:
-cc
or --clipboard-copy
copy the created password to the clipboard
-nb
or --no-breachwatch
skip Breachwatch check
-f <{table, json}>
or --format <{table, json}>
select an output method for the generated password
requires Commander v16.5.11+
-i <NUMBER>
or --json-indent <NUMBER>
with json format:
0 for plain json output
a number greater than 0 to select the indentation for easy to read output
requires Commander v16.5.11+
-n [NUMBER]
or --number [NUMBER]
create the given number of passwords
-c [LENGTH]
or --count [LENGTH]
length of the password
-s [SYMBOLS]
or --symbols [SYMBOLS]
minimum number of special symbols to include in the password
-d [DIGITS]
or --digits [DIGITS]
minimum number of digits to include in the password
-u [UPPERCASE]
or --uppercase [UPPSERCASE]
minimum number of uppercase letters to include in the password
-l [LOWERCASE]
or --lowercase [LOWERCASE]
minimum number of lowercase letters to include in the password
-dr [DICE_ROLLS]
or --dice-rolls [DICE_ROLLS]
number of dice rolls
Examples:
Generate a secure password
Generate a secure password that is 12 characters longs with at least 2 uppercase letters and 2 symbols and copy the password to the system clipboard
Generate a password and show password strength, and Breachwatch result in plain json format
Generate 10 diceware passwords of 6 words
Requires Commander v16.7.6+
Command: generate --dice-rolls
Detail: Generate a dice roll secure password consisting of random words
Switches:
-dr
or --dice-rolls <NUMBER OF WORDS TO GENERATE>
generate a dice roll password, and identify how many words to generate
--word-list <WORD LIST FILENAME>
optionally use a file of words to use as a wordlist
Examples:
generate a password of 6 random words
generate a password of 5 random words from the given file of words
Command: verify-records
Detail: Check for record format integrity and perform necessary repairs to record structure. Edge cases are added to this command when issues in the field are reported to Keeper support.
Examples:
Command: verify-shared-folders
Parameters
Name or UID of shared folder to check. Leave blank to check all
Detail: Check for records in shared folders that do not have the correct shared data key, then add the correct key where needed
Examples:
Command: reset-password
Detail: reset the account's master password
Switches:
--delete-sso
deletes SSO master password
--current
the current master password
--new
the new password to set as master password
Examples:
Hint: you can use the generate command to generate a secure password within Commander
Command: security-audit sync
or sas
This command is available only to enterprise administrators
Detail: Sync security audit data for enterprise vault(s). Used to correct mis-matching summary security audit scores as seen by the user (in their vault) and by an enterprise administrator (either in the admin console app or via a call to security-audit-report
in Commander)
Parameters:
Username(s) of vault(s) whose security data are to be synced. Multiple values allowed. Specify@all
to perform sync for all enterprise vaults.
Switches:
--soft
Do a "soft" sync of security data. Does not require corresponding vault login. This is the default sync-type.
--medium
Do a "medium" sync of security data. Can sync some data without the corresponding vault login.
--hard
Do a "hard" sync of security data. No data are synced until the corresponding vault login occurs.
-f
or --force
Perform sync without being prompted for confirmation (non-interactive mode)
-v
or --verbose
Output a Security Audit report after performing sync
Examples:
Perform a "soft" sync of security data for vault owned by user1@domain.com
Initiate a "hard" security-data sync for the vaults belonging to user2@domain.com and user3@domain.com
Initiate a "hard" security-data sync for all vaults in the enterprise
Perform a "hard" sync of security-audit data for user1@domain.com and run a Security Audit report immediately after. Note that, in this scenario, you should expect the resulting report to show all 0s in the affected vault's summary scores (to be updated eventually once the affected owner logs in to their vault).
Hint: If the total password record count shown in a user's vault (in "Security Audit" view) differs from the corresponding value shown in the admin console (also in "Security Audit" view) or the output of Commander's security-audit-report --show-updated
command, use the --hard
flag to force a summary security audit score reset/re-calculation to re-align those values.
For more on the use of this command to correct mis-aligned security scores, please refer to the "Security Audit Report Score Re-alignment Process" section of our Troubleshooting page.
This command is deprecated. If your goal is to add delay between commands, please refer to the run-batch
command.
Command: sleep
Detail: Add delay (in seconds) between batch commands
Switches:
The number of seconds, the delay, to be added between batch commands
Example:
Sleep for 5 seconds
Command: keeper-fill
Detail: Display or manage KeeperFill settings. For example, this allows you to view/change the "Autofill" and "Auto Submit" preferences on a specific Keeper record.
To get help on the command run:
Possible values for "set" command: none, off, on.
If set to "none", the behavior of the browser extension is to follow the user preference (in the browser extension general Settings screen). If the value is set to "on" or "off", the browser extension will follow the setting for the record.
Example commands:
Command: 2fa
Detail: Display, add, or delete manage 2FA settings.
To get help on the command run:
Example commands:
Rotate passwords on any remote system using Keeper Commander plugins
Keeper has also launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for most password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
Commander KeeperPAM commands
Keeper Commander has a feature which can communicate to internal and external systems for the purpose of rotating a password and synchronizing the change to your Keeper Vault. We accomplish this by associating a Keeper record with a physical system through the use of custom fields. For example, you might want to rotate your MySQL password, Active Directory password and local Administrator password automatically.
Typed records add simplicity to Commander rotation. Commander can scan fields and make intelligent decisions about the rotation type, and connection details. Record types such as the standard "SSH Key" or "Server" types make it easy to create records that are ready for rotation.
Each rotation plugin has slightly different requirements, select from the list of plugins on the left nested under this page to learn more.
Commander will identify the type of rotation to use automatically based on the values supplied to the record. For example a record with a PORT value of 22 will use the SSH rotation plugin by default. The rotation plugin can also be specified during rotation or with a custom record field.
Optionally, any records can use custom fields as configuration for rotation. See table below for an example of custom fields.
Not sure the difference between typed and untyped records? See the Troubleshooting section
Older, non-typed records require some additional setup in order to support Commander rotation.
To support a rotation plugin, simply add a set of custom field values to the Keeper record. The custom field values tell Commander which plugin to use, and what system to communicate with when rotating the password. To modify your Keeper record to include custom fields, login to Keeper on the Web Vault or Keeper Desktop app.
Example custom fields for MySQL password rotation:
Custom Field Name | Custom Field Value |
cmdr:plugin | mysql |
cmdr:host | 192.168.1.55 |
cmdr:db | testing |
Typed records also support custom record fields. If an older record is converted to be typed (and the fields are unchanged) it will work with Commander rotation.
When a plugin is specified in a record, Commander will search in the plugins/ folder to load the module based on the name provided (e.g. mysql.py) then it will use the values of the Keeper record to connect, rotate the password and save the resulting data.
Check out the plugins folder for all of the available plugins. Keeper's team adds new plugins on an ongoing basis. If you need a particular plugin created, send us an email to commander@keepersecurity.com.
https://github.com/Keeper-Security/Commander/tree/master/keepercommander/plugins
To activate a plugin for a particular Keeper record, you first need to update the custom fields for that record with special keywords that are used by Commander. See the specific plugin for the custom field requirements.
To perform a rotation use the rotate
command.
Keeper's team is expanding the number of plugins on an ongoing basis. If you need a particular plugin created or modified, email us at commander@keepersecurity.com.
Commands for performing password rotations on target systems.
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
Whether using the interactive shell, CLI or JSON config file, Keeper supports the following commands, each command supports additional parameters and options.
To get help on a particular command, run:
help <command>
Command | Explanation |
| Rotate the password in a record |
| Set environment variables that can be used for substitution within other commands or arguments |
| Display environmental variables |
Command: rotate
or r
Detail: Rotate a record's password
To be eligible for rotation, a record must have the custom field 'cmdr:plugin'='noop'
Parameters:
Record name or UID to rotate
Switches:
--print display updated record content after rotation
--match <REGULAR EXPRESSION> select all records that match this expression to rotate
--password <NEW PASSWORD> sets a new password. Commander generates random password if switch omitted. Ignored when passwords are rotated with --match parameter.
Examples:
Rotate the password of the record titled "dev" in the "servers" folder
Rotate the password of the record with the given UID
Rotate the password of all records that end with "machine" (Using regex)
Rotate the password of the give record UID with the specific password provided
For more information and examples see Connection to hosts documentation
Command: set
Detail: Set an environment variable
Parameters:
environment name, value to set
format:
set <name> <value>
Examples:
Set the MySecret variable to XXX
Command: echo
Detail: Display environmental variables
Parameters:
argument to display (optional)
format:
echo ${<variable>}
If no argument is given, all environment variables are shown
Examples:
Display all currently set environment variables
Display the value for the MySecret variable
Rotate AWS Passwords and Keys
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
You need to configure your AWS environment on the environment with an account that has administrative privileges in order to modify the Password for the specified user.
Rotation supports legacy and typed records. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
To run a rotation of AWS Keys, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options below). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
The following optional values can customize rotation parameters. Add these options to a record as text fields and set the label to correspond to the parameter as shown in the table.
For an easier time creating new AWS rotation records, create a custom record type with the text type fields defined
Label | Value | Comment |
---|---|---|
cmdr:plugin | awskey | (Optional) Tells Commander to use AWS Key rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:aws_profile | (Optional) AWS profile to use to login to AWS with | |
cmdr:aws_sync_profile | (Optional) if supplied, the AWS secret for the given profile will be updated to the AWS credentials file | |
cmdr:aws_assume_role | AWS Role ARN | (Optional) if supplied, the password rotation plugin assumes this role. The role requires these permissions:
|
After rotation is completed, the Access Key ID and Secret Key are stored in custom fields on the record with labels: cmdr:aws_key_id
and cmdr:aws_key_secret
.
Any Keeper user or Keeper Shared Folder associated with the record is updated instantly.
Label | Value |
---|---|
cmdr:aws_key_id | generated AWS Access Key ID |
cmdr:aws_key_secret | generated AWS Secret Access Key |
The 'Password' field is ignored when rotating keys
To run a rotation of AWS passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options below). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
The following optional values can customize rotation parameters. Add these options to a record as text fields and set the label to correspond to the parameter as shown in the table.
Name | Value | Comment |
---|---|---|
cmdr:plugin | awspswd | (Optional) Tells Commander to use AWS Key rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:rules | (Optional) password complexity rules | |
cmdr:aws_profile | (Optional) AWS profile to use to login to AWS with |
The Password
field of the Keeper record contains a new password to AWS account.
Rotate Azure AD account passwords
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin generates/rotates Azure AD password for any user.
Rotation supports legacy and typed records. If using typed record, a 'Login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
Populate the 'Login' field of the Keeper record with the Azure login name
The following fields are required for Azure AD rotation. Create each field with the label indicated and supply the required information.
Label | Description |
---|---|
cmdr:azure_secret | Displayed upon Registration of a new application (under Azure portal -> |
cmdr:azure_client_id | Azure portal -> |
cmdr:azure_tenant_id | Azure portal -> |
cmdr:azure_cloud | Optional. Azure Cloud. There are 4 physical Azure cloud locations
1. |
For an easier time creating new Azure rotation records, create a custom record type with theses text type fields defined
The following values can customize rotation parameters. Add these options to a record as text fields and set the label to correspond to the parameter as shown in the table.
Label | Value | Description |
---|---|---|
cmdr:plugin | azureadpwd | (Optional) Tells Commander to use Azure AD Key rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:rules | (Optional) password complexity rules |
To rotate Azure passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
After rotation is completed, the new password will be stored in the Password
field of the record
Rotate SQL Server passwords
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin allows rotating a user's password in Microsoft SQL Server
Rotation supports legacy and typed records. If using typed record, a 'Login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
Commander will use these settings to connect.
TIP: If the port is set to 1433, or the host begins with "mssql://" Commander will automatically recognize the record as Microsoft SQL credentials and will use that rotation method unless otherwise configured
Commander will use the password to login to perform the rotation
Create a Text type custom field labeled "cmdr:db" and fill in the name of the database to connect to.
Instead of using the fields above, custom fields can be added with the shown label
Label | Value | Comment |
---|---|---|
cmdr:plugin | mssql | Tells Commander to use Microsoft SQL Key rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:host | Hostname of your MSSQL server | |
cmdr:rules | '# uppercase, # lowercase, # numeric, # special' (e.g. 4,6,3,8) | Password generation rules |
To rotate MSSQL passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here added to a record field, or automatically assigned based on the port number (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
After rotation is completed, the new password will be stored in the Password
field of the record
Rotate and Connect to MySQL databases with Keeper Commander
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
The MySQL Commander Plugin requires the PyMySQL plugin version 0.10.1 and does not support more recent versions.
Create a record using either the Keeper Vault UI, or Keeper Commander.
Commander rotation supports all record types. A "Login" field is required on the record.
If using an untyped record, the host and port can be set to custom fields. See below.
Commander will use the mysql plugin automatically for records with the port number 3306, or with a hostname that starts with "mysql//"
replace 'XXX' with the current database password for this user
Label | Value | Comment |
---|---|---|
cmdr:plugin | mysql | Tells Commander to use MySQL rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:host | Hostname of your MySQL server. This can be set here if not set in the record's host field | |
cmdr:rules | # uppercase, # lowercase, # numeric, # special' (e.g. 4,6,3,8) | Password generation rules |
cmdr:port | MySQL port. 3306 assumed if omitted This can be set here if not set in the record's host field | |
cmdr:user_host | User host. '%' assumed if omitted |
For Commander versions greater than 4.88
For Commander versions 4.88 and before
for more information about the edit command, see the command documentation
Find the UID in the record information popup
Use the search command to find the UID for your record. Replace "MySQL Example" with the name of your record.
To rotate MySQL passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here added to a record field, or automatically assigned based on the port number or based on the host starting with "mysql://" (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
After rotation is completed, the new password will be stored in the Password
field of the record
connect
commandCustom Field Name | Custom Field Value |
connect:xxx:env:MYSQL_PWD | ${password} |
connect:xxx | mysql -u${login} -h${cmdr:host} |
xxx
refers to the 'friendly name' which can be referenced when connecting on the command line
Here's a screenshot of the Keeper Vault record for this use case:
For more information on the connect
command, see the documentation
Rotate Oracle database passwords with Commander
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin allows rotating a user's password in Oracle Database Server
Oracle requires Instant Client setup to enable client applications.
Consult the following page: http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html
Rotation supports legacy and typed records. If using typed record, a 'Login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
To connect with DSN string:
Label | Value | Comment |
---|---|---|
cmdr:dsn | ex: "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=XE)))" | Oracle DSN string |
To connect using database host and service name
If cmdr:dsn
is used then cmdr:host
and cmdr:db
properties will be ignored.
Label | Value | Comment |
---|---|---|
cmdr:host | Hostname of your Oracle server | |
cmdr:db | Database service to connect to on Oracle server |
Label | Value | Comment |
---|---|---|
cmdr:plugin | oracle | (Optional) Tells Commander to use Oracle rotation. This should be either set to the record, or supplied to the rotation command |
Commander will use the oracle plugin automatically for records with a hostname that starts with "oracle//"
Record Example:
To rotate Oracle passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
After rotation is completed, the new password will be stored in the Password
field of the record
Rotate PostgreSQL database passwords with Commander
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin allows rotating a user's password in PostgreSQL Server
Rotation supports legacy and typed records. If using typed record, a 'Login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
Populate the 'Login' field of the Keeper record with the PostgreSQL login name
If using an untyped record, the host and port can be set to custom fields. See below.
TIP: If no rotation plugin is specified, Commander will use the port number or host prefix to guess which rotation to use. Port 5432, or a hostname that begins with "postgresql://" will use PostgreSQL rotation
Add a custom field to the record labeled "cmdr:db" and fill the field with the name of the database to use.
These fields can be added to affect the rotation
Label | Value | Comment |
---|---|---|
cmdr:plugin | postgresql | (Optional) Tells Commander to use PostgreSQL rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:host | Hostname of your PostgreSQL server. Legacy records require this custom field, typed records can use the hostname and port fields. | |
cmdr:rules | # uppercase, # lowercase, # numeric, # special' (e.g. 4,6,3,8) | (Optional) Password generation rules |
cmdr:port | (Optional) PostgreSQL port. 5432 assumed if omitted |
connect
commandCustom Field Name | Custom Field Value |
connect:xxx:env:PGPASSWORD | ${password} |
connect:xxx | psql --host=${cmdr:host} --port=${cmdr:port} --username=${login} --dbname=${cmdr:db} --no-password |
Here's a screenshot of the Keeper Vault record for this use case:
For more information on the connect
command, see the documentation
Rotate remote admin passwords with PSPasswd
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin provides IT Admins with the ability to rotate the password of a remote system's administrative local password. The password is rotated using the widely used "pspasswd" utility and the change is synchronized to a specific Keeper record in your vault.
The way this plugin is implemented requires that Commander and pspasswd is installed on the Domain Controller.
The instructions in this README assume that you are executing Commander scripts from the Domain Controller.
Assuming all computers are domain-attached and reachable from the Domain Controller, ensure that "Remote Service Management" is allowed for inbound in Domain by enabling the relevant Firewall rule on all computers.
On each of the target computers, go to Windows Firewall rules -> Inbound Rules -> and enabled the "Remote Service Management" rule.
Download the PSTools Package from Microsoft
Extract the PSTools.zip folder to a location on your computer
Add this PSTools folder to your user or system environmental variable "PATH"
(System Properties -> Advanced -> Environmental Variables)
Select PATH and then "Edit"
On some systems, you have to append the location where you installed PSTools, e.g.:
;C:\Users\craig\PSTools
On newer systems, just click "New" then type in the full path to the install, e.g.: C:\Users\craig\PSTools
Rotation supports legacy and typed records. If using typed record, a 'Login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
Populate the 'Login' field of the Keeper record with the login to use with this rotation.
If using an untyped record, the host and port can be set to custom fields. See below.
The following values can customize rotation parameters. Add these options to a record as text fields and set the label to correspond to the parameter as shown in the table.
Label | Value | Comment |
---|---|---|
cmdr:plugin | pspasswd | (Optional) Tells Commander to use PSPasswd rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:host | Hostname of Computer or Computers where the local account exists. This can be set here if not set in the record's host field | |
cmdr:rules | # uppercase, # lowercase, # numeric, # special (e.g. 4,6,3,8) | (Optional) Password generation rules |
To rotate PSPasswd passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
After rotation is completed, the new password will be stored in the Password
field of the record
Rotate SSH keys with Commander
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
The SSH plugin for Keeper Commander gives you the ability to generate and rotate SSH keys to one or more target systems, or rotate any local or remote user's Unix/Linux password.
This plugin requires OpenSSL and OpenSSH packages to be installed on the computer running Keeper Commander.
To verify Installation, open the Terminal application and make sure 'openssl'
and 'ssh'
commands are installed and accessible with the system PATH environment variable.
Plugin name: ssh
Rotation supports legacy and typed records. If using typed record, a 'Login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
The standard "SSH Key" record type is a good fit for SSH rotations.
See the Troubleshooting section for more information on legacy vs typed records
If using an untyped record, the host and port can be set to custom fields. See below.
TIP: If no rotation plugin is specified, Commander will use the port number to guess which rotation to use. Port 22 will use SSH rotation
The following values can customize rotation parameters. Add these options to a record as text fields and set the label to correspond to the parameter as shown in the table.
Label | Value | Comment |
---|---|---|
cmdr:plugin | sshkey | ssh | (Optional) Tells Commander to use ssh key or ssh password rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:host | (Optional) Host name or IP address of target server. Can be added as a custom field if not entered as a record field | |
cmdr:rules | # uppercase, # lowercase, # numeric, # special' (e.g. 4,6,3,8) | (Optional) Password generation rules |
For SSH Key rotation, In order to automate the rotation of the public key on the target server, the public key must be manually updated one time
in .ssh/authorized_keys on the target host(s).
After it has been set this first time, subsequent rotations will be automated and updated by Commander.
When setting up this plugin for the first time please use the following steps:
Populate the Title, Login, and Hostname or IP and Port fields of the Keeper record.
Execute the rotate
command on the Keeper shell for this record. Commander will generate the public and private keys and store them in the record. Copy or save the public key and save this to the file .ssh/authorized_keys
in the target hosts - this step must be done manually the first time or you can use the ssh-copy-id
unix command.
Make sure to set the permissions of the authorized_keys file on the target system. chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys
Execute rotate
command on Keeper shell to perform a full rotation. If successful, the target hosts will be updated with the newly generated public key and the Keeper record will be updated with the private/public key pair.
This plugin makes an assumption that the target system uses the default settings for SSH service, i.e. authorized_keys
file is located in the .ssh
directory of the user HOME directory.
For more information on the rotate
command see documentation
To rotate SSH passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options above). If not supplied, Commander will use the port field to identify which plugin to use. In this case port 22 means the ssh plugin is used. Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
Rotate Unix passwords with Commander
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin allows rotating a local user's password using the Unix passwd
command.
Rotation supports legacy and typed records. If using typed record, a 'Login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
Populate the 'Login' field of the Keeper record with the login to use with this rotation.
The following values can customize rotation parameters. Add these options to a record as text fields and set the label to correspond to the parameter as shown in the table.
Name | Value | Comment |
cmdr:plugin | unixpasswd | (Optional) Tells Commander to use Unix password rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:rules | # uppercase, # lowercase, # numeric, # special' (e.g. 4,6,3,8) | (Optional) Password generation rules |
To rotate Unix passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
After rotation is completed, the new password will be stored in the Password
field of the record
Rotate Windows user passwords with Commander
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin allows rotating a windows user's password using the net user
command.
Rotation supports legacy and typed records. If using typed record, a 'login' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
Populate the 'Login' field of the Keeper record with the login to use with this rotation.
This plugin rotates passwords for both local and Active Directory accounts. When rotating Active Directory password use DOMAIN\USERNAME
syntax for Login field.
Label | Value | Comment |
---|---|---|
cmdr:plugin | windows | (Optional) Tells Commander to use Windows rotation. This should be either set to the record, or supplied to the rotation command |
cmdr:rules | # uppercase, # lowercase, # numeric, # special' (e.g. 4,6,3,8) | (Optional) Password generation rules |
To rotate Windows passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
After rotation is completed, the new password will be stored in the Password
field of the record
Automatic password rotation with Commander
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
You can automate password resets using Commander plugins, with a custom Commander configuration file
Example:
In this example, we are telling Commander to first download and decrypt records, then rotate the password (record UID iaOXP1fnApRh5DbaRd7MWA) using the plugin programmed into the record. To locate the Record UID, simply view it on the commander interactive shell or view it on the Keeper Web Vault and Desktop App (as seen below).
For more information on running Commander commands with a configuration file, see the documentation
Active Directory plugin for Keeper Commander rotation
Keeper has launched a new Password Rotation feature with Keeper Secrets Manager. This new capability is recommended for all password rotation use cases. The Documentation is linked below:
Password Rotation with Keeper Secrets Manager
This plugin provides IT Admins with the ability to rotate the password of an Active Directory user account. This plugin can be run on any system that has network access to the AD server.
Rotation supports legacy and typed records. If using typed record, a 'Password' type field is required. Additional fields may be added depending on the rotation type as well. See the instructions below.
See the Troubleshooting section for more information on legacy vs typed records
If using an untyped record, the host and port can be set to custom fields. See below.
TIP: If no rotation plugin is specified, Commander will use the port number to guess which rotation to use. Port 389 will use AD rotation
The following fields are required for AD rotation. Create each field with the label indicated and supply the required information.
Label | Value | Comment |
---|---|---|
cmdr:use_ssl | True or False | Whether or not to use SSL connection to AD Server |
cmdr:userdn | Distinguished name of the AD user you want to rotate the password on. |
The following values can customize rotation parameters. Add these options to a record as text fields and set the label to correspond to the parameter as shown in the table.
Label | Value | Comment |
---|---|---|
cmdr:plugin | adpasswd | |
cmdr:host | Host name or IP address of your AD Server | |
cmdr:port | Optional: Port number of your AD Server. Default value: 389 | |
cmdr:rules | Optional password complexity rules |
To rotate Active Directory passwords, use the rotate
command in Commander. Pass the command a record title or UID (or use --match
with a regular expression to rotate several records at once)
The plugin can be supplied to the command as shown here, or added to a record field (see options above). Adding the plugin type to the record makes it possible to rotate several records at once with different plugins.
The Keeper "Login" field is not used for this plugin. The user is identified with the cmdr:userdn custom field.
If you get the error "Error during connection to AD server" try the following:
Ensure your AD supports secure bind via TLS. The certificate can be self-signed if needed.
Disable 'Minimum password age’ group policy. It is set to one day by default.
Verify connectivity to the host server, make sure it is accessible. Download a tool such as the Softerra LDAP Browser to test if you're able to connect to Active Directory.
Check that your Distinguished Name cmdr:userdn is set correctly. It needs to be exactly right or else the connection will fail. You can check the value of this from within the Softerra LDAP browser software or you can run the below command prompt utility on the AD Server:
For connecting as Craig in this scenario, make sure the cmdr:userdn custom field contains this exact string (without the quotes).
Microsoft Active Directory requires SSL connection in order to change the password. The following link explains how to setup a secure connection to Active Directory
Deprecated or legacy Commander Commands
Deprecated or unsupported commands will be listed here.