Commands

Keeper Command Reference

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

enterprise-info command

Command: enterprise-infoor 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:

enterprise-info
ei "John Doe" --users 
ei --teams --format csv --output teams.csv
ei --roles --columns is_admin,user_count
ei --node "Keeper Security"

1. Display the enterprise name and node structure

2. Search the enterprise for users named "John Doe"

3. Output a list of teams in the enterprise to a CSV file

4. Display a list of roles, and only show if they are an admin role and how many users are in the role

5. 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

enterprise-user command

Command: enterprise-useror 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:

enterprise-user John.Doe@gmail.com
eu 20379619819523 --node Chicago --add-team "Chicago Engineering"
eu add Jane.Doe@gmail.com
eu 19819523203796 --lock
eu --add-alias new.name@company.com old.name@company.com
eu --add-role Employee @all

1. Show details of user "John.Doe@gmail.com"

2. For the user with the given UID, add them to the Chicago node and the "Chicago Engineering" team

3. Send an invite to "Jane.Doe@gmail.com" to open a vault in the enterprise

4. Lock the account with the given UID

5. Add an alias for a user who changed their name and set as primary

6. Add all enterprise users to the "Employee" role

enterprise-role command

Command: enterprise-roleor er

Detail: Manage an enterprise role or enforcement policy

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:

enterprise-role -v "Keeper Administrator"
er 20379621916672 "Engineer Team Lead"
er --add Onboarding --new-users
er 20379621916672 --add-admin "John.Doe@gmail.com" --cascade yes
er PM --name "Product Manager"
er 20379619819524 20379619819525 20379621916672 --Node Chicago
er 20379619819524 --copy --Node Chicago

1. Show details about the "Keeper Administrator" role including all enforcements

2. Show details about the role with the given UID and the "Engineer Team Lead" role

3. Add a new role named "Onboarding" and make new users automatically assigned to this role

4. Make user John Dow admin of the role with the given UID and all child roles

5. Rename the "PM" role to "Product Manager"

6. Add the three nodes with given UIDs to the "Chicago" node

7. Create a copy of the role in the "Chicago" node

Changing Role Enforcements

enterprise-role ROLE --enforcement "<POLICY>:<VALUE>"

enterprise-role ROLE --enforcement "<POLICY>:$FILE=<PATH_TO_FILE_WITH_POLICY_VALUE>"

enterprise-role Engineering --enforcement "RESTRICT_IMPORT:True"

# command format
enterprise-role ROLE --enforcement "POLICY:VALUE"

# boolean (allow secrets manager)
enterprise-role Engineering --enforcement "ALLOW_SECRETS_MANAGER:True"

# string (restrict access to a domain)
er "Support Admin" --enforcement "RESTRICT_DOMAIN_ACCESS:https://www.baddomain.com"

# long (set minimum password length)
er users --enforcement "MASTER_PASSWORD_MINIMUM_LENGTH:10"

# ternary DEN (set auto fill to off)
er DB_Admin --enforcement "KEEPER_FILL_AUTO_FILL:d"
# ternary values: d:disable e:enable n:null
# Note - n:null removes the enforcement

# RESTRICT_RECORD_TYPES accepts a list of record types separated by comma
# to get a list of all available record types
My Vault> rti
  Record Type ID  Record Type Name
----------------  -----------------------
               1  login
              11  bankAccount
              14  address
              ...
              34  sshKeys
# to restrict sshKeys and address record types
My Vault> er Finance --enforcement "RESTRICT_RECORD_TYPES:sshKeys, address"
# restrict all record types (other than legacy general type)
My Vault> er Finance --enforcement "RESTRICT_RECORD_TYPES:all"

# ip-whitelist (allow logins only from specified IPs)
My Vault> er --enforcement "RESTRICT_IP_ADDRESSES:1.0.0.1-1.0.0.10,172.15.0.1,192.0.0.2" IP-Restricted_Role

enterprise-team command

Command: enterprise-teamor 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:

enterprise-team "Chicago Engineering"
et "Chicago Engineering" Legal 
et --add "Chicago Product" --node Chicago --restrict-edit on
et 20379619819524 --name "El Dorado Hills Engineering"

1. Show details of "Chicago Engineering" team

2. Show details for "Chicago Engineering" and "Legal" teams

