Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Your first steps with Keeper Commander
Follow these instructions to install Keeper Commander on your system
For supported CLIs and SDKs:
In order to add additional modules, change source code or make other edits to Commander, you will need to Install Commander in Developer mode. Developer mode clones the Commander source code to your local machine in a virtual environment.
How to install Keeper Commander on Mac OS
Mac OS 10.15 or above (Catalina)
Watch the video below to learn how to install and log in to Keeper Commander.
For mac installs download and install the file named:
keeper-commander-mac-vx.xx.pkg
Download and install Python
Depending on your operating system security settings you may need to "Allow" the application to run or install. To do this open "System Preferences" > "Security and Privacy" > "General" tab
Validate Python is correctly installed by checking the installed version from a terminal window:
From a terminal window, install Keeper Commander with pip3:
Once installed, ensure you have the latest version by upgrading Commander:
Please do not upgrade a production system without validation in your test environment as commands and functionality is under rapid development.
To see which version of Keeper you're running:
To validate Keeper Commander is properly installed login:
Note, for your first time logging into a new device or a new location, you may have to perform device authorization through email or other 2FA methods.
On the Commander Github page, the current commander build is always available via the .
Download the current version of Python from:
Installing the Keeper Commander PowerShell Module
Keeper Commander is available on the PowerShell Gallery as the PowerCommander
module. This document provides instructions for installing and using this PowerShell Module
Keeper's PowerShell command-line tool (PowerCommander) provides basic vault access and administrative functions.
PowerShell module for Keeper Commander is available on the PowerShell Gallery:
To install PowerCommander from PowerShell Gallery:
GitHub Repository
To run the PowerCommander module from the source, refer to the following GitHub Link:
https://github.com/Keeper-Security/keeper-sdk-dotnet/tree/master/PowerCommander
Set Execution Policy Permissions
If you are unable to run PowerCommander commands, you may need to set the Execution Policy. To check this, run the following command:
Your output would be similar to this:
If the Scope for your installation is Undefined
or Restricted
, set it to Unrestricted
with the following command:
Note: The above command set the CurrentUser
scope
f - folder
r - record
S - shared
A - file attachments
O - owner
where
kr
is alias for Get-KeeperRecords
2fa
is alias for Show-TwoFactorCode
where
contro
is a substring of the record title. See last entry of kdir
output above
kcc
is alias for Copy-KeeperToClipboard
or
'ktY3jEBqwFDi9UYZSxmIpw'
is the Record UID of the same record
Create a Keeper record
The above command copies all records in the current Keeper folder to the folder with name 'Shared Folder'
Cmdlet name
Alias
Description
Connect-Keeper
kc
Login to Keeper server
Sync-Keeper
ks
Sync with Keeper server
Disconnect-Keeper
Logout and clear the data
Get-KeeperLocation
kpwd
Print current Keeper folder
Set-KeeperLocation
kcd
Change Keeper folder
Get-KeeperChildItems
kdir
Display subfolder and record names in the current Keeper folder
Get-KeeperRecords
kr
Enumerate all records
Get-KeeperSharedFolders
ksf
Enumerate all shared folders
Add-KeeperRecord
kadd
Add/Modify Keeper record
Remove-KeeperRecord
kdel
Delete Keeper record
Add-KeeperFolder
kmkdir
Create Keeper Folder
Remove-KeeperFolder
krmdir
Remove Keeper Folder
Move-RecordToFolder
kmv
Move owned record to Keeper folder
Copy-KeeperToClipboard
kcc
Copy record password to clipboard
Show-TwoFactorCode
2fa
Display Two Factor Code
How to install Keeper Commander on Linux
Ubuntu (Current release and latest LTS release)
CentOS (Current)
RedHat (Current)
Watch the video below to learn how to install and log in to Keeper Commander.
Install Python 3.x
Install Package installer for Python
Based on your distribution, follow the instructions to install Python 3.x, typical installation commands are listed below.
OR
Also ensure the "Package installer for Python" is installed (you may need to run an apt-get update first):
OR
Next, upgrade pip3 to the latest version using the command:
Validate Python is correctly installed by checking the installed version from a terminal window:
Next, install Keeper Commander using pip3:
Once installed, ensure you have the latest version by upgrading Commander:
Please validate all updates in your test environment as commands and functionality is under rapid development.
Now you can launch the keeper shell using command:
You should see:
You can find a list of commands you can use at https://docs.keeper.io/secrets-manager/commander-cli/using-commander/command-reference
Note, for your first time logging into a new device or a new location, you may have to perform device approval through email or other 2FA methods.
Keeper Commander .NET Developer SDK
Keeper Commander is written in Python and available on Github. We also have another Commander SDK which is written in .Net. This page describes the .Net version of Commander.
Keeper's .Net Commander tool provides basic vault access, a developer SDK for vault access and administrative functions: https://github.com/Keeper-Security/keeper-sdk-dotnet
For source integration into your .Net code, please utilize the KeeperSDK Library source code: https://github.com/Keeper-Security/keeper-sdk-dotnet/tree/release/KeeperSdk
Find detailed API documentation at the following URL: https://keeper-security.github.io/gitbook-keeper-sdk/CSharp/html/R_Project_Documentation.htm
.Net Framework 4.5
.Net Core 2.1
.Net Standard 2.0
For help with implementation of SDK features, please see the Sample Application: https://github.com/Keeper-Security/keeper-sdk-dotnet/tree/master/Sample
The .Net Commander CLI Sample App contains several basic operations such as logging in, authentication with two-factor, loading and decrypting the vault and updating passwords.
https://github.com/Keeper-Security/keeper-sdk-dotnet/tree/release/Commander
Run Commander in the AWS Cloud
Commander is a powerful tool that can solve many issues and provide valuable information about your Keeper Security environment. In addition to using Commander on a local desktop or server, Commander can be run in a cloud environment such as AWS for performing scheduled or on-demand requirements.
In this example, we will demonstrate how to use Commander with AWS Lambda to run user and usage reports on a scheduled basis.
Commander
See the Installation and Setup page for download details
A Keeper user account with a Master Password login method (SSO login and MFA will not work without human interaction)
Access to AWS and permissions to create Lambda functions, and create layers in AWS Cloud9
Commander needs to be packaged on a machine that matches what it will run on in AWS Lambda. to do this, we can create the Commander package in Cloud9.
Select Amazon Linux 2 as Cloud9 platform.
In AWS Cloud9 check the version of installed Python interpreter.
As of March 2023, you can install Python3.8
In AWS Cloud9, create a layer via the zip file method and add a python directory
Use pip to install the following dependencies:
keepercommander
if Python3.8 was installed
Zip the now installed Commander package
Publish the Lambda layer
In AWS Lambda, use the Lambda editor to write a Python function.
The lambda_handler
function is triggered by Lambda when it is processed.
See a complete example of a Commander Lambda function below:
The function is made up of several parts:
This function is called when the lambda is triggered, all other functions should be called from this one.
Commander uses some parameters in order to authenticate the user account. We will attach these as environment variables and inject them into the Lambda. See further instructions below.
The above steps are all that are required to run Commander in Lambda, once they have been done and Commander SDK code can be performed.
In this example, we run a user status report and send the results to an email address.
Commander uses some parameters to authenticate the user account and identify what Keeper region to access. In order to pass these parameters into Lambda, we will set them as environment variables.
Commander automatically creates the required parameters when you login to the CLI. The easiest way to generate the required parameters is to login to the Commander CLI on your machine.
To get the Commander parameters, open the generated config.json file. By default this is located in the Users/[your username]/.keeper/
folder on your machine. See the config file documentation for more information.
You should see a file that looks similar to this:
To set the required Commander parameters as environment variables, first head to the lambda configuration and select "Environment Variables".
Set each commander parameter as an environment variable to be used by the Lambda.
You will also need to add your keeper master password to be used to login to Commander.
We are using environment variables to set the email addresses to send from and to for this example code. If you are not sending an email in your script, these are not needed
In the general configuration section of the Lambda configuration, it is recommended to change the timeout value. Some Commander functions take time, so if your script takes longer to complete than this number, the Lambda will automatically end without finishing.
You can set this to any number you are comfortable with. A value of 300 seconds (5 minutes) should be more than enough time for most processes.
In the Lambda editor, select the layer that you created above to include the Commander package in your Lambda build.
Create an EventCloud trigger to trigger the Lambda and set it to trigger at a cadence of your choice (for example once per day, or once every 30 days).
AWS can also be configured to trigger Lambda from a number of other sources including email and SMS triggers. See Amazon's documentation on invoking Lambda for more options:
In this example, we are sending an email with the report results. In order to enable the email, you will need to allow Lambda to access SES SendEmail/SendRawEmail
service.
You will also need to create an IAM identity to enable email sending.
For more information on setting up email sending with AWS, see Amazon's documentation:
In this example, we are sending an email with the report results. In order to enable the email, you will need to allow Lambda to access SES SendEmail
/SendRawEmail
service.
In this example, we run a report that combines the results of 2 Commander reports (security-report
and security-audit-report
) and send it via email as a JSON attachment, allowing us to obtain enterprise-wide security-monitoring data -- e.g., last-login date and overall security scores for each user in the enterprise -- in a regularly-scheduled and automated way. However, with this setup, any other set of Commander functions can be run with Lambda.
Experiment with other Commander functionality, Lambda invocation methods, and other AWS services (such as SNS for utilizing various methods for push notifications -- including SMS messages) to bring automated value to your Keeper processes.
For some examples of using the Commander SDK code, see the example scripts in the Commander GitHub repo:
To learn more about Commander's various methods, see the Command Reference section.
Environment Variable Name | Value | Example |
---|---|---|
KEEPER_USER
Keeper user account email address (config user
field)
user@example.com
KEEPER_SERVER
Keeper server domain (config server
field)
keepersecurity.com
KEEPER_CLONE_CODE
clone_code
field from config
36df3[...]A0dsa4g
KEEPER_PRIVATE_KEY
private_key
field from config
sxv[...]oz3p=fzw
KEEPER_DEV_TOKEN
device_token
field from config
xko[...]r2IxdiQ
KEEPER_PASSWORD
Password for keeper account
*****
KEEPER_SENDER
Email address to send emails from
user@example.com
KEEPER_SENDTO
Email address to send emails to
receiver@example.com
Protecting configuration with AWS Secrets Manager
Amazon AWS Key Management Service can be utilized on an EC2 instance hosting Keeper Commander in order to protect and store the configuration data.
The AWS Key Management Service protected storage resource URL format is as follows:
Example:
aws-kms://us-east-1/12345678-abcd-1234-dcba-123456789012
aws-kms://eu-west-1/alias/key
The secret name should contain URL-safe characters
Keeper Commander requires "key users policy" to be granted to AWS user or role.
Protecting configuration with AWS Secrets Manager
Amazon AWS Secrets Manager can be utilized on an EC2 instance hosting Keeper Commander in order to protect and store the configuration data.
The AWS Secrets Manager protected storage resource URL format is as follows:
Example:
aws-sm://us-west-2/commander/config
The secret name should contain URL-safe characters and not start with forward slash /
Keeper Commander requires the following access permissions to the secret resource
secretsmanager:GetSecretValue
secretsmanager:PutSecretValue
Example AWS policy granting access to secret
Keeper Commander installed with pip
requires boto3
package to present in the virtual environment
pip install boto3
How to login and use the Keeper Commander CLI
To login to Commander for the first time, click the Keeper Commander icon or open a shell and type:
Once the shell is open, begin the login by typing login
. If this is your first login, you will need to follow the device approval workflow. This is only needed once, as an extra layer of security to trust the device you are on.
First Login Example:
If you wish to approve via email:
Type email_send
or es
Enter the security code via email_code=<code>
If you wish to approve via Keeper Push:
Type keeper_push
Approve via push
Type approval_check
If you wish to approve via 2fa code:
Input 2fa_send
Input 2fa_code=<code>
Once complete you will receive the following message:
After device approval, you will immediately move to the login process, or if you previously approved the device, this will be the first step.
Login Example (approved device):
If you have 2FA enforced on your account, you will be required to pass the 2FA step before logging in with a Master Password. Your login flow in commander will follow the same rules you have for logging into the Vault.
Login Example (2FA):
Each 2FA method that is enabled will have a number next to it.
In this example, only TOTP is enabled, so 3
would need to be entered, followed by the TOTP code. Enter the corresponding number to proceed:
By default, Keeper Commander prompts for 2FA code on every login. To store 2FA authentication for this device either for 30 days or forever, type one of the following before entering the code:
2fa_duration=30_days
to prompt for 2FA every 30 days, or...
2fa_duration=forever
to never prompt again on this device
If your network configuration requires using a proxy server you can use the proxy
command before logging in.
If SSO is configured for your Keeper enterprise, the following screen will appear for users that login to Commander:
To login to Commander using SSO, you will need to paste a token provided by the SSO provider from your web browser into Commander. To receive the SSO token, follow these steps:
Option 1: Open the Page Automatically From Commander
To have Commander automatically open the default browser to the SSO Connect page, enter "o" in the SSO selection and hit Enter
The default browser for your system will open to the SSO Connect page.
Depending on your operating system, settings, and administrator privileges, Commander may be unable to open the web browser, in this case use the following option to open the SSO Connect screen.
Option 2: Paste the SSO Login Screen URL into a Browser
You can copy the URL to your SSO's logins screen from the SSO Connect text in Commander, or enter "c" in the SSO selection and hit Enter
to copy the URL to your clipboard.
Once the URL is copied, paste it into a web browser to navigate to the SSO Connect page.
After a successful SSO login, the web page will show a yellow "Copy" button. Click the button to copy the token.
Once the token has been copied, go back to Commander to complete the SSO login.
In Commander enter "p" in the SSO selection screen and hit Enter
to paste the token from your clipboard into Commander and complete SSO login.
If device approval is turned on for your account, the device approval selection will be shown after the first SSO login.
Enter your selection and hit Enter
to continue with device approval.
1 : Approve with Keeper Push
2 : Approve with Admin Approval
r : Resume SSO login after the device has been approved
See First Login on a New Device section for more details on device approval.
Customers who normally login to their Keeper Vault using Enterprise SSO Login (SAML 2.0) can also login to Keeper Commander using a Master Password. To make use of this capability, it must be enabled by the Keeper Administrator and then configured by the user. The steps are below:
(1) Login to the Keeper Admin Console
As the admin, login to the Keeper Admin Console as you normally do.
(2) Enable SSO Master Password Policy
For the User/Role who will be accessing Keeper Commander, open the Role Enforcement Policy setting screen. Enable the option "Allow users who login with SSO to create a Master Password"
(3) Login to the End-User Vault using SSO
As the user who will be using Commander, login to the Keeper Web Vault or Keeper Desktop app with your SSO provider as you normally do.
(4) Create a Master Password
Visit the Settings > General screen and setup a Master Password
After the Master Password is created, you are now able to login to Keeper Commander.
Add the following line to your configuration file.
Commander can be configured to stay logged in between sessions, and you can also configure how long the device will remain logged in without activity.
Use the this-device
command to set your preferences.
Example:
To enable "Stay Logged In" so that you're not prompted for authentication, use these commands:
If persistent login is enabled, you won't be prompted to authenticate the next time you run Commander:
Changing persistent-login ("stay logged in") affects all devices that you use with Keeper
To set the inactivity logout timer to a certain number of minutes:
Understanding the Commander configuration file for automation and CLI usage
When you login to Commander for the first time, a config.json
file is created, if one does not exist. When launching Commander as an application, the config file is created at ~/.keeper
on MacOS and Linux, and at C:\Users\[USERNAME]\.keeper
on Windows. When using Commander from the command line or terminal, the config.json
file is created in the current directory, unless the --config
option is passed a different location.
server
Keeper data center region
Commander defaults to the US region, so customers hosted in other regions will need to specify a server in the config.
debug
enable or disable detailed crypto output and network logging
set to true
or false
plugins
Set which password rotation plugin will be loaded.
Learn more about password rotation plugins for Commander.
commands
Comma-separated list of Keeper commands to run
timedelay
Run the specified commands every X seconds.
example: "timedelay":600
will run the commands every 10 minutes.
private_key
Device private key generated by Commander on a new device. This key is used to encrypt and decrypt vault data.
device_token
Device token generated by the backend for every new device. The device token is used to uniquely identify the device, and it controls the session behavior.
proxy
Proxy URL: schema://[user:password@]host:port
where schema
http
HTTP proxy
socks5
SOCKS5 proxy with local DNS
socks4
SOCKS4 proxy with local DNS
socks4a
SOCKS4 proxy with remote DNS
socks5h
SOCKS5 proxy with remote DNS
sso_master_password
Forces master password login for Enterprise SSO Accounts
skip_records
Prevents syncing of records if the value is set to true
. For users with very large vaults, this allows you to login and perform commands without requiring a full sync of records. After login, to force sync records use sync-down --force
Example line in config.json: "skip_records":true,
Using the commands
field allows for predetermined commands to be run on login.
Enter a comma-separated list of Keeper Commander commands to be run. Example:
In this example, it will sync, and then download a report of the available files in the vault.
If you start Commander from the binary installer, the config file will be located in the user's home directory in a folder called ".keeper".
On Mac environments, the configuration file is located in ~/.keeper/config.json
In Windows environments, the configuration file is located in /Users/{Username}/Documents/.keeper/config.json
If you use Commander from a pip3 or source installation, the configuration file will be created in the current folder where the Commander executable is started from.
You can specify the config file to use when launching Commander, for example:
In an environment with multiple servers or dynamic servers, you can use the same config.json
file for each instance as long as all of the fields are populated, and the device identifier has been "approved".
Example config.json
file:
As long as you have performed a device approval step at least one time, this configuration file can be loaded on any number of servers.
If you plan to distribute this file to multiple instances, we recommend protecting this file through secure storage facilities provided by your cloud infrastructure. We also recommend assigning the user account to a Role Enforcement policy on the Keeper Admin Console that is locked down based on IP range.
Persistent Login allows a Commander device to authenticate to Keeper without having to populate the "password" in the configuration file. This is useful for automation scripts or calling Commander from other software.
In order to enable this feature, you need to register the device and turn on the persistent login setting. Once that's done the next time you login with the specified configuration file, the session will be resumed and the user will be automatically logged in. Several tokens are stored in the config.json
file in order to resume a session automatically.
Commands to enable persistent login on a device for 30 days (max):
You can use seconds as the value (e.g. 60 for 60 seconds) or numbers and letters (e.g. 1m for one minute, 5h for 5 hours, and 7d for 7 days).
Also note that typing "logout" will invalidate the session. Just "quit" the Commander session to exit.
Once persistent login is set up on a device, the config.json
in the local folder will look something like this:
The configuration file can be modified to include auto-execution of commands or other features. See the configuration documentation for more details.
You can create any number of persistent login sessions. However, the persistent session option is not intended for dynamic multi-server environments. If you share the exact configuration file on multiple servers, persistent login will fail when attempting to login to the second server.
For multi-server dynamic environments, please refer to the prior section of using a fully populated config file that is distributed to each instance.
If you would like to maintain different configurations, you can run Commander with a specified config file. For example, this will open the CLI without prompting for login:
To leave the CLI, make sure to type "quit" instead of "logout". Typing "logout" will expire the session and you'll need to create a new persistent session config.
Another example would be executing a particular command without prompting for login. In the below example, a new record is created automatically with a single line.
You can batch execute a series of commands and pipe the file to STDIN of Commander. For example, create a text file called test.cmd
with the following lines:
To run this file in a batch mode:
or
Handling Errors
The batch execution is aborted if some command returns failure. Use @
in front of the command to suppress the possible command error.
Batch Mode in Windows
Following example shows how to execute three commands using Windows command line:
By setting up a persistent login configuration (as described in the previous section), you can execute a series of batch commands without any prompt for login. For example:
Keeper supports a batch mode from within the CLI which can conveniently execute commands sequentially.
The command is called "run-batch" and can be executed like below:
In this example, each command is executed with a delay of 10 seconds in between.
On Linux environments, the path can also be specified such as:
The sensitive configuration file parameters (user, password, server, device_token, private_key, clone_code) can be optionally stored in 3rd party secrets managers or hardware security modules.
To use protected storage, add config_storage
property to your config file. config_storage
value has URL format. Please reference the appropriate section below for storage URL format.
Commander supports the following protected storages:
Rotate passwords on any remote system using Keeper Commander plugins
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
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:
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:
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: 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
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:
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.
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
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.
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.
The Password
field of the Keeper record contains a new password to AWS account.
with Keeper Secrets Manager
For more information and examples see
with Keeper Secrets Manager
See the section for more information on legacy vs typed records
Label | Value | Comment |
---|
Label | Value |
---|
Name | Value | Comment |
---|
Region
Property Setting for "server"
US
https://keepersecurity.com
EU
https://keepersecurity.eu
AU
https://keepersecurity.com.au
GOV
https://govcloud.keepersecurity.us
CA
https://keepersecurity.ca
JP
https://keepersecurity.jp
Custom Field Name
Custom Field Value
cmdr:plugin
mysql
cmdr:host
192.168.1.55
cmdr:db
testing
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 |
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_key_id | generated AWS Access Key ID |
cmdr:aws_key_secret | generated AWS Secret Access Key |
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 |
cmdr:aws_profile | (Optional) AWS profile to use to login to AWS with |
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
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 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.
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.
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 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
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
commandxxx
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:
This plugin allows rotating a user's password in Oracle Database Server
Oracle requires Instant Client setup to enable client applications.
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.
To connect with 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.
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
(Optional)
Label | Value | Comment |
---|---|---|
Label | Description |
---|---|
Label | Value | Description |
---|---|---|
Label | Value | Comment |
---|---|---|
with Keeper Secrets Manager
Consult the following page:
See the section for more information on legacy vs typed records
Label | Value | Comment |
---|
Label | Value | Comment |
---|
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
cmdr:azure_secret
Displayed upon Registration of a new application (under Azure portal -> Azure Active Directory
-> App Registrations
-> New Registration
.
cmdr:azure_client_id
Azure portal -> Azure Active Directory
-> App Registrations
-> [App name] -> Application (client) ID
cmdr:azure_tenant_id
Azure portal -> Azure Active Directory
-> App Registrations
-> [App name] -> Directory (tenant) ID
cmdr:azure_cloud
Optional. Azure Cloud. There are 4 physical Azure cloud locations
1. Global
. Default location. Omit this property.
2. China
3. German
4. USGov
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
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
Custom Field Name
Custom Field Value
connect:xxx:env:MYSQL_PWD
${password}
connect:xxx
mysql -u${login} -h${cmdr:host}
cmdr:dsn | ex: "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=XE)))" | Oracle DSN string |
cmdr:host | Hostname of your Oracle server |
cmdr:db | Database service to connect to on Oracle server |
cmdr:plugin | oracle | (Optional) Tells Commander to use Oracle rotation. This should be either set to the record, or supplied to the rotation command |
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.
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 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:
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.
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.
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 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:
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.
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.
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.
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.
Label | Value | Comment |
---|---|---|
with Keeper Secrets Manager
See the section for more information on legacy vs typed records
with Keeper Secrets Manager
See the section for more information on legacy vs typed records
Label | Value | Comment |
---|
For more information on the rotate
command see
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
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 |
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 |
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
Instructions for installation of Commander with the intent on modifying source code
If you are a developer and you plan to create Python source code or set up a development environment based on the Github repository, you can use a virtual environment to isolate the environment for testing. Follow the below instructions:
Clone or download the Commander repository from: https://github.com/Keeper-Security/Commander
2. Install Python3
Find the most recent Python3 installation from python.org
3. Install Virtualenv
4. Create and activate the virtual environment for your keeper project
Virtualenv creation and activation differs on Mac OS/Linux and Windows operating systems. Please follow the corresponding instructions.
5. Install Commander to the virtual environment
You should be able to now login to the CLI by typing:
Additional Plugins
Keeper supports plugins for various 3rd party systems for password reset integration. Depending on the plugin, you will need to also install the modules required by that plugin. For example, our MySQL plugin requires the PyMySQL module.
See Password Rotation Plugins section for more information about Commander plugins.
After you have installed Keeper Commander in developer mode, you can simply login using the keeper shell
command:
Several standalone python scripts can be found here, with examples for searching records, creating teams and sharing folders, and more.
Setup Complete
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.
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.
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
Label | Value | Comment |
---|---|---|
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.
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
Instructions on uninstalling Keeper Commander
If you installed Keeper Commander with pip3, you can uninstall Keeper Commander by invoking the following command:
You will be prompted to confirm uninstallation:
If you installed Keeper Commander using the Windows binary, follow the following steps to uninstall:
Open Control Panel
Navigate to Programs > Programs & Features
Right Click "Keeper Commander" and select "Uninstall"
Follow the prompted directions on screen
For alternative ways on uninstalling program on Windows, refer to this page.
If you installed Keeper Commander using the Mac binary, follow the following steps to uninstall:
Open Finder
Navigate to Application Folder
Right Click "Keeper Commander" and select "Move to Trash"
How to install Keeper Commander on Microsoft Windows
Windows 10 (1903 and above)
Windows Server 2016 (1803 and above)
Watch the video below to learn how to install and log in to Keeper Commander.
The binary download is the file named:
keeper-commander-windows-vX.XX.exe
Note about Windows installs: - You may have to right click on the executable and go to properties to unblock the file. - You need to have admin rights to install Commander - Sometimes antivirus may block the files, create a one time exception to install as needed
Recommended releases:
Windows 11 - Python 3.10.8
Windows 10 - Python 3.10.8
Server 2018 - Python 3.10.8
Server 2016 - Python 3.9.13
On the first screen of the installation, opt-in to include python.exe in the PATH
Validate Python is correctly installed by checking the installed version from launching the cmd prompt.
From the command prompt, install Keeper Commander with pip3:
Once installed, ensure you have the latest version by upgrading Commander:
Please validate all updates in your test environment as commands and functionality is under rapid development.
Login to Keeper in order to validate Keeper Commander is properly installed:
Note, for your first time logging into a new device or a new location, you may have to perform device authorization through email or other 2FA methods.
On the Commander Github page, the current commander build is always available via the .
Download the current version of Python from
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
connect
commandHere's a screenshot of the Keeper Vault record for this use case:
For more information on the connect
command, see the documentation
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
Custom 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
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.
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
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