3. Add a new team named "Chicago Product" in the "Chicago" node, and restrict users in the team from editing records

4. Change the name of the team with the given UID to "El Dorado Hills Engineering"

enterprise-node command

Command: enterprise-nodeor 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:

enterprise-node Chicago
en Chicago "El Dorado Hills" 20379619819524 --parent NA
en --add Cork --parent EMEA
en APAC --wipe-out
en Chicago --toggle-isolated
en --logo-file ~/chicago_logo.jpg Chicago

1. Show details for the "Chicago" node

2. For the three nodes: "Chicago", "El Dorado Hills" and node with the given UID, change the parent node to node "NA"

3. Add a new node named "Cork" under the "EMEA" node

4. Delete all nodes, roles, users, and teams from under the "APAC" node

5. Make the "Chicago" node invisible (if currently visible) or visible (if currently invisible) to people in other nodes

6. 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.

Custom Emails

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:

[Subject]
// Insert E-mail Subject line text

[Heading]
// Insert E-mail Message heading text here

[Message]
// Insert E-mail Message body text here

[Button Text]
// Insert the download button text here 

Custom Email Use Case

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:

en Chicago --invite-email="C:\user\emailTemplates\emailChicago.txt"
en Tokyo --invite-email="C:\user\emailTemplates\emailTokyo.txt"

When sending invitation emails, users will receive the following emails based on their branch location:

enterprise-push command

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:

enterprise-push office-codes.json --team "Chicago Office"
enterprise-push default.json --email Jane.Doe@gmail.com
enterprise=push --syntax-help

1. Send records templated in the "office-codes.json" file to every user in the "Chicago Office" team

2. Send records templated in the "default.json" file to user "Jane.Doe@gmail.com"

3. See the syntax help

File Format

The "enterprise-push" command uses Keeper JSON record import format.

Example JSON file:

[
    {
        "title": "Google",
        "login": "${user_email}",
        "password": "${generate_password}",
        "login_url": "https://google.com",
        "notes": "",
        "custom_fields": {
            "Name 1": "Value 1",
            "Name 2": "Value 2"
        }
    },
    {
        "title": "Admin Tool",
        "login": "${user_email}",
        "password": "",
        "login_url": "https://192.168.1.1",
        "notes": "",
        "custom_fields": {
        }
    }
]

Supported template parameters:

${user_email}          User email address
${generate_password}   Generate random password
${user_name}           User full name

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

export --format=json --folder=Templates templates.json

• 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.

enterprise-down command

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:

enterprise-down

team-approve command

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:

enterprise-down
team-approve --team
team-approve --email
team-approve --team --restrict-edit on

1. Sync down any pending Enterprise Team approvals

2. Automatically approve queued provisioned teams

3. Automatically approve queued provisioned users

4. Automatically approve queued provisioned teams and don't allow users in those teams to edit records

device-approve command

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:

device-approve
device-approve John.Doe@gmail.com --approve
device-approve --reload
device-approve --output device_approvals.csv --format csv

1. Show list of pending device approvals

2. Approve user "John.Doe@gmail.com"

3. Refresh list of pending device approvals

4. Write list of pending device approvals to a file in csv format

create-user command:

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.

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-user John.Doe@gmail.com
create-user John.Doe@workplace.com --name "John Doe" --node Chicago

1. Create a new user account and vault for John.Doe@gmail.com

2. Send an invitation to John Doe to join Keeper, name the new user "John Doe" and add him to the "Chicago" node

Onboarding with create-user Command

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.

My Vault> create-user John.Doe@gmail.com
User "John.Doe@gmail.com" credentials are stored to record "Keeper Account: John.Doe@gmail.com"

My Vault> share create "Keeper Account: John.Doe@gmail.com" --expire 7d
https://keepersecurity.com/vault/share#-Rkzr6w[...]wMw3fQ3kM

The new user will follow this url to receive their temporary credentials and perform the first login.

transfer-user command:

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-user keeperuser1@keepersecurity.com --target-user recipient@keepersecurity.com

1. 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:

user1@company.com -> user2@company.com
user3@company.com -> user4@company.com

automator command:

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.

When the automator command is executed without parameters it displays the list of available automators as well as a command help.

automator command [target] [--options]

 Command            Description
=================================================================
 list               Displays the list of the available automators
 create             Creates automator
 init               Initializes automator
 view               Prints automator details
 edit               Changes automator configuration
 delete             Deletes automator
 reset              Resets automator configuration to the default
 enable             Enables automator
 disable            Disables automator
 log                Retrieves automator logs
 clear              Clears automator logs
 certificate        Display certificate information.
 
 list, create:
 'target' parameter is ignored 
 
 init, view, edit, delete, reset, start, stop, log, clear:
 these commands require 'target' parameter: Automator Name or ID

 Option             Commands
==================================================================
 --node             create 
 --name             create, edit
 --url              edit : Webhook URL 
 --skill            edit : "device" and/or "team"
 --set              edit : KEY=VALUE

Examples:

Create automator with name "Cloud SSO Device Approval".

My Vault> automator create --name="Cloud SSO Device Approval"     

        Automator ID: 888888888888        
                Name: Cloud SSO Device Approval
                 URL:                     
             Enabled: No                  
         Initialized: No                  
              Skills: Device Approval

Edit automator to set the Webhook URL. The Webhook URL is provided by the Automator application.

My Vault> automator edit --url="https://automator.company.com:8089" 888888888888    

        Automator ID: 888888888888        
                Name: Cloud SSO Device Approval
                 URL: https://automator.company.com:8089                    
             Enabled: No                  
         Initialized: No                  
              Skills: Device Approval       

Skills (Team Approvals, Team-User Approvals, Device Approvals) can be set with the "skill" argument. For example:

My Vault> automator edit --url https://<application URL> --skill=team --skill=team_for_user --skill=device "My Automator"

Initialize the automator instance using "setup", "init" and "enable" commands. The backend verifies that the Automator is configured and ready to process requests.

My Vault> automator setup 888888888888
My Vault> automator init 888888888888
My Vault> automator enable 888888888888 

For more information about the Keeper Automator for SSO device approvals, see the Automator Service documentation.

scim command

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.

scim command [target] [--options]
 Command            Description
=================================================================
 list               Displays the list of SCIM endpoints
 create             Creates SCIM endpoint
 view               Prints SCIM endpoint details
 edit               Changes SCIM endpoint configuration
 delete             Deletes SCIM endpoint
 push               Pushes data to SCIM endpoint
 
 list, create
 'target' parameter is ignored 
 
 view, edit, delete
 these commands require 'target' parameter: SCIM endpoint ID
 
 Option             Commands
=================================================================
 --reload           all : Reloads SCIM configuration
 --node             create : Node ID or Name 
 --prefix           create, edit : Role prefix
 --unique-groups    create, edit : Unique groups 
 --force            delete : Do not ask for delete confirmation

Examples:

Create SCIM endpoint for node SCIM Node

My Vault> scim create --node="SCIM Node"                                                                                                                                                 

SCIM ID: 888888888888
SCIM URL: https://keepersecurity.com/api/rest/scim/v2/7777777777777
Provisioning Token: yIiq6Y4FnWtOPtqatUzZH7BI4FaUNhIbwEtDT5esL-g

Edit SCIM endpoint configuration. Editing SCIM endpoint generates a new provisioning token

My Vault> scim edit 888888888888 --prefix="Group_"                                                                                                                                   

SCIM ID: 888888888888
SCIM URL: https://keepersecurity.com/api/rest/scim/v2/7777777777777
Provisioning Token: 6oykLqC2-d20Sy3N2d-HKZtGzOt63U60rJz8CLagszY

Delete SCIM endpoint

My Vault> scim delete 820338837203                                                                                                                                                   

ALERT!
You are about to delete SCIM endpoint 888888888888

Do you want to proceed with deletion? [y/n]: y
SCIM endpoint "888888888888" at node "7777777777777" deleted

Push group and user data to SCIM endpoint

My Vault> scim push 820338837203 --source=google --record=AW6XZoJr8VM3rlFoxW_6rg

Switches

--source Source of SCIM data. Available values: google, ad

--record Record UID with SCIM configuration

Configuring SCIM source for push

• Common configuration steps

• Google Workspace

• Active Directory

audit-alert command

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

audit-alert command [--options]
 Command            Description
=================================================================
 list               Display alert list
 view               View alert configuration
 history            View alert history
 delete             Delete audit alert
 add                Add audit alert
 edit               Edit audit alert
 reset-counts       Reset alert counts
 recipient          Modify alert recipients  

To get help on command run

My Vault> audit-alert <command> -h

list options

  --format {table,csv,json} 
                        format of output
  --output OUTPUT       path to resulting output file (ignored for "table" format)
  --reload              reload alert information

My Vault> audit-alert list --reload
My Vault> aa l

view options

ALERT       Alert ID or Name.

My Vault> audit-alert view "Failed Login"
My Vault> aa v 1
              Alert ID  1
            Alert name  Failed Login
                Status  Enabled
             Frequency  Every Occurrence
            Recipients:
Send To Originator (*)  False

          Recipient ID  1
                  Name  Administrator
                Status  Enabled
              Email To  admin@company.com

history options

ALERT       Alert ID or Name.

My Vault> aa h 1                                                                                                                                           
Alert Sent At         Occurrences
---------------       -------------
2023-02-10 18:55:00              1

delete options

ALERT       Alert ID or Name.

My Vault> audit-alert delete "Failed Login"    

add options

  --name NAME           Alert Name.
  --frequency FREQUENCY
                        Alert Frequency. "[N:]event|minute|hour|day"
  --audit-event EVENT   Audit Event. Can be repeated.
  --user USER           Username. Can be repeated.
  --record-uid RECORD_UID
                        Record UID. Can be repeated.
  --shared-folder-uid SHARED_FOLDER_UID
                        Shared Folder UID. Can be repeated.

My Vault> audit-alert add --name="Failed Login" --frequency=event --audit-event=login_failure

edit options

  ALERT       Alert ID or Name.

  --name NAME           Alert Name.
  --frequency FREQUENCY
                        Alert Frequency. "[N:]event|minute|hour|day"
  --audit-event EVENT   Audit Event. Can be repeated.
  --user USER           Username. Can be repeated.
  --record-uid RECORD_UID
                        Record UID. Can be repeated.
  --shared-folder-uid SHARED_FOLDER_UID
                        Shared Folder UID. Can be repeated.

My Vault> audit-alert edit --frequency=2:hour   

reset-counts options

ALERT       Alert ID or Name.

My Vault> audit-alert reset-counts 1       

recipient options

ALERT       Alert ID or Name.

recipient actions:
  {enable,disable,delete,add,edit}
    enable              enables recipient
    disable             disables recipient
    delete              deletes recipient
    add                 adds recipient
    edit                edit recipient

recipient enable, disable. or delete options

  RECIPIENT   Recipient ID or Name. Use "*" for "User who generated event"

My Vault> audit-alert recipient 1 enable *
# enables "User who generated event"  
My Vault> audit-alert recipient 1 disable Administrator
# disables recipient by name
My Vault> audit-alert recipient 1 delete 1

recipient add or edit options

RECIPIENT   Recipient ID or Name.  # edit only
  --name NAME           recipient name
  --email EMAIL         email address
  --phone PHONE         phone number. +1 (555) 555-1234
  --webhook URL         Webhook URL. See https://docs.keeper.io/enterprise-guide/webhooks
  --http-body BODY      Webhook HTTP Body. @filename to load body from a file
  --cert-errors {ignore,enforce}
                        Webhook SSL Certificate errors
  --generate-token      Generate new access token

My Vault> audit-alert recipient "Failed Login" add --name="Administrator" --email=admin@company.com 
# add email recipient and assign name "Administrator"
My Vault> aa r 1 edit 1 --name="Admin"  
# change recipient #1 name on alert #1
My Vault> aa r 1 edit 1 --email= --phone="+1(555)555-1234"
# change recipient #1 on alert # 1 from email to Text Message

Overview

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.

Which method should I use?

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.

Invite Users to an Enterprise

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.

Format:

enterprise-user John_Smith@example.com --add

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.

Complete Example:

enterprise-user John_Smith@example.com --add --node "Chicago" --name "John Smith"

Find more information in the command documentation.

Invitation Email and Vault Creation

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.

Example: Invite Users from Email Addresses in a File

In this example, we will take a file with a list of email addresses and send an invite to each email address.

Setup

• 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:

this-device register
this-device persistent-login on

For more information on persistent login and options, see the documentation page.

Getting Started

First gather the email addresses into a file. In this example the file will look like this:

john_smith@example.com
jane_doe@example.com
mary_sue@example.com
chris_adams@example.com
amanda_patel@example.com

For this example, each email address is on its own line. The file can contain any number of email addresses.

Send Invites

Now that the file is ready, we can use a simple script to cycle through each email and send an invite.

for /f %e in (user_emails.txt) do keeper enterprise-user "%e" --add

while read email; do
   keeper enterprise-user "$email" --add
done < user_emails.txt

Run the script for your operating system from the examples above to send an invite to each email address from the file.

Advanced Example: Include User's Name and Node

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:

john_smith@example.com,John Smith,Chicago Office
jane_doe@example.com,Jane Doe,New York Office
mary_sue@example.com,Mary Sue,Chicago Office
chris_adams@example.com,Chris Adams,Chicago Office
amanda_patel@example.com,Amanda Patel,New York Office

Each line now has each user's email address, display name, and node separated by commas.

To include these details in the invitation command, we simply need to add the relevant flags to the script.

for /f "tokens=1,2,3 delims=," %e in (users.txt) do keeper eu "%e" --add --name "%f" --node "%g"

while IFS=, read -r email name node; do
   keeper eu "$email" --add --name "$name" --node "$node"
done < users.txt

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.

Create New User Accounts

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

Creating Users with Commander

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.

Format:

create-user John_Smith@example.com --node "Chicago"

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

Enterprises with MFA or SSO Login

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.

Differences with enterprise-user Command

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.

Creating User Accounts From a File

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:

for /f "tokens=1,2,3 delims=," %e in (users.txt) do keeper create-user "%e" --name "%f" --node "%g"

while IFS=, read -r email name node; do
   keeper create-user "$email" --name "$name" --node "$node"
done < users.txt

About

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 ReportsEnterprise Guide

The compliance-report command

The 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.

Cache

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

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.

Filters

The compliance report can be filtered by Node, User, Job Title and if the record is shared, deleted, or active.

Outputting to a File

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).

The compliance command

In 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:

• team-report

• record-access-report

• summary-reports or stats

• shared-folder-report

Refer to the sub command's section for more information.

Compliance Team Report

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.

My Vault> compliance team-report
Team Name    Team UID                Shared Folder Name  Shared Folder UID       Permissions            Records
-----------  ----------------------  ------------------  ----------------------  -------------------  ---------
Engineering  qLoY4YptKEs30VK_D8px1A  Devops Secrets      YZaagndh8CQToqlhuvv95Q  Read Only                    1
Marketing    XWLBkyN_HnwJKA4BYWrByw  Website Logins      -IcFcSgrFPEW9aP1-noiWw  Can Share, Can Edit          2

Compliance Record-Access 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 --email 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:

My Vault> compliance record-access-report --email user1@company.com
Vault Owner       Record UID              Record Title  Record URL     Has Attachments    In Trash    Record Owner       IP Address     Device             Last Access
----------------- ----------------------  ------------  -------------  -----------------  ----------  -----------------  -------------  -----------------  -------------------
user1@company.com LDUw6M6jNcUmEkuArp4LXQ  User1-Login   domain.com     False              False       user1@company.com  172.158.8.18   Web App 16.10.2    2023-05-30 17:04:23
                  5U4DK0MmJ5ZVui-o6JcDQw  User2-Login   google.com     True               False       user2@company.com  172.158.8.18   Web App 16.10.2    2023-01-24 17:04:18
                  MMhu6YQ5gKtYbgPiVD41UQ  User3-Login   hotmail.com    False              False       user3@company.com  172.158.8.18   Web App 16.10.2    2022-11-31 14:35:23

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 --email=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 1) specifying each username / ID separately, 2) by using the "@all" shorthand to indicate that you would like to run the report for all users or 3) by not providing a user — yet a more concise way to include all users in the report. This is illustrated in the following corresponding examples:

compliance record-access-report -e user1@company.com -e user2@company.com

compliance record-access-report --email @all

compliance record-access-report

Compliance Summary Report

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:

My Vault> compliance summary-report

Email                             Total Items    Total Owned    Active Owned    Deleted Owned
------------------------------- -------------  -------------  --------------  ---------------
bob.loblaw@keeperdemo.io                   22             14              12                2
jose.rizal@keeperdemo.io                   49             42              33                9
tyrion.lannister@keeperdemo.io              3              3               3                0
doogie.howzer@keeperdemo.io                15              5               5                0
alan.turing@keeperdemo.io                  17             13               4                9
richard.feynmann@keeperdemo.io              4              1               1                0
TOTAL                                                     78              58               20

Compliance Shared-Folder Report

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:

My Vault> compliance sfr
Loading record information....
Loading compliance data....:
Shared Folder UID       Team UID                Team Name    Record UID              Email
----------------------  ----------------------  ------------ ----------------------  ------------------------------
y01GmuTipqHGLdd0NkM4qw                                       PG7MELDIOaNMQkDiw--JoQ  bob.loblaw@keeperdemo.io
                                                             1JDuc5ZcJDpt8SbhYnD0HA  nate.hawthorne@keeperdemo.io
YZaagndh8CQToqlhuvv95Q  qLoY4YptKEs30VK_D8px1A  Engineering  IOYb8jAmDsaIGtTwZB5Biw  samuel.clemens@keeperdemo.io
                                                                                     w.b.yeats@keeperdemo.io
-IcFcSgrFPEW9aP1-noiWw  XWLBkyN_HnwJKA4BYWrByw  Marketing    O69TWFDnPCG_dpg9wpABqg  e.hemmingway@keeperdemo.io
                        qLoY4YptKEs30VK_D8px1A  Engineering  f46BWlqg5SoWraVlEFFSDA
0qpDTAWuznWrInnednG3Xw  XWLBkyN_HnwJKA4BYWrByw  Marketing    EnqP808xakJA9hOpjhYb9A  e.hemmingway@keeperdemo.io

See the Reporting Documentation for other reports available in Commander

Commands

Breachwatch Command

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:

breachwatch
breachwatch scan
breachwatch list
bw password n5@x85tG#gH7& my_dog_21
bw ignore qUX4gSrtDRfM1Kq9lrQi-w
bw report

1. See a summary of Breachwatch commands

2. Run a Breachwatch dark web scan and show which passwords are breached

3. List any records which have been marked as breached (and not ignored)

4. Check the passwords "n5@x85tG#gH7&" and "mydog21" for breaches using Breachwatch

5. Ignore the breached record with the given UID

6. Run a Breachwatch security report on users in your enterprise (only for admin accounts)

Automatic Scans

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.

For identity providers that don't support SCIM, customers can utilize the Keeper Commander scim push command to provision users and teams.

Common Setup Steps

Prerequisites: please be familiar with User and Team provisioning

1. Create a SCIM provisioning for your enterprise with the Admin Console or Commander

2. Create a record in Keeper with login record type to store the SCIM configuration

3. Paste the SCIM URL to the Website Address field of the Keeper record

4. Paste the SCIM Token to the Password field of the Keeper record

Google Workspace

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

(keeper) % pip install google-api-python-client

1. Google Cloud Platform: Create a project or chose an existing one

2. 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

3. 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.

4. Grant the Service Account access to your Google Workspace Directory

   • Google Cloud Platform

     • 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

5. 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

6. 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:

Pushing Provisioning Data

To perform a push of the Google users and Teams into Keeper, use the below command:

scim push <SCIM ID> --source=google --record=<RECORD UID>

The SCIM ID can be found in the Admin Console or using Commander. For example:

My Vault> scim list
        SCIM ID  Node Name              Node ID          Status   Last Synced
---------------  ---------------------  ---------------  -------  ------------
288797895952358  Lurey, Inc.\Corporate  288797895950343  active   Wed Jul  6 09:44:44 2022
288797895951707  Lurey, Inc.\Azure      288797895951061  active   Fri Jul  7 14:25:31 2023
288797895951110  Lurey, Inc.\Google     288797895951063  active   Mon May 30 23:42:52 2022

Automatic Provisioning of Google Workspace

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:

Google Workspace User and Group Provisioning with Cloud FunctionSSO Connect Cloud

Active Directory

The setup steps in this section allow you to provision users and teams from Active Directory using the scim push command.

Prerequisites:

1. In your Active Directory browser, create a Group and add AD users and groups that need to be provisioned in Keeper.

2. Get the Active Directory connect URL, e.g. ldap(s):<domain controller host or IP>

3. Pick a user that can read Active Directory

The Active Directory configuration record in Keeper should now contain the following fields:

Pushing Provisioning Data

To perform a push of the Active Directory users and Teams into Keeper, use the below command:

scim push <SCIM ID> --source=ad --record=<RECORD UID>