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...
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...
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...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Quick start guide to Keeper Password Rotation
Rotation is a feature of Keeper Secrets Manager ("KSM"). Once you have activated Keeper Secrets Manager on your account, you can enable the Rotation feature for specific roles.
Log in to the Keeper Admin Console for your tenant.
Go to Admin > select a Role (or create new Role) > Enforcement Policies > Secrets Manager
Enable both policies:
Enable Keeper Secrets Manager: This activates the Secrets Manager functionality in the Vault, which is needed for rotation.
Manage Keeper Rotation: This allows users to deploy gateway and configure rotation for privileged access records in their vaults.
Rotation can also be enabled on the Keeper Commander CLI using the enterprise-role
command. The enterprise-role
command allows you to manage enforcement policies.
Prior to enabling rotation, you need to enable the KSM feature for a role:
After enabling KSM, you can enable the Rotation feature for the same role with:
After Enabling Keeper Rotation on a role, 4 new record types will become available in your vault. The users of that role will be able to the create the following new records types:
PAM User Contains a login / password, private key, or both.
PAM Directory Information about your on-prem or cloud-based directory
PAM Database Self-hosted or managed cloud-based databases such as MySQL, SQL Server, etc
PAM Machine Windows, Linux, macOS machines on-prem or in the cloud
All 4 record types can be added in the Vault, placed in folders, and shared like any other Keeper records. These records can be shared with non-privileged Keeper users, but they cannot be rotated unless the user has the "Manage Keeper Rotation" role enforcement policy enabled.
For more information on these record type and the role they play in Rotation, visit:
When rotation is activated, within the Secrets Manager screen of the vault you'll see a section called PAM Configurations. A PAM Configuration is an object which is contains the following:
Environment Local Network, AWS or Azure
Keeper Gateway Service which you install into your on-prem or cloud infrastructure
Application Folder Shared Folder which contains the Secrets Manager application and associated records
Administrative Credentials Keeper record which contains privileged credentials for performing rotation and discovery.
Customers may have any number of PAM Configurations, Applications and Gateways.
The basic steps to rotation of passwords in any target environment are:
Create a Shared Folder in the vault
Add PAM Directory, PAM Database or PAM Machine records to the Shared Folder
Add PAM User records to the Shared Folder
Create a Secrets Manager application
Assign the Secrets Manager application to the Shared Folder
Set the shared folder permissions from Read Only to Can Edit
Add a Keeper Gateway to the Secrets Manager application
Create a PAM Configuration which ties everything together
Automatically rotate secrets in the cloud and on-prem
Activation of Password Rotation requires a Keeper Secrets Manager license. This capability can be activated at the role level from the Admin Console under Role > Enforcement Policies > Secrets Manager. If you have questions, please email feedback@keepersecurity.com.
Keeper Password Rotation allows Keeper customers to securely rotate credentials in any cloud-based or on-prem environment. Automatically rotate Active Directory accounts, Windows or Linux Users, Database passwords, Azure IAM accounts, AWS accounts, SSH keys and many more. All components of rotation adhere to Keeper's Zero Trust and Zero Knowledge security model.
For many organizations, periodic rotation of credentials is mandated by the company or compliance policy. Automating this with Keeper removes the trouble associated with ad-hoc or manual password rotation. Keeper's encryption model preserves the principle of Zero-Knowledge, ensuring that data is encrypted and decrypted locally in the customer's environment.
Keeper Password Rotation has been engineered in the cloud to provide the strongest security possible, while making deployment simple in any environment. Least privilege is enforced throughout the lifecycle and operations of the platform. Orchestration of password rotation is managed through the use of encrypted vault records.
Managing both secrets and their settings as encrypted records provides several benefits:
Secure sharing of records and configuration between IT users
Redundancy and data integrity
Audit logging and change history for rotation actions
All of this is built into an easy-to-manage enterprise password management platform, bridging the gap between the security challenges faced by IT and the needs of the workforce.
Automatically rotate credentials for machines, service accounts, and user accounts across your infrastructure and multi-cloud environments.
Schedule rotations to occur at any time or on demand
Perform post-rotation actions such as restarting services, or running other applications as needed
Securely store all credentials in the Keeper vault
Control and audit access to credentials through secure sharing and compliance reporting
Log all actions to Keeper’s Advanced Reporting and Alerts Module (ARAM)
Automate everything with Commander or using the Vault and Admin Console UI
Installation and setup of the Keeper Gateway
The Keeper Gateway is a lightweight service that is installed on any Windows, Linux or macOS machine in order to execute rotation, discovery and connection tasks. A single Gateway can be used to communicate with any target infrastructure, both on-prem and cloud. For example, to rotate Active Directory accounts, the Gateway can be installed on any machine which can communicate to AD.
Disk space required: 50MB
Memory: 1GB+
The Keeper Gateway generates encryption keys and a local Secrets Manager configuration that is used to authenticate with the Keeper cloud. The location depends on the context in which the Gateway is being run. It can be installed to the local user or installed as a service.
Login to the Keeper Web Vault or Desktop App
Create a Secrets Manager Application or select existing application
Click on the "Gateways" tab and click "Provision Gateway"
Select Windows, Mac or Linux install method
Install the Keeper Gateway using the provided method
During the creating of a Keeper Gateway, you have the choice to select "Lock external WAN IP Address of device for initial request". This will additionally IP lock the Gateway in addition to the authentication and encryption built into the service. This option is recommended as long as the external IP of your gateway machine is static.
Based on your Operating System, refer to the corresponding guide on installing the Keeper Gateway:
Keeper Admins can view and monitor all Gateways created under the enterprise environment. In the Secrets Manager section of the Keeper Admin Console, visit the "Gateways" tab.
Admins can see the status, creation date, and node assignment for all gateways. By clicking the Edit button, the Gateway name and Node can be modified, and a list of attached configurations and rotation history can be viewed.
The Gateway preserves zero knowledge by performing all encryption and decryption of data locally. The Gateway uses Keeper Secrets Manager APIs to communicate with the Keeper cloud. A full description of the security architecture can be found .
(minimum OS version: Server 2016+ 1803 and newer)
: Ubuntu, CentOS, and RedHat
: 12+
If you are installing on an EC2 instance in AWS, the Keeper Gateway can be configured to use the instance role for pulling its configuration from AWS Secrets Manager. Detailed instructions on this setup can be .
Instructions for installing Keeper Gateway on MacOS
This document contains information on how to install, configure, and update your Keeper Gateway on MacOS.
Prior to proceeding with this document, make sure you generated a Keeper Gateway One-Time Access Token in your Vault. For more information, visit the following page:
Note: On macOS, the Gateway can only be installed as the local user and not as a service
Executing the following command will install the Keeper Gateway:
Executing the following command will install and initialize the Keeper Gateway:
Note: Replace XXXXX with the One-Time Access Token supplied by the Vault screen, more information here
The gateway will be installed in the following location:
An alias gateway
is also created:
After installation, To start the gateway on the local Terminal, type:
If the Gateway was never initialized, you will be prompted for an One-Time Access Token, more information here
The Keeper Gateway configuration file contains a set of tokens that includes encryption keys, client identifiers, and destination server information used to authenticate and decrypt data from the Keeper Secrets Manager APIs. This configuration file is created from the Gateway One Time Access Tokens and have a one to one relationship with client devices.
The gateway configuration file is stored in the following location:
Logs that contain helpful debugging information are automatically created and stored on the local machine.
The gateway log files are stored in the following location:
To upgrade the Keeper Gateway service:
Stop the current Gateway service
Install the new binary by executing the following command:
Executing the following command will uninstall the Keeper Gateway:
Instructions for installing Keeper Gateway on Linux
This document contains information on how to install, configure, and update your Keeper Gateway on Linux.
Prior to proceeding with this document, make sure you generated a Keeper Gateway One-Time Access Token in your Vault. For more information, visit the following page:
Executing the following command will install the Keeper Gateway:
Executing the following command will install, initialize the Keeper Gateway, and run it as a service:
Note: Replace XXXXX with the One-Time Access Token supplied by the Vault screen, more information here
The gateway will be installed in the following location:
An alias gateway
is also created in the same directory
For managing the Keeper Gateway as a service, the following are created during the Gateway installation:
A keeper-gateway
folder
A keeper-gw
user
keeper-gateway folder
The keeper-gateway
folder contains the gateway configuration file and is created in the following location:
keeper-gw user
During the gateway installation, a new user, keeper-gw
, is created and added to the sudoers list in /etc/sudoers.d/.
The keeper-gw
user is the owner of the keeper-gateway folder and runs the gateway service. This is required when performing rotations on the gateway service and performing post-execution scripts.
The following commands can be executed to start, restart, or stop the Keeper Gateway as a service:
The Keeper Gateway configuration file contains a set of tokens that includes encryption keys, client identifiers, and destination server information used to authenticate and decrypt data from the Keeper Secrets Manager APIs. This configuration file is created from the Gateway One Time Access Tokens and have a one to one relationship with client devices.
If the Keeper Gateway is installed and running as a service, the gateway configuration file is stored in the following location:
If the Keeper Gateway is installed locally and not running as a service, the gateway configuration file is stored in the following location:
Logs that contain helpful debugging information are automatically created and stored on the local machine.
If the gateway is running as a service, the gateway log files are stored in the following location:
If the gateway is not running as a service, the gateway log files are stored in the following location:
To add verbose debug logging, modify this file:
and add the -d
flag to the "gateway start" command, e.g:
Apply changes to the service:
Executing the following command will upgrade the Keeper Gateway:
Configure your Keeper Gateway installation to automatically check for updates, ensuring it stays up-to-date with the latest version. For more information, refer to the following:
Executing the following command will uninstall the Keeper Gateway:
Instructions for installing Keeper Gateway on Windows
This document contains information on how to install, configure, and update your Keeper Gateway on Windows.
Prior to proceeding with this document, make sure you generated a Keeper Gateway One-Time Access Token in your Vault. For more information, visit the following page:
https://keepersecurity.com/pam/keeper-gateway_windows_x86.exe
Upon installation of the service, select "Enter a Keeper One-Time Access Token" and supply the token provided by the Gateway setup screen on the Vault. After installation, the service will automatically start up and register with the Keeper cloud.
For information on how to generate the Keeper One-Time Access Token for the gateway, visit this page
The default installation location is the following:
Keeper recommends that the Keeper Gateway is installed as a service.
After selecting the installation location, you will be prompted with the following:
Setup Options Details:
Install Windows service - Installs the gateway as a window service
Use service account - If checked, use the specified service account, otherwise the account installing the gateway will be used
Start Windows service - if checked, start the Keeper Gateway service immediately after installation
Turn on debug logging - Enable verbose logging on the gateway log files
If "Use service account" is specified you will be prompted to enter the valid credentials of the desired service account:
The final step prior to successfully installing the Keeper Gateway as service is to enter the One-Time Access Token:
After clicking "Next", click "Install" in the prompted screen to successfully install the Keeper Gateway.
After installing and running the Keeper Gateway as a service, this service can be accessed and easily managed within the Windows Services Manager as "Keeper Gateway"
The Keeper Gateway configuration file contains a set of tokens that includes encryption keys, client identifiers, and destination server information used to authenticate and decrypt data from the Keeper Secrets Manager APIs. This configuration file is created from the Gateway One Time Access Tokens and have a one to one relationship with client devices.
If the Keeper Gateway is installed and running as a service, the gateway configuration file is stored in the following location:
If the Keeper Gateway is installed locally and not running as a service, the gateway configuration file is stored in the following location:
Logs that contain helpful debugging information are automatically created and stored on the local machine.
If the gateway is running as a service, the gateway log files are stored in the following location:
If the gateway is not running as a service, the gateway log files are stored in the following location:
To activate verbose logging:
Go to Windows Services > Keeper Gateway > Properties
Stop the service
Set the "Start parameters" to: --debug
or -d
Start the service by clicking on "Start" Do not click "OK" without first starting the service as it will not persist the Parameter setting
To upgrade, stop the service, install the latest executable and then start the service.
Back up your configuration .json file
Uninstall Keeper Gateway from "Add and remove programs"
Install Keeper Gateway (do not select "Enter a Keeper One-Time Access Token")
Configure your Keeper Gateway installation to automatically check for updates, ensuring it stays up-to-date with the latest version. For more information, refer to the following:
This section provides instructions for performing a silent installation of the Keeper Gateway on Windows systems. Silent installation allows the setup process to run in the background without displaying any user interface or messages.
To install Keeper Gateway silently, use the following command in your command prompt or script:
Replace <YOUR ONE-TIME ACCESS TOKEN>
with the actual token generated for your Keeper Gateway installation.
Existing Configuration: If you have previously installed Keeper Gateway and wish to use the existing configuration, you can bypass the token entry by using:
The following other options may be used:
Installation Log File: To generate a log file during the installation process, use the following option and specify the desired log file path:
If you prefer to run the Keeper Gateway under a specific Windows service account, use the following options to specify the account details:
Replace <ACCOUNT USERNAME>
and <ACCOUNT PASSWORD>
with the credentials of the service account you intend to use.
To enable the Auto Updater feature, allowing Keeper Gateway to automatically check for and apply updates, use the following option:
To uninstall the service:
Uninstall Keeper Gateway from "Add and remove programs"
If desired, delete the private configuration .json file
Creating a one-time access token for installing the Keeper Gateway
In order to successfully install and setup up the Keeper Gateway, you need the Keeper Gateway's One Time Access Token. In order to generate this token, you will need to:
Prior to working with this guide, make sure that:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
Follow these steps to create a KSM Application:
In the Keeper Web Vault or Desktop App user interface, create a shared folder. This shared folder will contain the PAM records you will create as you are working through the use-case guides.
Navigate to the "Secret Managers" tab on the left and click on "Create Application" to create a KSM application
In the prompted window:
Enter the name of your KSM application
Choose the shared folder you have created in Step 1
Set the Record Permissions for Application to "Can Edit"
Click on "Generate Access Token" and then click on "OK"
You can safely ignore the first One-Time Access Token generated for the newly created KSM application. When creating a Keeper Gateway device, a different One-Time Access Token will be created.
For more information on KSM, visit:
Follow these steps to generate the Keeper Gateway's One Time Access Token:
After creating your KSM Application, select it, and navigate to the Gateways tab
In the Gateways tab, click on Provision Gateway
In the prompted screen do the following:
Enter your desired Gateway Name
Choose the operating system where this Gateway will be installed
After clicking Next, you will get a confirmation screen as shown in the screenshots below.
For Gateways that will be installed on windows, just the One-Time Access Token is shown:
For Gateways installed on Mac or Linux, you have the option of choosing one of the following:
New Gateway: This gives you the installation command with the One-Time Access Token
Existing Gateway: This gives you just the installation command
Important: Make sure to store this One Time Access Token for your records as this code is necessary to complete your Keeper Gateway Installation
Advanced Keeper Gateway Configurations
This section will cover additional configurations users can make to modify the Keeper Gateway's default behavior.
Prior to proceeding with this guide, Keeper highly recommends you go over and setup one of the many supported Rotation use cases with Keeper Rotation:
The following are supported configurations for the Keeper Gateway:
Instructions for installing and configuring the Auto Updater for the Keeper Gateway.
Auto Updater is supported only on Versions 1.4.0 or later of the Keeper Gateway
This document contains information on how to install & configure the Auto Updater for your Keeper Gateway installation. The Auto Updater makes periodic checks to update your Keeper Gateway to the latest version.
By default, the Auto Updater is disabled to prevent unexpected updates.
However, Keeper recommends enabling the Auto Updater to ensure you receive the most recent security and functionality enhancements. The Auto Updater verifies all Keeper Gateway downloads by checking the GPG signature of hash value, which are then utilized to checksum each file.
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Execute the following command to download and run the installer. The --autoupdate
parameter is necessary for installing the auto updater in addition to Keeper Gateway.
Click the following link for details on other Linux installation options:
Install Auto Updater on existing installation by executing the following Keeper Gateway command:
Verify Installation (Optional)
Verify that the Auto Updater has been installed successfully by executing the following Keeper Gateway command:
Download the latest version of the Gateway installer which includes the Auto Updater from the official website.
Double-click the installer file to launch the installation wizard and follow the on-screen instructions. Click the following link for details on other Windows installation options:
During installation, check the box "Enable automatic updates". This setup option will create a new Task Scheduler task for auto updating the Gateway.
Install with existing Keeper Gateway
Open a command prompt as Administrator.
Install Auto Updater with the following Keeper Gateway command:
Verify Installation (Optional)
Open a command prompt as Administrator.
Verify that Auto Updater has been installed successfully by executing the following Keeper Gateway command:
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Check the Auto Updater status by executing the following Keeper Gateway command:
Open a command prompt as Administrator
Check the Auto Updater status by executing the following Keeper Gateway command:
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Check that Auto Updater is enabled using the steps in the Status section:
Edit the crontab that runs Auto Updater.
Here is an example of the default crontab entry that checks for updates every hour:
The first part 0 * * * *
is the crontab expression which will cause execution to occur every hour at 0 minutes.
The second part is the update command keeper-gateway-update
The option --trust
causes explicit trust of the Keeper Gateway GPG public key for verification of downloaded install files.
Configure the update frequency and other settings with the following steps:
Run taskschd.msc
to open Windows Task Scheduler.
In the left pane double-click on Task Scheduler Library -> Keeper -> Gateway -> AutoUpdate to show the Auto Updater Task.
In the upper middle pane double-click on the AutoUpdate Task with the name of the current version and click on the Triggers menu tab.
Click Edit...
to change when the Auto Updater checks for a new update to install. The default is to "Repeat task every 1 hour indefinitely" as shown below.
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Remove Auto Updater by executing the following Keeper Gateway command:
Remove Auto Updater with the following steps:
Open a command prompt as Administrator.
Remove Auto Updater with the following Keeper Gateway command:
To assist with diagnosing issues or monitoring the status of updates, the Gateway Auto Updater generates two types of logs. These logs are subject to rotation policies to avoid overuse of disk space.
Log Location
All log files for Linux are located in /var/log/keeper-gateway
Log Files
Update Logs:
Any logs generated during an update will be timestamped and stored as update_YYYY-MM-DD_HH-MM-SS.log
.
Last Update Check:
The file last-update-check.log
contains information regarding the most recent check for updates.
The log files for the Gateway Auto Updater are located in \ProgramData\KeeperGateway\install
Log Files
Update Logs:
Any logs generated during an update will be timestamped and stored as YYYY-MM-DD_HH-MM-SS.log
Last Update Check:
The file last-update-check.log
contains information regarding the most recent check for updates.
Password Rotation in the Azure Environment
In this section, you will learn how to rotate user credentials within the Azure network environment across various target systems. Rotation works on the devices configured and attached to the Azure Active Directory (Azure AD) which can also be your default directory.
Keeper can rotate the password for Azure AD users, service accounts, local admin users, local users, managed services, databases and more.
Configurations for the Azure Active Directory are defined in the PAM Configuration section of Keeper Secrets Manager.
Configurations for the Azure AD joined devices are defined in the PAM Directory, PAM Machine, and PAM Database record types. The following table shows the supported Azure AD joined devices with Keeper Rotation and their corresponding PAM Record Type:
Configurations for Azure Directory User's credentials are defined in the PAM User records.
Prior to rotating user credentials within your Azure environment, you need to make sure you have the following information and configurations in place:
All Azure AD joined devices that you want to use with Rotation need to be created and configured within your Azure Active Directory
To successfully configure and setup Rotation within your Azure Network, the following values are needed for your PAM Configuration:
Make sure all the Azure services or Azure AD joined devices you plan on using for rotation have access to the Azure Active Directory. For more information, visit this page
Create a custom role to allow application to access/perform actions on various Azure resources. For more information on custom role setup, visit this page
At a high level, the following steps are needed to successfully rotate passwords on your Azure network:
Create Shared Folders to hold the PAM records involved in rotation
Create PAM Machine, PAM Database and PAM Directory records that contain credentials with the necessary permissions to rotate and update the user's credentials
Create PAM User records that contain the user's information
Create a Secrets Manager Application and assign it to the shared folders that hold the PAM records
Install a Keeper Gateway and add it to the Secrets Manager application
Create a PAM Configuration with the Azure environment setting
Configure Rotation settings on the PAM User records and/or PAM Machine, PAM Database, PAM Directory records
The next section of the documentation covers the Azure Environment Setup.
The following pages cover these steps in more details on how to successfully rotate passwords in different scenarios on the Azure network:
Step by step guides for performing rotation on any target system
The setup and configuration of Keeper Rotation is defined by the use case. Keeper supports any cloud or on-prem environment.
Looking for a specific use case we don't cover? Please email feedback@keepersecurity.com.
Azure AD Joined Device | Corresponding PAM Record Type |
---|---|
Field | Description |
---|---|
Azure AD Domain Services
PAM Directory
Virtual Machines
PAM Machine
Managed Databases
PAM Database
Client ID
The application/client id (UUID) of the Azure application
Client Secret
The client credentials secret for the Azure application
Subscription ID
The UUID of your subscription to use Azure services (i.e. Pay-As-You-GO)
Tenant ID
The UUID of the Azure Active Directory
Rotating Admin/Regular Azure MariaDB Database Users with Keeper
In this guide, you'll learn how to rotate passwords for Azure MariaDB Users and Admin accounts on your Azure environment using Keeper Rotation. Azure MariaDB is an Azure managed resource where the MariaDB Admin Credentials are defined in the PAM Database record type and the configurations of the MariaDB Users are defined in the PAM User record type.
For Azure Managed MariaDB database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the Azure network, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your Azure MariaDB Server Database
Your Azure environment is configured per our document
The PAM Database record contains the admin credentials and necessary configurations to connect to the MariaDB server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure MariaDB Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
If you already have a PAM Configuration for your Azure environment, you can simply add the additional Resource Credentials required for rotating machine users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Azure AD Admin and User passwords with Keeper
In this guide, you will learn how to rotate passwords for Azure AD users. In Keeper, the PAM Configuration contains all of the information needed to rotate passwords. The record containing the Azure AD user accounts to be rotated are stored in the PAM User record.
For a high-level overview on the rotation process in the Azure network, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
Your Azure environment is configured per our documentation
The Keeper Gateway uses Azure APIs to rotate the credentials defined in the PAM User records.
Note: You can skip this step if you already have a PAM Configuration set up for Azure.
Prior to setting up the PAM Configuration, make sure that:
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is provisioned in the Keeper Secrets Manager application you created.
We recommend installing the Keeper Gateway service in a machine within the Azure environment in order to rotate other types of targets.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields that needs to be filled on the PAM Configuration Record with your information:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation uses the Azure Graph API to rotate the PAM User records in your Azure environment. The PAM User records need to be in a shared folder that is shared to the KSM application created in the pre-requisites.
The following table lists all the required fields that needs to be filled on the PAM User record with your information:
There should only be one PAM User record for each Azure AD user. Having multiple PAM User records with the same user/login will cause conflicts.
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should select the PAM Configuration setup previously.
The "Resource Credential" field should be empty / not selected.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with "Can Edit" rights to a PAM User record has the ability to set up rotation for that record.
Rotating Admin/Regular Azure SQL Database Users with Keeper
In this guide, you'll learn how to rotate passwords for Azure SQL Database Users and Admin accounts on your Azure environment using Keeper Rotation. Azure SQL is an Azure managed resource where the SQL Admin Credentials are defined in the PAM Database record type and the configurations of the SQL Users are defined in the PAM User record type.
This guide assumes the following tasks have already taken place:
The PAM Database record contains the admin credentials and necessary configurations to connect to the SQL Server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure SQL Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
If you already have a PAM Configuration for your Azure environment, you can simply add the additional Resource Credentials required for rotating machine users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating local and remote user accounts on Azure Virtual Machines with Keeper
This guide assumes the following tasks have already taken place:
PowerShell is available on all Windows machines and bash on all Linux machines
Keeper can rotate any local user account on either the Gateway machine or any other machine on the network. A PAM Machine record should be created for every machine. This PAM Machine record should contain an administrative credential that has the rights to change passwords for users on the machine.
Once a PAM Machine record is created for every machine, a PAM User record needs to be created for each user account that will be rotated. The PAM Machine record can also be rotated.
The following table lists all the required fields that needs to be filled on the PAM Machine records.
If you already have a PAM Configuration for your Azure environment, you can simply add the additional Resource Credentials required for rotating machine users to the existing PAM Configuration.
Make sure the following items are completed first:
PAM Machine records have been created for each target machine
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields that needs to be filled on the PAM Configuration.
If a Gateway has already been deployed to an existing PAM Configuration, you can simply adjust the configuration to include additional Administrative Resource Credentials as needed.
In the example below, there are 5 local admin PAM Machine records, one for each VM in Azure. Each of the accounts is used to rotate credentials for local users in each respective machine.
Keeper Rotation will use the credentials in the PAM Machine record to rotate the credentials of accounts referenced by the PAM User records.
The following table lists all the required fields that need to be filled on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine admin credential specific to this user's machine.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
Optionally, the PAM Machine credential can also be rotated. Select the PAM Machine record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine which can rotate the credential.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
For Azure Managed SQL database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the Azure network, visit this .
Keeper Secrets Manager is enabled for your and your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
A Keeper Rotation is already installed, running, and is able to communicate with your Azure SQL Server Database
If the Gateway is installed on a Linux or macOS server, install the
Your Azure environment is per our document
Field | Description |
---|
Field | Description |
---|
For more details on all the configurable fields in the PAM Network Configuration record, visit this .
Field | Description |
---|
In this guide, you'll learn how to rotate Azure Virtual Machine local and remote user accounts within the Azure environment using Keeper Rotation. For a high-level overview on the rotation process in the Azure network, visit this .
Keeper Secrets Manager is enabled for your and your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created.
Your Azure environment is
A Keeper Rotation is already installed, running, and is able to or with your target Azure Virtual Machine(s).
Field | Description |
---|
A Keeper Secrets Manager has been created
A Keeper Rotation is already installed, running, and is provisioned in the Keeper Secrets Manager application you created.
Field | Description |
---|
For more details on all the configurable fields in the PAM Network Configuration record, visit this .
Field | Description |
---|
Title
Keeper record title Ex: Azure MariaDB Admin
Hostname or IP Address
The Database Server name i.e testdb-mariadb.mariadb.database.azure.com
Port
For default ports, see port mapping
Ex: mariadb=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation. If the admin in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Admin account password
Database ID
Name of the Azure Database Server i.e. testdb-mariadb
Database Type
mariadb
or mariadb-flexible
Provider Group
Azure Resource group name
Provider Region
Azure Resource region i.e. East US
Title
Configuration name, example: Azure DB Configuration
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure MariaDB database from the pre-requisites
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the directory user account's credentials
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-Prod
Client ID
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services.
Tenant ID
The UUID of the Azure Active Directory
Title
Keeper record title i.e. Azure MariaDB User1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Account password is optional, rotation will set one if blank
Title
Configuration name, example: Azure AD Configuration
Environment
Select: Azure
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Active Directory server from the pre-requisites
Application Folder
Select the Shared folder that will contain the PAM User records
Admin Credentials Record
Not required
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-1
Client ID
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application. It’s random looking text.
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services.
Tenant ID
The UUID of the Azure Active Directory
Title
Keeper record title i.e. Azure User1
Login
Case sensitive username of the account being rotated. The username has to be in one of the following formats:
domain\username
username@domain
Password
Providing a password is optional. Performing a rotation will set one if this field is left blank.
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure SQL database from the pre-requisites |
Application Folder | Select the Shared folder that contains the PAM Database record in Step 1 |
Admin Credentials Record | Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the directory user account's credentials |
Azure ID | A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: |
Client ID | The unique Application (client) ID assigned to your app by Azure AD when the application was registered |
Client Secret | The client credentials secret for the Azure application |
Subscription ID | The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services. |
Tenant ID | The UUID of the Azure Active Directory |
Title | Keeper record title i.e. |
Login | Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as |
Password | Account password is optional, rotation will set one if blank |
Connect Database | Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to |
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Active Directory server from the pre-requisites |
Application Folder | Select the Shared folder that contains the PAM Machine record(s) |
Resource Credential(s) | Select the PAM Machine record containing the admin credentials with sufficient permissions to rotate local user passwords. Important: If there are multiple machines being rotated, each PAM Machine record needs to be added as a Resource Credential. |
Azure ID | A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: |
Client ID | The unique Application (client) ID assigned to your app by Azure AD when the application was registered. |
Client Secret | The client credentials secret for the Azure application. |
Subscription ID | The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services. |
Tenant ID | The UUID of the Azure Active Directory |
Title | Keeper record title i.e. |
Login | Case sensitive username of the account being rotated. The username has to be in one of the following formats:
|
Password | Account password is optional, rotation will set one if blank |
Title | Keeper record title Ex: |
Hostname or IP Address | The Database Server name i.e |
Port |
Use SSL | Check to perform SSL verification before connecting, if your database has SSL configured |
Login | Admin account username that will perform rotation. If the admin in the DB user table is in a Host other than %, add the Host value to the user name as |
Password | Admin account password |
Connect Database | Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to |
Database ID | Name of the Azure Database Server i.e. |
Database Type |
|
Provider Group | Azure Resource group name |
Provider Region | Azure Resource region i.e. |
Title | Name of the Record e.g. |
Hostname or IP Address | Machine hostname or IP as accessed by the Gateway, e.g. 10.0.1.4 |
Port | Typically 5985 or 5986 for WinRM, 22 for SSH |
Login | Username of the Administrator account |
Password | Required for WinRM
Optional for SSH if your setup requires a password, otherwise can use PEM key.
Note: The following chars are restricted: |
Private PEM Key | Required for SSH if not using a password |
Operating System | The VM Operating System: |
SSL Verification |
How to configure your AWS environment for Keeper Rotation
Resources in your AWS environment can be rotated either using EC2 instance roles or using a specified Access Key ID / Secret Access Key configured in the PAM Configuration record.
The role policy must be configured appropriately to enable access to the target AWS resources:
EC2 Role Policy (Preferred)
The following diagram shows the AWS environment hierarchy:
If you are running the Keeper Gateway on an EC2 instance in AWS, this method of configuration using EC2 IAM instance role policy is preferred.
To rotate credentials of AWS Managed Resources from an EC2 instance, a role with the appropriate policy settings can be configured and attached to the EC2 instance instead of using a static Access Key ID / Secret Access Key.
Below is a basic role policy:
To be configured for rotation, the following inline policy can be created with the following JSON:
The steps to create this in the AWS console are below:
Create role with JSON specified above, or click on IAM > Roles > Create Role > Select "AWS Service" with "EC2 use case".
Attach the above policy JSON to the role
In the EC2 instance view, go to Actions > Security > Modify IAM Role > Select this new role.
The above JSON can be edited to remove resources not used for rotation. For example, if no RDS resource is used, you can remove rds:DescribeDBInstances
and rds:ModifyDBInstance.
However iam:SimulatePrincipalPolicy
is required.
Using EC2 instance role policy is preferred. Alternatively, the AWS Access Key ID and Secret Access Key can be directly set in the PAM Configuration. The IAM Admin account needs to be created with the appropriate policy settings configured to access the target resource in AWS.
An inline policy can be created for a user with the following JSON:
The above JSON can be edited to remove resources not used for rotation. For example, if no RDS resource is used, you can remove rds:DescribeDBInstances
and rds:ModifyDBInstance
However iam:SimulatePrincipalPolicy
is required.
The steps to create the access keys is below:
Create a new IAM user or select an existing user
Attach the inline policy specified above to the user
Open the IAM user > Security credentials > Create access key
Select "Application running outside AWS"
Save the provided Access Key ID / Secret Access Key into the PAM Configuration
Rotating Admin/Regular Azure MySQL Single or Flexible Database Users with Keeper
In this guide, you'll learn how to rotate passwords for Azure MySQL Database Users and Admin accounts on your Azure environment using Keeper Rotation. Azure MySQL is an Azure managed resource where the MySQL Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
For Azure Managed MySQL database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the Azure network, visit this page.
In 2024, Azure is going to sunset the non-flexible MySQL managed services. Most likely the term flexible will be removed. See: What's happening to Azure Database for MySQL Single Server?
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your Azure MySQL Server Database
Your Azure environment is configured per our document
The PAM Database record contains the admin credentials and necessary configurations to connect to the MySQL Server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure MySQL Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
If you already have a PAM Configuration for your Azure environment, you can simply add the additional Resource Credentials required for rotating machine users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Admin/Regular Azure PostgreSQL Single or Flexible Database Users with Keeper
In this guide, you'll learn how to rotate passwords for Azure PostgreSQL Database Users and Admin accounts on your Azure environment using Keeper Rotation. Azure PostgreSQL is an Azure managed resource where the PostgreSQL Admin Credentials are defined in the PAM Database record type and the configurations of the PostgreSQL Users are defined in the PAM User record type.
For Azure Managed PostgreSQL database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the Azure network, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your Azure PostgreSQL Server Database
Your Azure environment is configured per our document
The PAM Database record contains the admin credentials and necessary configurations to connect to the PostgreSQL Server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure PostgreSQL Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
If you already have a PAM Configuration for your Azure environment, you can simply add the additional Resource Credentials required for rotating machine users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Password Rotation in the AWS Environment
In this section, you will learn how to rotate user credentials within the AWS Cloud environment across various target systems and services.
Configurations for your AWS environment are defined in the PAM Configuration section of Keeper Secrets Manager. Keeper will use the inherited EC2 instance role where the Gateway is installed to authenticate with the AWS system and perform rotation. If instance roles are not defined, the AWS Access Key ID and Secret Key can be stored in the PAM Configuration record to authenticate and perform rotations.
PAM Configuration records are encrypted in the vault just like other Keeper records
Configurations for managed resources like EC2, RDS, and Directory Services are defined in the PAM Machine, PAM Database, and PAM Directory record types. The following table shows the supported AWS managed resources with Keeper Rotation and their corresponding PAM Record Type:
Configurations for directory users or IAM users are defined in the PAM User record type.
Prior to rotating user credentials within your AWS environment, you need to make sure you have the following information and configurations in place:
To configure and setup Rotation within your AWS environment, the following values are needed in the PAM Configuration:
The Keeper Gateway will always first attempt to use the EC2 instance role to authenticate and perform the rotation. If this fails or is not available on the machine, Keeper will use the Access Key ID and Secret Access Key stored in the PAM Configuration.
Visit the following section for more details on setting up your environment in AWS:
At a high level, the following steps are needed to successfully rotate passwords on your AWS network:
Create Shared Folders to hold the PAM records involved in rotation
Create PAM Machine, PAM Database and PAM Directory records that contain credentials with the necessary permissions to rotate and update the user's credentials
Create PAM User records that contain the user's information
Create a Secrets Manager Application and assign it to the shared folders that hold the PAM records
Install a Keeper Gateway and add it to the Secrets Manager application
Create a PAM Configuration with the AWS environment setting
Configure Rotation settings on the PAM User records and/or PAM Machine, PAM Database, PAM Directory records
The following pages cover these steps in more details on how to successfully rotate passwords in different scenarios on the Azure network:
For default ports, see
Ex: 1433
For WinRM, if selected, will use SSL mode port 5986. Ignored for SSH. See this for troubleshooting tips
Managed User Type | IAM Policy |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
AWS Managed Resource | Corresponding Record Type |
---|
To successfully rotate IAM User accounts, an IAM Admin account needs to be created. An IAM Admin account is an IAM User account with the appropriate policy settings configured to access the target resource. For more information on the policy settings, visit this .
To successfully rotate credentials of AWS Managed Resources attached to an EC2 instance, a role with the appropriate policy settings need to be configured and attached to the EC2 instance. For more information on the policy settings, visit this .
Field | Description |
---|
Rotation uses local credentials and no specific AWS permissions are needed.
Rotation uses AWS APIs for PAM Database records and requires: iam:GetUser iam:SimulatePrincipalPolicy rds:ModifyDBInstance rds:DescribeDBInstances
For managing PAM Database or PAM User Records via SQL no AWS permissions are needed.
Rotation uses AWS APIs for PAM Directory records and requires:
iam:SimulatePrincipalPolicy ds:DescribeDirectories ds:ResetUserPassword ds:DescribeLDAPSSettings ds:DescribeDomainControllers
Rotation uses AWS APIs for PAM User records and requires:
iam:SimulatePrincipalPolicy iam:UpdateLoginProfile iam:GetUser
Title
Keeper record title Ex: Azure MySQL Admin
Hostname or IP Address
The Database Server name i.e testdb-sql.mysql.database.azure.com
Port
For default ports, see port mapping
Ex: mysql=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation. If the Admin account in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Admin account password
Database ID
Name of the Azure Database Server i.e. testdb-sql
Database Type
mysql
or mysql-flexible
Provider Group
Azure Resource group name
Provider Region
Azure Resource region i.e. East US
Title
Configuration name, example: Azure DB Configuration
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure MySQL database from the pre-requisites
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the directory user account's credentials
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-Prod
Client ID
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services
Tenant ID
The UUID of the Azure Active Directory
Title
Keeper record title i.e. Azure DB User1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Account password is optional, rotation will set one if blank
Title
Keeper record title Ex: Azure PostgreSQL Admin
Hostname or IP Address
The Database Server name i.e testdb-psql.postgresql.database.azure.com
Port
For default ports, see port mapping
i.e. 5432
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation. If the Admin account in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Admin account password
Connect Database
Optional database that will be used when connecting to the database server.
For example, PostgreSQL requires a database and so this will default to template1
.
Database ID
Name of the Azure Database Server i.e. testdb-psql
Database Type
postgresql
or postgresql-flexible
Provider Group
Azure Resource group name
Provider Region
Azure Resource region i.e. East US
Title
Configuration name, example: Azure DB Configuration
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure PostgreSQL database from the pre-requisites
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the directory user account's credentials
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-Prod
Client ID
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services.
Tenant ID
The UUID of the Azure Active Directory
Title
Keeper record title i.e. Azure PostgreSQL User1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server. For example: PostgreSQL requires a database and so this will default to template1
EC2 | PAM Machine |
RDS | PAM Database |
Directory Service | PAM Directory |
Access Key ID | This is the Access Key ID from the desired Access Key found in the IAM User account
Set this field to |
Secret Access Key | This is the Secret Access Key from the desired Access Key found in the IAM User account
Set this field to |
Rotating AWS EC2 Virtual Machine accounts with Keeper
In this guide, you will learn how to rotate AWS EC2 Virtual Machine (VM) Accounts on your AWS Environment using Keeper Rotation. The EC2 VM is an AWS managed resource where the EC2 VM Admin Credentials are defined in the PAM Machine record type and the configurations of the EC2 VM Users are defined in the PAM User record type.
For EC2 VM Accounts, the AWS SDK is not used to rotate the password. Instead, the normal operating system commands are used to change the password. Keeper will connect to the target machine and send command-line commands to change the password. For a high-level overview on the rotation process in the AWS Environment, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created.
A Keeper Rotation gateway is already installed, running, and is able to communicate via SSH or WinRM with your target AWS Virtual Machine(s).
Your AWS environment is configured per our documentation
Keeper can rotate any local user account on either the Gateway machine or any other machine on the network. A PAM Machine record should be created for every machine. This PAM Machine record should contain an administrative credential that has the rights to change passwords for users on the machine.
Once a PAM Machine record is created for every machine, a PAM User record needs to be created for each local user account that will be rotated. The PAM Machine record itself can also be rotated.
Keeper will use the referenced admin credential to rotate the password or SSH key of AWS Virtual Machine users in your AWS environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of these user accounts.
If you are running a rotation on a PAM Machine record which also happens to be the same machine running the Keeper Gateway, Keeper will attempt to rotate the password or SSH key for the account using the keeper-gw user. Assuming that keeper-gw has sudoers privilege, it will be able to perform rotations on the local Gateway machine.
The following table lists all the required fields on the PAM Machine record:
This PAM Machine Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
The PAM Machine record can also be set up for rotation.
If you already have a PAM Configuration for your AWS environment, you can simply add the additional Resource Credentials required for rotating machine users to the existing PAM Configuration.
Make sure the following items are completed first:
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is provisioned in the Keeper Secrets Manager application you created.
PAM Machine records have been created for each target machine
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields that needs to be filled on the PAM Configuration.
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Add all of the Administrative Resource Credentials to your PAM Configuration required for performing rotation on the target machines. For example, if you are rotating 3 different PAM Machines, those needed to be added as Resource Credentials on the PAM Configuration.
Keeper will use the credentials in the PAM Machine record to rotate the PAM User records in your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields that need to be filled on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
If rotation of the PAM Machine credential is desired, select the PAM Machine record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
When rotating the private PEM Key credential on a target machine or user, Keeper will update the authorized_keys file on the machine with the new public key. The first time that a rotation occurs, the old public key is left intact in order to prevent system lockout. The second public key added to the file contains a comment that serves as an identifier for future rotations. For example:
If the first rotation is successful, you can optionally delete the old public key entry in the authorized_keys file. On subsequent rotations, Keeper will update the line which contains the "keeper-security-xxx" comment.
For Linux user rotations, password-encrypted PEM files are not currently supported.
Rotating AWS IAM account passwords with Keeper
In this guide, you will learn how to rotate passwords for AWS IAM users. In Keeper, the PAM Configuration contains all of the information needed to rotate passwords. The record containing the AWS IAM user accounts to be rotated are stored in the PAM User record.
This guide assumes the following tasks have already taken place:
The Keeper Gateway uses AWS APIs to rotate the credentials defined in the PAM User records.
In this folder, you’ll create records for the AWS IAM accounts that you’ll rotate. You will create a PAM User record for each user that will be rotated.
Keeper Rotation uses the AWS API to rotate the PAM User records in your AWS environment. The PAM User records need to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Note: You can skip this step if you already have a PAM configuration set up.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Select the PAM User record(s) from Step 2, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field is not needed
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
Note: The user must have AWS Console access and at minimum have a temporary password set in the AWS Console before the password can be rotated.
Rotating Admin/Regular AWS SQL Database Users with Keeper
In this guide, you'll learn how to rotate passwords for AWS MySQL Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for MySQL is an AWS managed resource where the MySQL Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
This guide assumes the following tasks have already taken place:
The PAM Database record contains the admin credentials and necessary configurations to connect to the MySQL RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the MySQL RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
If you already have a PAM Configuration for your AWS environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
If you are running a database directly on an EC2 instance in your AWS environment instead of using a managed service, refer to the documentation for rotating passwords.
For a high-level overview on the rotation process in the AWS cloud environment, visit .
Keeper Secrets Manager is enabled for your and your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
A Keeper Rotation is already installed and running
Your AWS environment is per our documentation
Field | Description |
---|
Field | Description |
---|
For more details on all the configurable fields in the PAM Network Configuration record, visit this .
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the AWS Environment, visit this .
Keeper Secrets Manager is enabled for your and your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
A Keeper Rotation is already installed, running, and is able to communicate with your AWS MySQL Database
Your AWS environment is per our documentation
Field | Description |
---|
Field | Description |
---|
For more details on all the configurable fields in the PAM Network Configuration record, visit this .
Field | Description |
---|
Title
Name of the Record i.e AWS Linux 1
Hostname or IP Address
Machine hostname or IP as accessed by the Gateway
Port
Typically 5985 or 5986 for WinRM, 22 for SSH.
Login
Username of the Admin account
Password
Required for WinRM
Optional for SSH if your admin user logs in with a password, otherwise the PEM key is utilized.
Note: The following chars are restricted: " '
Private PEM Key
Required for SSH if not using a password
Operating System
The VM Operating System, i.e Windows
or Linux
SSL Verification
For WinRM, if selected, will use SSL mode port 5986. Ignored for SSH.
Title
Configuration name, example: AWS VM Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Active Directory server from the prerequisites
Application Folder
Select the Shared folder that contains the PAM Machine record in Step 1
Admin Credentials Record
Select the PAM Machine record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the directory user account's credentials
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
Access Key ID
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Secret Access Key
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Title
Keeper record title i.e. AWS Machine1 ec2-user
Login
Case sensitive username of the user account being rotated, e.g. ec2-user
.
Password
This is only required if the user logs in with a password. If the password is left blank, performing a rotation will set one.
Private PEM Key
This is only required if you are planning to rotate the PEM key instead of rotating a password.
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application. |
Application Folder | Select the Shared folder from Step 1 that contains the PAM User record(s) which will be rotated. |
Admin Credentials Record | This is not required for IAM User rotations. It may be required for other use cases. |
AWS ID | A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: |
Access Key ID | Set this field to |
Access Secret Key | Set this field to |
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MySQL RDS Instance |
Application Folder | Select the Shared folder that contains the PAM Database record in Step 1 |
Admin Credentials Record | Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the credentials of regular database user accounts |
AWS ID | A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: |
Access Key ID | Set this field to |
Access Secret Key | Set this field to |
Title | Keeper record title i.e. |
Login | Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as |
Password | Account password is optional, rotation will set one if blank |
Title | Keeper record title i.e. |
Login |
Password | Providing a password is optional. Performing a rotation will set one if this field is left blank. |
Distinguished Name | This is the full ARN of the user identity, e.g: |
Title | Keeper record title Ex: |
Hostname or IP Address | The RDS Endpoint i.e. |
Port |
Use SSL | Check to perform SSL verification before connecting, if your database has SSL configured |
Login | Admin account username that will perform rotation |
Password | Admin account password |
Database ID | The AWS DB instance ID |
Database Type |
|
Provider Region | The region your Amazon RDS instance is using. i.e |
Password Rotation in the Local Network Environment
In this section, you will learn how to rotate user credentials within a Local Network environment across various target systems.
A local network is configured by setting the Local Network as your environment in the PAM Configuration Record. Using this Local Network setting will only allow rotation on the local machine and all interactions with the operating system are done via Bash or PowerShell.
At a high level, the following steps are needed to successfully rotate passwords on your local network:
Create Shared Folders to hold the PAM records involved in rotation
Create PAM Machine, PAM Database, PAM Directory records that contain credentials with the necessary permissions to rotate and update the user's credentials
Create PAM User records that contain the user's information
Create a Secrets Manager Application and assign it to the shared folders that hold the PAM records
Configure the Gateway and add it to the Secrets Manager application
Create a PAM Configuration
Configure Rotation settings on the PAM User records
The following pages cover these steps in more details on how to successfully rotate passwords in different scenarios on the local network:
Rotating Admin/Regular AWS SQL Server Database Users with Keeper
In this guide, you'll learn how to rotate passwords for AWS SQL Server Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for SQL Server is an AWS managed resource where the SQL Server Admin Credentials are defined in the PAM Database record type and the configurations of the SQL Server Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the AWS Environment, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your AWS SQL Server Database
If the Gateway is installed on a Linux or macOS server, install the Microsoft ODBC driver
Your AWS environment is configured per our documentation
The PAM Database record contains the admin credentials and necessary configurations to connect to the SQL Server RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the SQL Server RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
If you already have a PAM Configuration for your AWS environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Admin/Regular AWS PostgreSQL Database Users with Keeper
In this guide, you'll learn how to rotate passwords for AWS PostgreSQL Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for PostgreSQL is an AWS managed resource where the PostgreSQL Admin Credentials are defined in the PAM Database record type and the configurations of the PostgreSQL Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the AWS Environment, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your AWS PostgreSQL Database
Your AWS environment is configured per our documentation
The PAM Database record contains the admin credentials and necessary configurations to connect to the PostgreSQL RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the PostgreSQL RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
If you already have a PAM Configuration for your AWS environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Admin/Regular AWS Oracle Database Users with Keeper
In this guide, you'll learn how to rotate passwords for AWS Oracle Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for Oracle is an AWS managed resource where the Oracle Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the AWS Environment, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your AWS Oracle Database
Your AWS environment is configured per our documentation
The PAM Database record contains the admin credentials and necessary configurations to connect to the Oracle RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Oracle RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
If you already have a PAM Configuration for your AWS environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Admin/Regular AWS MariaDB Database Users with Keeper
In this guide, you'll learn how to rotate passwords for AWS MariaDB Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for MariaDB is an AWS managed resource where the MariaDB Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password. For a high-level overview on the rotation process in the AWS Environment, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your AWS MariaDB Database
Your AWS environment is configured per our documentation
The PAM Database record contains the admin credentials and necessary configurations to connect to the MariaDB RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the MariaDB RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
If you already have a PAM Configuration for your AWS environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Linux User Accounts on Local Network
This guide assumes the following tasks have already taken place:
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Machine Record.
The following table lists all the required fields that needs to be filled on the PAM Machine Record with your information:
This PAM Machine Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating Linux users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Machine record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Machine record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating active directory accounts remotely using LDAP
In this guide, you'll learn how to remotely rotate Active Directory accounts via LDAP using Keeper Rotation.
This guide assumes the following tasks have already taken place:
Keeper Rotation will use an admin credential to rotate other accounts in your environment. This account does not need to be a domain admin account, but needs to be able to successfully change passwords for other accounts.
The admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
Note: You can skip this step if you already have a PAM configuration setup.
A PAM Configuration associates a Keeper Gateway with credentials. If you don't have a PAM Configuration set up yet for this use case, create one. On the left menu of the Vault, select "Secrets Manager", then select the "PAM Configurations" tab and create a new configuration for Active Directory rotation.
Keeper Rotation will use the credentials in the "PAM Directory" record to rotate "PAM User" records in your environment.
The user credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites.
The following PowerShell command can be used to get the correct DN for the user: Get-ADUser -Identity bsmith -Properties DistinguishedName
Select the PAM User record, edit the record and open the "Password Rotation Settings".
Any user with Can Edit rights to a PAM User record has the ability to set up rotation for that record.
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the "PAM Directory" credential setup previously.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
An easy way to test if LDAP is properly configured is to run 'LDP.exe' and test the connection. If this connection succeeds, then Keeper Rotation should also succeed.
Case sensitive username of the account being rotated.
This is the last section of the : ...:user/TestUser
The RDS Port, for default ports see
i.e. 3306
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
In this guide, you'll learn how to rotate Linux user accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this .
Keeper Secrets Manager is enabled for your and your .
Keeper Rotation is enabled for your .
A Keeper Secrets Manager has been created.
A Keeper Rotation is already installed, running, and is able to communicate via to your Linux Machine(s)
Field | Description |
---|
Field | Description |
---|
Field | Description |
---|
Keeper Secrets Manager is enabled for your and your .
Keeper Rotation is enabled for your .
A Keeper Secrets Manager has been created.
A Keeper Rotation is already installed, running, and is able to communicate via LDAPs to your directory server.
Field | Description |
---|
Field | Description |
---|
Field | Description |
---|
Title
Keeper record title Ex: RDS SQL Server Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see port mapping
i.e. 1433
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Password
Admin account password
Connect Database
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master
.
Database ID
The AWS DB instance ID
Database Type
mssql
Provider Region
The region your Amazon RDS instance is using. i.e us-east-2
Title
Configuration name, example: AWS RDS Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your SQL Server RDS Instance
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the credentials of regular database user accounts
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
Access Key ID
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master
.
Title
Keeper record title Ex: AWS PostgreSQL Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see port mapping
i.e. 5432
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Password
Admin account password
Connect Database
Optional database that will be used when connecting to the database server.
For example, PostgreSQL requires a database and so this will default to template1
.
Database ID
The AWS DB instance ID
Database Type
postgresql
Provider Region
The region your Amazon RDS instance is using. i.e us-east-2
Title
Configuration name, example: AWS RDS Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your PostgreSQL RDS Instance
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the credentials of regular database user accounts
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
Access Key ID
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server. For example: PostgreSQL requires a database and so this will default to template1
Title
Keeper record title Ex: AWS Oracle Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see port mapping
i.e. 1521
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Password
Admin account password
Connect Database
Optional database that will be used when connecting to the database server.
Database ID
The AWS DB instance ID
Database Type
oracle
Provider Region
The region your Amazon RDS instance is using. i.e us-east-2
Title
Configuration name, example: AWS RDS Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Oracle RDS Instance
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the credentials of regular database user accounts
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
Access Key ID
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server. For example: PostgreSQL requires a database and so this will default to template1
Title
Keeper record title Ex: AWS MariaDB Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see port mapping
i.e. 3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Password
Admin account password
Database ID
The AWS DB instance ID
Database Type
mariadb
Provider Region
The region your Amazon RDS instance is using. i.e us-east-2
Title
Configuration name, example: AWS RDS Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MariaDB RDS Instance
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the credentials of regular database user accounts
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
Access Key ID
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Title | Name of the Record ex: "Local Linux Admin" |
Hostname or IP Address | Machine hostname or IP as accessed by the Gateway (internal) or "localhost" |
Port | 22 for SSH |
Login | Username of the Admin account |
Password | Depends on your SSH setup. Your SSH setup may require a password, otherwise optional.
Note: The following char are restricted: |
Private PEM Key | Required for SSH if not using a password |
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application and has SSH access to your Linux devices |
Application Folder | Select the Shared folder that contains the PAM Machine record in Step 1. |
Admin Credentials Record | Select the PAM Machine record created in Step 1. This is the record with the admin credentials and sufficient permissions to rotate credentials |
Record Type | PAM User |
Title | Keeper record title |
Login | Case sensitive username of the account being rotated. Example: |
Password | Account password is optional, rotation will set one if blank |
Record Type | PAM Directory |
Title | Keeper record title |
Hostname or IP Address | IP address, hostname or FQDN of the directory server. Examples: |
Port |
|
Use SSL | Must be enabled |
Login | Username of the account performing the LDAP rotation. Example: |
Password | Admin account password |
Domain Name | Domain name of the Active Directory. Example: |
Other fields | These should be left blank |
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that has access to your Active Directory server from the pre-requisites |
Application Folder | Select the Shared folder that contains the PAM Directory record above |
Admin Credentials Record | Select the PAM Directory record, this list is filtered to records in the application folder |
Add Resource Credential | Add any optional credentials to be attempted in addition to the primary credential |
Default Rotation Schedule | Optional |
Other fields | These should be left blank |
Record Type | PAM User |
Title | Keeper record title |
Login | Username of the account being rotated. Example: |
Password | Account password is optional, rotation will set one if blank |
Distinguished Name | The LDAP DN for the user |
Other fields | These should be left blank |
Rotating Local Network MySQL database accounts with Keeper Rotation
In this guide, you'll learn how to rotate Local MySQL Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role.
Keeper Rotation is enabled for your role.
A Keeper Secrets Manager application has been created.
A Keeper Rotation gateway is already installed, running, and is able to communicate to your MySQL database
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Database record.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Windows User Accounts on Local Network
In this guide, you'll learn how to rotate Windows user accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role.
Keeper Rotation is enabled for your role.
A Keeper Secrets Manager application has been created.
A Keeper Rotation gateway is already installed and showing online
Connection Method Choose one of the following methods to enable on your target Windows Machine(s):
WinRM: Enabled and running on port 5986.
Verification: Run winrm get winrm/config
to verify that WinRM is running.
OR
SSH: Enabled and running on port 22.
Verification: Run ssh [your-user]@[your-machine] -p 22
to verify that SSH is running.
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Machine Record.
The following table lists all the required fields that needs to be filled on the PAM Machine Record with your information:
This PAM Machine Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating Windows users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Machine record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Machine record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Local Mac User Accounts with Keeper Rotation
In this guide, you'll learn how to remotely rotate MacOS accounts via SSH using Keeper Rotation.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role.
Keeper Rotation is enabled for your role.
A Keeper Secrets Manager application has been created.
Keeper Rotation will use an admin credential to rotate other accounts in your environment. This account does not need to be joined to a domain, or a full admin account, but the account needs to be able to successfully change passwords for other accounts.
The admin credential needs to be in a shared folder that is shared to the KSM applicaiton created in the pre-requisites. Only the KSM applicaiton needs access to this privileged account, it does not need to be shared with any users.
Note: You can skip this step if you already have a PAM configuration setup.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab. Create a new configuration:
Keeper Rotation will use the credentials in the PAM Machine record to rotate the PAM User records in your environment.
The user credential needs to be in a shared folder that is shared to the KSM applicaiton created in the pre-requisites.
Select the PAM User record, edit the record and open the "Password Rotation Settings".
Any user with edit
rights to a PAM User record has the abilty to setup rotation for that record.
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the "PAM Machine" credential setup previously.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Rotating Local Network MariaDB database accounts with Keeper Rotation
In this guide, you'll learn how to rotate Local MariaDB User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role.
Keeper Rotation is enabled for your role.
A Keeper Secrets Manager application has been created.
A Keeper Rotation gateway is already installed, running, and is able to communicate to your MariaDB database
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Database Record.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Local Network PostgreSQL database accounts with Keeper Rotation
This guide assumes the following tasks have already taken place:
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Database Record.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Local Network MongoDB database accounts with Keeper Rotation
This guide assumes the following tasks have already taken place:
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Database Record.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Rotating Local Network Microsoft SQL Server database accounts with Keeper Rotation
This guide assumes the following tasks have already taken place:
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Database Record.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
In this guide, you'll learn how to rotate Local Postgres Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this .
Keeper Secrets Manager is enabled for your and your .
Keeper Rotation is enabled for your .
A Keeper Secrets Manager has been created.
A Keeper Rotation is already installed, running, and is able to communicate to your Postgres database
Field | Description |
---|
Field | Description |
---|
Field | Description |
---|
In this guide, you'll learn how to rotate Local MongoDB User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this .
Keeper Secrets Manager is enabled for your and your .
Keeper Rotation is enabled for your .
A Keeper Secrets Manager has been created.
A Keeper Rotation is already installed, running, and is able to communicate to your MongoDB Database
Field | Description |
---|
Field | Description |
---|
Field | Description |
---|
In this guide, you'll learn how to rotate Local MS SQL Server Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this .
Keeper Secrets Manager is enabled for your and your .
Keeper Rotation is enabled for your .
A Keeper Secrets Manager has been created.
A Keeper Rotation is already installed, running, and is able to communicate to your MySQL database
If the Gateway is installed on a Linux or macOS server, install the
Field | Description |
---|
Field | Description |
---|
Field | Description |
---|
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see port mapping
Ex: mysql=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
The admin account that will perform rotation
Password
Admin account password
Database Type
mysql
Title
Configuration name, example: MySQL LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MySQL database
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate credentials
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Title
Name of the Record ex: "Local Windows Admin"
Hostname or IP Address
Machine hostname or IP as accessed by the Gateway (internal) or "localhost"
Port
22 for SSH, 5985 (HTTP) or 5986 (HTTPS) for WinRM
Login
Username of the Admin account
Password
Required for WinRM
Optional for SSH if your setup requires a password, otherwise can use PEM key.
Note: The following chars are restricted: " '
Private PEM Key
Required for SSH if not using a password
Title
Configuration name, example: Windows LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has SSH access to your Windows devices
Application Folder
Select the Shared folder that contains the PAM Machine record in Step 1.
Admin Credentials Record
Select the PAM Machine record created in Step 1. This is the record with the admin credentials and sufficient permissions to rotate credentials
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Record Type
PAM Machine
Title
Keeper record title
Hostname or IP Address
IP address or hostname of the directory MacOS device. Use localhost if the gateway is installed on the device. Examples: 10.10.10.10
, MarysMacBook
, localhost
Port
SSH port, typically: 22
- SSH is required for rotation.
Use SSL
Must be enabled
Login
Username of the account performing the LDAP rotation. Example: rotationadmin
Password
Admin account password
Operating System
For Mac OS rotation, use: MacOS
Other fields
These should be left blank
Title
Configuration name, example: MAC Rotation
Environment
Select: Local Network
Gateway
Select the Gateway that has SSH access to your MacOS devices
Application Folder
Select the Shared folder that contains the PAM Machine record above.
Admin Credentials Record
Select the admin record record, this list is filtered to records in the application folder
Add Resource Credential
Add any optional credentials to be attempted in addition to the primary credential
Default Rotation Schedule
Optional
Other fields
These should be left blank
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Other fields
These should be left blank
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see port mapping
Ex: mariadb=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
The admin account that will perform rotation
Password
Admin account password
Database Type
maridb
or maridb-flexible
Title
Configuration name, example: MariaDB LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MariaDB database
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1
Admin Credentials Record
Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate credentials
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your PostgreSQL database |
Application Folder | Select the Shared folder that contains the PAM Database record in Step 1 |
Admin Credentials Record | Select the PAM Database record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate credentials |
Record Type | PAM User |
Title | Keeper record title |
Login | Case sensitive username of the db account being rotated. Example: |
Password | Account password is optional, rotation will set one if blank |
Connect Database | Optional database that will be used when connecting to the database server. For example: PostgreSQL requires a database and so this will default to template1. |
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MongoDB database |
Application Folder | Select the Shared folder that contains the PAM Database record in Step 1 |
Admin Credentials Record | Select the PAM Database record created in Step 1. This is the record with the admin credentials and sufficient permissions to rotate credentials |
Record Type | PAM User |
Title | Keeper record title |
Login | Case sensitive username of the db account being rotated. Example: |
Password | Account password is optional, rotation will set one if blank |
Connect Database | Optional database that will be used when connecting to the database server.
For example: MongoDB requires a database and so this will default to |
Title | Configuration name, example: |
Environment | Select: |
Gateway | Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MS SQL Server database |
Application Folder | Select the Shared folder that contains the PAM Database record in Step 1. |
Admin Credentials Record | Select the PAM Database record created in Step 1. This is the record with the admin credentials and sufficient permissions to rotate credentials |
Record Type | PAM User |
Title | Keeper record title |
Login | Case sensitive username of the db account being rotated. Example: |
Password | Account password is optional, rotation will set one if blank |
Connect Database | Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to |
Title | Keeper record title Ex: |
Hostname or IP Address | Server address - doesn't need to be publicly routable |
Port |
Use SSL | Check to perform SSL verification before connecting, if your database has SSL configured |
Login | The admin account that will perform rotation |
Password | Admin account password |
Connect Database | Optional database that will be used when connecting to the database server. For example, PostgreSQL requires a database and so this will default to template1. |
Database Type |
|
Title | Keeper record title Ex: |
Hostname or IP Address | Server address - doesn't need to be publicly routable |
Port |
Use SSL | Check to perform SSL verification before connecting, if your database has SSL configured |
Login | The admin account that will perform rotation |
Password | Admin account password |
Connect Database | Optional database that will be used when connecting to the database server.
For example, MongoDB requires a database and so this will default to |
Database Type |
|
Title | Keeper record title Ex: |
Hostname or IP Address | Server address - doesn't need to be publicly routable |
Port |
Use SSL | Check to perform SSL verification before connecting, if your database has SSL configured |
Login | The admin account that will perform rotation |
Password | Admin account password |
Connect Database | Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to |
Database Type |
|
Rotating Local Network Oracle database accounts with Keeper Rotation
In this guide, you'll learn how to rotate Local Oracle Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role.
Keeper Rotation is enabled for your role.
A Keeper Secrets Manager application has been created.
A Keeper Rotation gateway is already installed, running, and is able to communicate to your Oracle database
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Database Record.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Database record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Perform automatic script execution after password rotation
Post-rotation scripts are user-defined code snippets that execute after a credential is rotated. Scripts can be attached to PAM records, and will execute on either the remote machine or on the gateway.
For more information on attaching Post Rotation Scripts to PAM records, visit:
Post-Rotation scripts empower Keeper customers to manage and automate their IT administrative processes and tasks ranging from restarting a resource to notifying relevant parties on credential updates. Here are some of the use cases made possible with Keeper Post Rotation:
Updating Access Control Lists (ACLs)
After changes to a password or private key, it may be necessary to update the ACLs of files directories or servers as to not disrupt access. A post-execution script can automate this process and ensure that the procedures and/or users have the necessary permissions.
Revoking old credentials
After changes to a password or private key, old credentials may need to be revoked to prevent unauthorized access. A post-execution script can automate this process by revoking the old credentials and updating the user's access permissions.
Notifying relevant parties on updated credentials
Relevant parties such as IT administrators or security personnel should be notified on credentials changes. A post-execution script can automate this process by sending out notifications or alerts.
Auditing
Password or private key changes should be audited for compliance and security purposes. A post-execution script can automate this process by logging the change and any associated actions, such as ACL updates or notifications.
For code snippets and examples of these use cases, visit:
Upon successful rotation of credentials on a PAM record, Keeper executes the attached Post-Rotation scripts with parameters containing information on the involved records, credentials, and user.
For more information visit:
For default ports, see
Ex: postgresql=5432
For default ports, see
Ex: mongodb=27017
For default ports, see
Ex: mssql=1433
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see port mapping
Ex: oracle=1521
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
The admin account that will perform rotation
Password
Admin account password
Database Type
oracle
Title
Configuration name, example: Oracle LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Oracle database
Application Folder
Select the Shared folder that contains the PAM Database record in Step 1.
Admin Credentials Record
Select the PAM Database record created in Step 1. This is the record with the admin credentials and sufficient permissions to rotate credentials
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
By default, debug statements will not appear in the Gateway logs, even if you set your $DebugPreference
to Continue
on your PowerShell Post-Rotation Script.
In order to view debug statements in the logs, such as with Write-Debug
, you must run the Gateway service with the -d
start parameter and set your $DebugPreference
accordingly.
This example will allow you to rotate the credential on a Windows Scheduled Task running as a Service Account that has its password rotated via Keeper PAM.
To use these scripts, PowerShell 7 must be available on the target machine and should be set up and configured to enable remoting using PowerShell 7 using Enable-PSRemoting
.
The data in the record being rotated is made available to your script via a BASE64-encoded JSON string. This is passed into your script for consumption. When your script has finished execution, Clear-History is executed to ensure that the record data is not available for future PowerShell sessions.
The Remote Procedure Call (RPC) and Windows Management Instrumentation services should be enabled and running on the target server to run the scripts in the examples below.
To rotate the credential of a service account, the user (which in this case is the Gateway's user account) will need to be part of the Administrator's group on the target machine. This means the Gateway must run as a Service account that is assigned the appropriate level of privilege to achieve this and not run as the default SYSTEM user.
This example uses the commonly used tool jq
, for parsing the JSON data passed to the script containing the records data. This example assumes you have it installed and the jq
command is in PATH.
The data in the record being rotated is made available to your script via a BASE64-encoded JSON string. This is passed into your script for consumption.
To run this script, SSH public key authentication must be set up and enabled between the gateway server and the target server.
In the below example, you will hard code three values:
The name of the Scheduled Task for which you wish to rotate the credential.
The DNS resolvable name of the server the service is running on.
The username of the SSH user
Native SSH remoting is still not fully implemented into PowerShell and is only reliably possible in PowerShell 7. The gateway defaults to Windows PowerShell (v5) when running a .ps1
script. However, when attaching the script, you can also specify an alternative script command and point to the path of your PowerShell 7 executable.
Once the rotation is complete, we will log the service status to DEBUG.
As mentioned above, a BASE64 string will be piped into your script, which includes the username and new password (among other data), which you will use to rotate the Windows Service's credentials.
Using the below snippet, we can take the piped input and use certutil
to decode the BASE64 string. These will be saved to temporary files and cleaned up later, as is the custom in bat
scripts, as certutil
only accepts files as input.
jq
can be used on the resulting JSON file to get the values of user
and newPassword
.
The sc
command is used to update the desired Windows service using the values you just extracted. Replace the server and service names with your specific server and service details.
After updating the Windows Service, we will restart it, which will confirm that the credentials have been updated successfully.
Note: Server hostnames should start with a double backslash.
These examples will allow you to rotate the credential on an IIS Application Pool running as a Service Account that has its password rotated via Keeper PAM.
The data in the record being rotated is made available to your script via a BASE64-encoded JSON string. This is passed into your script for consumption. When your script has finished execution, Clear-History is executed to ensure that the record data is not available for future PowerShell sessions.
This example uses the IIS Management utility appcmd
and expects it on PATH. The executable is located in C:\Windows\System32\inetsrv
on any IIS-enabled server.
To update the 'Log On As' property on a Windows Scheduled Task, you will need a credential with the appropriate permissions, such as an Administrator account.
When attaching a PAM script to a record, you have the option to add a Resource Credential that is passed to the Gateway as part of the BASE64-encoded JSON data. The above credential will need to be attached as a Resource Credential.
As many Resource Credentials can be attached to a PAM script, knowing the UID
of the Resource Credential you have attached helps ensure your script uses the correct one to update the Service's 'Log On As' property.
Native ISS Management RPC commands are no longer available in modern versions of Windows Server and last appeared in Windows Server 2008. However, the IIS management utility, appcmd
, coupled with Invoke-WmiMethod
can achieve the same outcome.
Field | Description | Notes |
---|---|---|
Login
Username; exact context depends on associated resource
Required
Password
Password of the user
Can be rotated
Private PEM Key
PEM Key associated with user
Can be rotated
Distinguished Name
Distinguished name; used if associated with a directory
Required when the User is managed by a directory
Managed User
Flag for accounts that are managed by the AWS or Azure IAM systems
If this is checked, Keeper will skip rotation for this user. This is a planned feature to support account discovery and will not be automatically populated by Keeper at this time.
Complete list of the devices and accounts Keeper can access and rotate
After enabling Rotation, you will have access to new PAM record types:
PAM User Contains a login / password, private key, or both.
PAM Directory Information about your on-prem or cloud-based directory
PAM Database Self-hosted or managed cloud-based databases such as MySQL, SQL Server, etc
PAM Machine Windows, Linux, macOS machines on-prem or in the cloud
PAM Configuration Information on your network
On the Keeper Vault, these record types contain the relevant credential and/or configuration information for the Provider, Resource, or User
When Rotation is triggered, the credentials defined on the PAM User and/or PAM Directory, Database, Machine will be changed to new credentials. After rotation is complete, the updated credentials will be reflected on the remote Resource and on the Vault Record.
For detailed information on the how each of the PAM record types can be configured, visit the following:
Details regarding the PAM Configuration record
When creating a PAM Configuration record, you have the option of choosing one of the following environments:
Local Network
AWS
Azure
The following tables provides more details on each configurable fields in the PAM Configuration record regardless of the environment you choose:
The following tables provides more details on each configurable fields in the PAM Network Configuration record based on the environment you chose:
Field | Description | Notes |
---|---|---|
Field | Description | Notes |
---|---|---|
Field | Description | Notes |
---|---|---|
Field | Description | Notes |
---|---|---|
Title
Name of PAM configuration record
Ex: My Configuration
Gateway
The configured gateway
See docs for more info
Application Folder
The shared folder that contains the PAM records
Administrative Credential Record
The administrative credential record with sufficient permissions to rotate credentials
This is your PAM Machine, PAM Database or PAM Directory record
Default Rotation Schedule
Specify frequency of Rotation
Ex: Daily
Port Mapping
Type of Connection method
Ex: 3307=mysql
See docs for more info
Network ID
Unique ID for the network
This is for the user's reference
Ex: My Network
Network CIDR
Subnet of the IP address
Ex: 192.168.0.15/24
Refer to this for more info
AWS ID
A unique id for the instance of AWS
Required, This is for the user's reference
Ex: AWS-1
Access Key ID
From an IAM user account, the Access key ID from the desired Access key.
Optional
Secret Access Key
The secret key for the access key.
Optional, Masked
Region Names
AWS region names
Ex: us-east-2
Azure ID
A unique id for your instance of Azure
Required, This is for the user's reference
Ex: Azure-1
Client ID
The application/client id (UUID) of the Azure application
Required
Client Secret
The client credentials secret for the Azure application
Required
Subscription ID
The UUID of the subscription (i.e. Pay-As-You-GO).
Required
Tenant ID
The UUID of the Azure Active Directory
Required
Resource Groups
A list of resource groups to be checked. If left blank, all resource groups will be checked
How Keeper Rotation maintains Keeper's Zero-Knowledge Architecture
Building on Keeper's encryption model and the security of Keeper Secrets Manager, Rotation adds two major components, the Router and the Gateway.
The Gateway is the on-premise component of rotation, which communicates with the managed resources in your networks.
The Router is part of Keeper's infrastructure, but it facilitates communication between Keeper's APIs and your on-premise Gateway.
Details on the security of each can be found in the links below.
Steps to create a Keeper Secrets Manager application for rotation of passwords
Prior to working with Rotation, you need to create a KSM application. For more information on KSM, visit:
Navigate to the "Secret Managers" tab on the left and click on "Create Application" to create a KSM application
In the prompted window:
Enter the name of your KSM application
Choose the shared folder you have created in Step 1
Set the Record Permissions for Application to "Can Edit"
Click on "Generate Access Token" and then click on "OK"
You can safely ignore the first One-Time Access Token generated for the newly created KSM application. When creating a Keeper Gateway device, a different One-Time Access Token will be created.
Granting a service account the minimum permissions to rotate
When creating a PAM Directory Resource, it is recommended that you use a service account with the least required privileges to perform rotation.
The following steps show you how to enable a service account to rotate credentials using Active Directory's Delegation of Control feature.
Before starting, create a service account for password rotation whose credentials you will store in the Keeper resource record.
Launch Active Directory Users and Computers
In the directory tree, select a node for which password rotation should be allowed.
Right-click on the node, then click Delegate Control.
In the Delegation of Control Wizard, click 'Add'.
Locate your chosen service account, then click 'OK'.
Click 'Next' to advance to permission selection.
In 'Delegate the following common tasks', check the option for 'Reset user passwords and force password change at next logon', then click 'Next'.
Add the service account's login and password to the Resource Record for the AD instance.
In the Keeper Web Vault or Desktop App user interface, create a shared folder. This shared folder will contain the PAM records you will create as you are working through the guides.
Security and encryption model of the Keeper Router
Keeper Router ("Router") is a cloud service hosted in Keeper's Amazon AWS environment which facilitates communications between the Keeper backend API, end-user applications (Web Vault, Desktop App, etc.), and Keeper Gateways installed in the user’s environment. The Router is responsible for communications that perform resource discovery, password rotation, timed access, and privileged connection management.
In traditional or legacy privileged access products, the customer is responsible for installing on-prem software which is difficult to manage and configure in a cloud environment. In Keeper's model, a small service (called a Gateway) is installed into the customer's environment which establishes an outbound secure connection to the Keeper Router, enabling bi-directional communication to the Keeper cloud without any network configuration. Keeper Router makes cloud access to on-prem infrastructure easy and secure by utilizing WebSockets for the inbound requests.
With Keeper, WebSockets are established between the end-user device (e.g. Web Vault) and the Keeper Router using the user's current session token. The session token is verified by the Keeper Router to authenticate the session. All encrypted payloads sent to the Keeper Router are wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the end-user device and transferred to the server using ECIES encryption via the Router's public EC key.
When a user on their Web Vault or Desktop App triggers a password rotation, discovery job or remote connection, the message flow is the following:
Upon installation of the Gateway, it authenticates with the Keeper Cloud using a hashed One Time Access Token one time. The client signs the payload and registers a Client Device Public Key with the server on the first authentication. After the first authentication, subsequent requests are sent to the Keeper Router and signed with the Client Device Private Key.
The Gateway establishes an authenticated WebSocket connection using the Client Device Private Key and ECDSA signature.
The Vault sends a message to the Keeper Router with a command to execute (rotation, discovery, connection) and authenticates the command using the user's active session token.
The Vault only transmits command and control messages, for example: Rotate UID XXX
. No secret information is communicated between Vault and Router. The Router authenticates the command using the session token of the record's rotation configuration to validate the user's request.
The Router relays the command to the destination gateway through the existing WebSocket connection.
The Gateway retrieves secrets, admin credentials, record details and other private data by using Keeper Secrets Manager APIs. API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device. The Client Device decrypts the ciphertext response from the server with the Application Private Key, which decrypts the Record Keys and Shared Folder Keys. The Shared Folder Keys decrypt the Record Keys, and the Record Keys decrypt the individual Record secrets.
The Gateway uses Keeper Secrets Manager "update" commands to update the user's vault with any password or discovery job updates.
After a rotation or discovery job is complete, the Gateway informs the Router that the job is complete. ARAM event logs are triggered by the Router.
The Keeper Router architecture is Zero Knowledge, and Keeper's infrastructure never has the ability to access or decrypt any of the customer's stored vault data.
The Router consists of two logical deployments that work together - the Head and the Workers.
The Router is hosted in Keeper’s AWS cloud environment, isolated to each of the global regions (US, EU, CA, AUS, JP, and US Gov).
The Head is not exposed to the internet, and performs the following functions:
Synchronization of global state between Workers
Inter-worker communication
Scheduling of events (e.g. rotation, discovery and connection requests)
The Workers connect to the Head via WebSocket and also use REST API calls to retrieve information. The Workers perform the following functions:
Communication with Gateways
Communication with Keeper end-user applications
Communication with Keeper backend API
Communication with Head
Workers are scaled and load balanced in each Keeper environment. Access to the Keeper Router is established through a common URL pattern in each region:
US: https://connect.keepersecurity.com
EU: https://connect.keepersecurity.eu
AU: https://connect.keepersecurity.com.au
CA: https://connect.keepersecurity.ca
JP: https://connect.keepersecurity.jp
US GOV: https://connect.keepersecurity.us
The end-user device will always communicate through the same Router instance. When the end-user vault connects to the Router system, a communication exchange is performed to ensure that the vault is communicating to the desired gateway. Once the Gateway communication is established, a Cookie is stored locally on the user's browser which expires automatically in 7 days. This Cookie is only used to establish a sticky session with the target Router instance, and does not contain any secret information.
Each Gateway device is associated with a unique UID. The Gateway UID is stored within an encrypted “PAM Configuration” record in the user's vault. This way, the Keeper vault record knows which Gateway must be used to perform the requested rotation, discovery or connection features.
Keeper Password Rotation architecture diagram and data flow
The Keeper Rotation Module infrastructure diagram is below. Click the image to zoom in.
Keeper Admin schedules rotation or clicks ‘Rotate Now’ from the Vault interface
Keeper backend schedules the rotation using the Record UID
Keeper Gateway establishes an outbound WebSocket connection, receives the request to rotate, and pulls the needed records using Keeper Secrets Manager APIs
The Keeper Gateway generates new credentials and updates Keeper, and the target resource
Gateway runs custom post-execution scripts on the Gateway or target machines
Client devices securely retrieve the updated record using Keeper Secrets Manager
Vault end-users receive the latest rotated information on the Keeper Vault user interface
Keeper's Advanced Reporting & Alerts module logs all events and triggers alerts
The Keeper Gateway is a lightweight service which is installed into the customer's environment and communicates outbound to Keeper services. The Gateway performs the rotation, discovery and connections to assets on the network. The Gateway receives commands from the Keeper Router, then uses Keeper Secrets Manager APIs to authenticate, communicate and decrypt data from the Keeper cloud.
Keeper hosted infrastructure that manages connections between Keeper and Rotation Gateways. The Cloud Router provides real-time messaging and communication between the Keeper Vault, customer gateway and Keeper backend services.
Keeper's Backend API is the endpoint which all Keeper client applications communicate with. Client applications encrypt data locally and transmit encrypted ciphertext to the API in a Protocol Buffer format.
Keeper hosted infrastructure that manages timing and logistics around scheduled rotation of credentials across the target infrastructure.
The Management console used to set and enforce policies across all Keeper component.
The end-user interface for managing the vault and rotating passwords.
Security and encryption model of the Keeper Gateway service
The Keeper Gateway is a service that is installed on-premise in order to execute rotation, discovery and connection tasks. The Keeper Gateway communicates outbound to the Keeper Router using WebSockets and Keeper Secrets Manager zero-knowledge protocols.
The Keeper Gateway authenticates first to the Keeper Router using the One Time Access Token provided upon installation of the Gateway service on the target machine. After the first authentication, subsequent API calls to the Router authenticate using a Client Device Identifier (which is the HMAC_SHA512 hash of the One Time Access Token).
For accessing and decrypting vault records, the Keeper Gateway uses standard Keeper Secrets Manager APIs which perform client-side encryption and decryption of data. The security model of Keeper Secrets Manager ensures least privilege and zero knowledge by allocating only specific folders and records that can be decrypted by the service. API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device.
Like any other Secrets Manager device, access can also be restricted based on IP address in addition to the encryption and signing process.
Rotations can be performed on-demand or on a schedule. When an on-demand rotation is triggered by a user in the Web Vault or Desktop App, the Keeper Router uses the active WebSocket connection to the appropriate Gateway to push instructions to run the rotation. The messages do not contain any secret information or encrypted ciphertext. All messages sent through the WebSocket contain only the command type (e.g. "rotate") and the affected Record UID ("UID") which is not a secret value.
For scheduled rotations, the same mechanism is used. Rotation schedules are tracked in the Router, and at the appropriate intervals rotation instructions are pushed to the Gateway. When the Gateway receives a rotation task, it uses the local KSM configuration to fetch the secrets associated with the provided Record UIDs and decrypts the record information locally. These secrets are in turn used to perform the rotation, discovery or connection.
When the Gateway service is installed, the local KSM configuration is protected by permissions on the local file system. By default, the configuration will be stored in the home directory (.keeper
folder) of the user that installed the Gateway.
If Gateway is started as a user:
Config file: ~/.keeper/gateway-config.json
Logs folder: ~/.keeper/log
If Gateway is running as a service:
User: keeper-gateway-service
Config file: /etc/keeper-gateway/gateway-config.json
Logs folder: /var/log/keeper-gateway
If Gateway is started via Command Line
Logs location: C:\Users\[USER NAME]\.keeper\logs\
Config File location: C:\Users\[USER NAME]\.keeper\gateway-config.json
If Gateway is started as a Windows Service
Logs location: C:\ProgramData\KeeperGateway\
Config File location: C:\ProgramData\KeeperGatewayPrivate\
Note: This folder can only be accessed by the user who installed the Gateway Service.
Access to the KSM configuration file allows a user to retrieve any associated secrets from Keeper. To prevent unauthorized access, this configuration file is only readable by the installing user and administrative accounts. On a Windows server, the Windows System account is used to run the service by default, and also has access to the KSM configuration.
Caching is used for discovery but not for rotation. Every time a secret is rotated, the Gateway retrieves associated records in real time using the Keeper Secrets Manager APIs.
The Gateway includes a virtual command shell. When the Gateway is run as a stand-alone application, the user is dropped into the shell. When the Gateway is run as a service, the shell is not accessible.
An SSH service is bundled with the Gateway to provide advanced debug access to the shell. The SSH service is not running by default, and there is no way to access the shell while it is disabled. When the Gateway service is started, an optional argument can be supplied to enable the SSH service component. When the SSH service is enabled, by default there are no accounts that can connect to it. A system administrator must create a key pair with an account to utilize SSH.
The Gateway shell does not provide commands to interact directly with secrets.
Keeper Commander can also be used to access the Gateway for troubleshooting. This leverages the connection between the Gateway and the Router, and the associated security mechanisms. For example, Commander can send a command to the Router to retrieve a list of running tasks on the Gateway. These commands can be used with any Gateway in the same enterprise as the Commander user.
Any secrets that are retrieved during rotation are automatically scrubbed from log messages produced by the Gateway. This includes accidental logging, such as stack traces.
Keeper Gateway supports the ability to execute admin-generated scripts in PowerShell and Bash for performing customized behaviors after a successful rotation has taken place. The script is provided to the Gateway through a file attachment in the corresponding Keeper record. Post-Rotation scripts are categorized differently from general file attachments, and only the record owner has the ability to attach post-rotation scripts on the corresponding record.
The script is decrypted by the Gateway and then executed on the Gateway. Connections to secondary devices, for the purpose of restarting services, etc., must be orchestrated within the post-rotation script.
Obviously, the script which is uploaded to the Keeper record and executed on the gateway must be protected from malicious abuse. Keeper Administrators need to ensure that least privilege is assigned to the Keeper record.
When Post-Rotation scripts are run, stdout and stderr output from the script are written to disk in logs. Secrets are also automatically scrubbed from this output. Record UIDs can be logged in this way for diagnostic purposes. The Post-Rotation script can be written with any arbitrary code, however the Keeper Gateway provides the script with minimal information required to perform standard use cases through the command-line parameters. This includes the following parameters:
PAM Rotation Record UID (contains environment settings)
Resource Record UID (contains target resource data)
Account Record UID (the record that was rotated)
Old Password (from Account Record)
New Password (from Account Record)
Username (from Account Record)
After the command is executed, Keeper Gateway clears the command line history on Linux and Windows instances.
If a Post-Rotation script requires access to other secrets beyond those passed in automatically, users are strongly encouraged to use the Keeper Secrets Manager SDKs or the Secrets Manager CLI tool.
Storing Keeper Gateway Configuration in AWS KMS
If the Keeper Gateway is installed on an Amazon Web Services (AWS) Elastic Compute Cloud (EC2) Instance, the corresponding Gateway configuration file can be stored in your AWS Key Management Service (KMS). This can be done by creating an Identity Access Management (IAM) Role Policy and assigning it to the EC2 Instance in order to provide the Keeper Gateway service with the required permissions to retrieve the necessary configuration from the AWS KMS. This method eliminates the need for storing a configuration file on the disk, and instead stores the configuration file in your AWS KMS.
AWS KMS is a fully managed service that makes it easy for you to create and control the cryptographic keys used to encrypt and decrypt your data. The service is integrated with other AWS services, making it easier to encrypt data and manage keys. You will need a AWS KMS key as part of this process, and it is recommended that you follow the principle of least privilege when assigning permissions to this key.
AWS Secrets Manager stores a base64 configuration string that is generated from a One-Time Token in Keeper Vault. In the Vault, generate a One-Time Token by creating new Gateway. Then convert the generated One-Time Token into a configuration using the Gateway command ott-init
. For example:
gateway ott-init [ONE-TIME-TOKEN]
Securely keep the output of this command. This value will be later entered into the AWS Secrets Manager as a value for a secret.
A. Navigate to the AWS Secrets Manager
Log in to your AWS Management Console. In the 'Services' dropdown, select 'Secrets Manager'. This will direct you to the AWS Secrets Manager home page.
B. Start the Process of Creating a Secret
On the AWS Secrets Manager home page, click on 'Store a new secret'. This will take you to a new page where you'll initiate the creation of a new secret.
C. Input Secret Details
Select 'Other type of secrets (e.g. API key)' as the secret type. Now, it's crucial to note that your Gateway Configuration in Base64 string format should be directly entered into the 'Plaintext' text box. This is important because AWS Secrets Manager supports both key/value and plaintext secret formats, but in this case, the plaintext format type will be used.
In the "Encryption Key" section, select the KMS key that will be used to encrypt the secret. If you don't have a KMS key already, AWS Secrets Manager can create one for you.
D. Secret Name and Description
Once Value of the "Plaintext" field is entered, click "Next" button. Provide a unique name for your secret. This name serves as the identifier for finding it within AWS Secrets Manager and will be used later when we will be configuring Gateway to use AWS Secrets Manager secret. Optionally provide a description that details the purpose of this AWS Secrets Manager secret or other related information.
E. Review and Store the Secret
Review all the details of the secret. Once everything is accurate, click on 'Store'. You have now successfully created a new secret in AWS Secrets Manager.
The EC2 instance you create should be a standard type that can have an IAM role assigned to it. There are various types of instances, each suited to different use cases, so choose one that fits your needs. The Gateway tool is compatible with any standard configurations, which gives you flexibility in your instance selection.
Create an IAM role that can be used by your EC2 instance to make API requests on your behalf. This IAM role should be configured with the least privileges necessary, allowing it to read only the necessary values from AWS Secrets Manager. This helps to reduce the potential for accidental exposure of sensitive information.
Navigate to IAM Dashboard - https://console.aws.amazon.com/iam/
Create new role
Type: "AWS service"
Common use case: EC2
Go to Step 2 and click on "Create policy" which should open a new tab.
Select "JSON" policy and enter the following:
Be sure to replace placeholders like "[REGION]", "[ACCOUNT ID]", and "[SECRET NAME WITH RAND]" with your actual AWS account details.
secretsmanager
: This is the specific AWS service that the resource belongs to. In this case, the resource is managed by AWS Secrets Manager.
[REGION]
: The region is the geographical AWS region where the resource is located. For example, us-west-2
for the US West (Oregon) region.
[ACCOUNT ID]
: This is the AWS account ID of the account that owns the resource. It's a 12-digit number unique to your AWS account.
secret
: This indicates the type of resource. In this case, the resource is a secret stored in AWS Secrets Manager.
[SECRET NAME WITH RAND]
: This is the name that you gave the secret when you created it in AWS Secrets Manager. Make sure that the name is the one found in the secret ARN, it should include random characters after a dash. Example: arn:aws:secretsmanager:us-east-1:134301558361:secret:keeperRotationGatewayConfig-Vwt7zX
Name the policy and click on "Create policy"
The last step is to attach this policy to the newly created role. Navigate back to the previous tab, refresh list of roles then attach this new policy to the role.
And lastly, on the last page give a name to the new role, make sure Step 2 has policy attached, and hit "Create role".
Now that your IAM role is properly configured, the next step is to attach it to your EC2 instance. This process involves standard AWS procedures to start an AWS EC2 Instance and attach a policy to it. For detailed steps, refer to the AWS EC2 documentation.
With the IAM role attached to your EC2 instance, it's important to validate that the setup has been done correctly. You can do this by running the AWS CLI command inside the EC2 instance to verify it has access to the secret:
Note: This command will output secret to the screen.
If you received successful output then that means that the EC2 instance was configured successfully and we are ready to configure the Keeper Gateway.
The AWS Secrets Manager Key is an identifier that is specified when starting the Gateway. It's used to enable the Gateway to access the secret from AWS Secrets Manager. If this key is not specified, the Gateway will not start. It's important to handle this key value securely and keep it confidential. Make sure that in this case the secret name will be the one that the key is named in AWS Secrets Manager, ie. without random characters that you specified before in the ARN.
A. Using Command Line Parameter: Here's a command that starts the Gateway in debug mode, logging all outputs to the log file. It uses the secret name provided:
B. Using Environment Variable: This is a method particularly useful when running the Gateway in a containerized environment. You set the environment variable AWS_KMS_SECRET_NAME
to [SECRET NAME] before starting the Gateway. This allows your application to read the SM Key directly from the environment variable.
Open the Keeper Gateway service unit file /etc/systemd/system/keeper-gateway.service
file and modify line that starts with ExecStart
change --config-file /etc/keeper-gateway/gateway-config.json
to --aws-kms-secret-name="[SECRET NAME]"
where [SECRET NAME]
is a name of the AWS KMS Secret.
The line should look like this:
Apply changes to the service:
Always adhere to the principle of least privilege when granting access permissions. This principle ensures that only the minimum necessary access is granted to perform an action.
Setting up your Azure environment to work with Keeper Secrets Manager
In order to set up your Azure environment, the following steps must be taken:
Create an Azure application in the default Azure Active Directory.
Get values for the Keeper PAM Configuration from this new application.
Grant permissions to the application to access the Azure Active Directory.
Create a custom role to allow the application to access/perform actions on various Azure resources.
Go to the Azure portal > Home and click on Azure Active Directory in the left side vertical menu. Select App Registrations, and then New Registration. Give the new application a name and select Single tenant for Supported accounts types. Then click the Register button at the bottom.
In the Overview of the application, the Application (client) ID UUID is shown. This is the Client Id field of the Keeper PAM Configuration record. The Directory (tenant) ID is also shown. This is the Tenant Id field of the Keeper PAM Configuration record. Save these values for later.
Next click on the Add a certification or secret for Client credentials. On the next page, click on New client secret, give the client secret a Description, and select a desired Expires date, and click Add.
The page will refresh showing the secret Value. Copy the Value (not Secret ID) into the Keeper PAM Configuration "Client Secret" field. Save this value for later.
At this point, all the required the PAM Configuration fields should be filled in. You also have an Azure application that cannot do anything yet.
In order for the Azure tenant service principal/application to rotate Azure Active Directory users or Azure Active Directory Domain Service users, the application must be a assigned to an Administrative role.
From the Azure portal go to Home > Azure Active Directory > Roles and administrators, and click on the Administrative role to use (such as Privileged Authentication Administrator). The correct role depends on what privileges are needed for your use case. Custom roles can be used.
Global Administrator - It is not recommended to use a Global Administrator on a service principal. However, it will allow both administrator and user passwords to be rotated.
To add the application, click Add assignments and Search for the service principal/application that was created, click it, and then Add.
Roles need to be attached to the Azure Application (also called a Service Principle here) in order to rotate passwords of target resources. This is done in the Subscription section of the Azure portal.
Go to the Azure portal > Home > Subscriptions then select your subscription. Click on Access control (IAM), and then Roles.
Click Add on the top menu, and then Add custom role. Jump to the JSON tab. Click on Edit and paste the JSON object from below, modifying it according to your setup.
This is a complete list of all of the permissions that Keeper Gateway can use, if applicable. Only include those that are needed for your setup.
Change the following before you save:
<ROLE NAME>: Role Name, e.g. "Keeper Secrets Manager"
<DESCRIPTION>: Description, e.g. "Role for password rotation"
<SUBSCRIPTION ID>: Subscription ID of this Azure subscription
Click Save.
When done, click Review + create, and click Create.
Once the role is created, it needs to be assigned to the Application (Service Principle). Click View in the Details column.
A panel will appear on the right side of the screen. Click Assignments, and then Add assignment.
Enter in the new role's name in the search bar on the Role tab, then double click it to select it. Move to the Members tab. Click Select members. In the panel that opens, enter the name of the Azure application, select the current application, and click Select.
Go to the Review + assign tab click Review + assign.
🎉 At this point, you have created the necessary roles and applications within your Azure environment.
Advanced configuration of the Keeper gateway with Keeper Vault custom fields
These configuration capabilities are functional and currently in an experimental phase, and we invite users to actively explore and utilize them. We are actively evaluating their functionality and performance, with the intention of considering them for official integration into our product in the future.
The additional gateway configurations will be defined with these custom fields on the PAM Record Types. The Keeper Gateway will then adjust its behavior based on the defined configurations.
The following tables lists all the possible configurations with custom fields:
Note:
The custom fields values are not case-sensitive.
- Can change the password for any user, including a Global Administrator user.
- Can change the password for any user, except a Global Administrator user.
When setting up Rotation in your Keeper Vault, you store the credentials of your assets involved in rotation on their corresponding . On these record types, you are able to .
Custom Field Name | Type | Default Value | Description |
---|
| Text |
| Allows you to specify a custom shell path that the Gateway will use when executing rotation and post-rotation scripts. This gives you control over the environment in which these scripts run.
Example Value: |
| Text |
| Allows you to control whether the Gateway performs the primary rotation operation or proceeds directly to execution of the post-rotation script. If set to |
| Text |
| Specifically designed for WinRM connections using Kerberos authentication.
By default, the Gateway automatically decides whether to use Kerberos based on certain rules, and If these conditions are met, the Gateway will attempt to use Kerberos for WinRM. However, if you encounter issues with this automatic detection, setting this field to |
| Text |
| Gateway Version 1.3.4+
This custom field pertains to the type or algorithm of the private key stored in a record.
When adding a private key to a record, users do not need to take any additional action regarding its type or algorithm. The system is designed to automatically recognize and use the same algorithm as the existing private key during the rotation process. If the algorithm in use is ECDSA, the key size will also be preserved during the rotation.
Available Options if needed to overwrite the key type:
|
| Text |
| Gateway Version 1.3.4+
|
Rotating AWS Managed Microsoft AD Service accounts with Keeper
In this guide, you will learn how to rotate Admin and User Accounts of an AWS Managed Microsoft AD service using Keeper Rotation. The Active Directory Service is an AWS managed resource where the Directory Service admin credentials are defined in the PAM Directory record type and the configurations of the AD Users are defined in the PAM User record type.
For Amazon Managed Active Directory Services, the AWS SDK will be used to rotate the password of Directory Admins. User Account passwords will be rotated using LDAP and, in order to successfully rotate, server-side LDAPS must be configured and the Directory Admin, defined in the PAM Directory record type, must be using a SSL Connection.
For a high-level overview on the rotation process in the AWS Environment, visit this page.
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your enterprise and your role
Keeper Rotation is enabled for your role
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is able to communicate with your AWS Directory Services
Your AWS environment is configured per our documentation
Keeper Rotation will use the Directory admin credentials of your AWS Managed Directory Service to rotate passwords of Domain Service's directory accounts. These admin credentials can also be used to rotate the passwords of the Directory admin.
The following table lists all the required fields on the PAM Directory Record:
Note: Adding Provider Region and Directory ID will enable managing the PAM Directory Record through the AWS SDK, which is preferred.
This PAM Directory Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
If you already have a PAM Configuration for your AWS environment, you can simply add the additional Resource Credentials required for rotating directory users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration". The following table lists all the required fields on the PAM Configuration Record:
For more details on all the configurable fields in the PAM Network Configuration record, visit this page.
Keeper Rotation will use the credentials in the PAM Directory record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the required fields on the PAM User record:
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Directory credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit
rights to a PAM User record has the ability to setup rotation for that record.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
Select the PAM Directory record from Step 1, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Directory credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
If the desired Admin Credential is not showing in the rotation settings screen, go to Secrets Manager > PAM Configuration > and add the necessary resource credentials.
The following windows command can be used to get the distinguished name of the Directory user:
If the command does not exist, you need to import the appropriate module with:
Field | Description |
---|---|
Field | Description |
---|---|
Field | Description |
---|---|
Title
Name of the Record i.e. AD Domain Service
Hostname or IP Address
The Directory DNS Name i.e. ad.pam.test
Port
636
for LDAPS, for default ports see port mapping
Use SSL (checkbox)
Must be checked
Login
Directory Service Admin Account i.e. Admin
Note: Either Login and Domain Name or Distinguished Name is required. Distinguished Name is preferred.
Password
Directory Service Admin Password
Distinguished Name
Directory Service Admin Account's Distinguished Name (DN).
Note: If DN is not provided, the following format will be used:
Given domain name is example.com
:
CN=<user>,CN=Users,DC=example,DC=com
Domain Name
The Directory DNS Name Note: This is required if using Login instead of Distinguished Name
Directory ID
Directory Service's Identifier i.e d-##########
Directory Type
Directory Service Directory type, defaults to Active Directory
if left blank.
Provider Region
AWS region name i.e. us-east-1
Title
Configuration name, example: AWS AD Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Active Directory server from the pre-requisites
Application Folder
Select the Shared folder that contains the PAM Directory record in Step 1
Admin Credentials Record
Select the PAM Directory record created in Step 1 This is the record with the admin credentials and sufficient permissions to rotate the directory user account's credentials
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
Access Key ID
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE
if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Region Names
List of AWS region names, one per line
Example:
us-east-1
us-east-2
Title
Keeper record title i.e. AWS Directory User1
Login
Username of the Directory Service's user account
Password
Account password is optional, rotation will set one if blank
Distinguished Name
Directory Service User Account's Distinguished Name (DN)
The Base64 encoded JSON object can be unpacked with various scripts and applications.
Linux and MacOS has no built in JSON parser, so, in order to parse JSON, a tool like jq is required.
Keeper will execute this as follows:
MacOS history
is not like Linux history
. Linux uses history -c
, macOS uses local HISTSIZE=0
to clear the history. This mainly affects SSH connections where BASH is not forced.
Keeper will execute this as follows:
The post rotation script is not limited to shell scripts. Applications can be written in languages like Python or C# to get the piped parameters.
Since the UIDs of the Rotation involved records are passed in the params, Application can also use the KSM SDKs to get additional information about the records.
For more information on the available SDKs, visit:
The next section will go over the results from the Post Rotation Scripts, post execution.
Example use cases for post-rotation scripts in Keeper
The following section contains code snippets on common post-rotation script use cases:
Database Use Cases
Upon execution of the script, the following information is returned. The results are an an array containing instances of RotationResult
for each script that was executed. The class RotationResult
has the following attributes:
uid
- Keeper Vault record UID that has the script attached
command
- Command that was issued to the shell.
system
- Operating system the script will run upon.
title
- Title of the script file attached to the Keeper Vault record.
name
- Name of the script attached to the Keeper Vault record.
success
- Was the script successful?
Linux and macOS - Script returned in a 0 return code.
Windows - Script returned a True status.
stdout
- The standard out from the execution of the script.
stderr
- The standard error from the execution of the script.
Additionally, the following methods can be used to determine if the script was a success, or not:
With this, it is possible to customize logging:
The class RotationResult
has attribute stderr
which logs the errors from execution of the script.
Although post rotation script results and information are available via the RotationResult
class, errors and outputs of scripts are based on the type of shell the script is executed on. Keeper does not check the standard out or errors of the scripts as Keeper does not know what defined an error for a customer controlled script.
For example, if a BASH script does not contain a set -e
, the script will continue even if part of the script fails. If the script exits with a 0
return code, the script will be flagged as successful.
Therefore, it is up to the user to properly handle the outputs and errors of the script.
Upon successful rotation of credentials on a PAM record, Keeper executes the attached Post-Rotation scripts with parameters containing information on the involved records, credentials, and user.
Parameters will be placed in a Base64 encoded JSON object and piped to the script. The following keys can be found in this JSON object:
records
fieldThe records key value is a Base64, JSON array of dictionaries. This array will include the following data:
PAM Network Configuration Data
PAM Machine, PAM Database, or PAM Directory Record Data
The PAM record type is depended on the PAM record type of the administrative credential
Additional Record Data
These are the Resource Credential(s) attached to the Post Rotation Script
User Record Data
Each dictionary object will contain:
uid
- The UID of the Vault record.
title
- The title of the Vault record.
The rest of the dictionary will contain key/value pairs of the record's data where
the key will be the label of the field.
If the field does not contain a label, the field type will be used.
If the key already exists, a number will be added to the key.
the value will be the corresponding field value
Note: The rotationScripts
field will be omitted from the data.
Since the parameters are piped to the script, the parameters will not appear on the command line.
The next section will go over how to access these parameters.
Post Rotation scripts can be attached to any of the PAM Record Types. Depending on the PAM record the script is attached to, the script will run either on the gateway, or the remote host where rotation occurred.
The following table shows all the available PAM Records and where the attached script will execute:
Scripts will be executed in the following order:
Scripts attached to User Record types
Scripts attached to PAM Machine, PAM Database, or PAM Directory Record types
Scripts attached to PAM Network Configuration Record types
If multiple scripts are attached to a record, scripts will be executed in the order they're in on the PAM Record
When creating or editing a PAM record, towards the bottom, there is a Add PAM Script button:
Clicking on Add PAM Script will allow you to:
Browse locally and choose your Rotation Script(s). [Required]
Add additional Resource Credential(s). This is to add additional records which contains the necessary credentials required to execute the attached post rotation script(s). [Optional]
Specify a custom command to executed. In the below screenshot, I attached a python script (postRotationTest.py
) and specified the command to be used to execute the python script. [Optional]
Multiple Scripts can be attached to a record.
After successfully selecting the script(s), the record will be updated to show the attached Post Rotation scripts:
Click Save to create or update the record. Attached Post Rotation Scripts can be deleted or edited by clicking on their respective inline icons.
Rotating Okta user accounts using the Okta API
This documentation provides guide how to set up password rotation using Okta and the Keeper PAM Gateway using "NOOP mode". This is a flag set in the Keeper record which tells the Gateway to skip the primary rotation method and directly execute the Post-Rotation script.
This guide includes pre-requisites, step-by-step instructions, and a Python script example.
KSM Application: Ensure that the Keeper Secrets Manager (KSM) application is set up.
Shared Folder: A shared folder should be set up where all the records will be stored.
PAM Configuration: Ensure that the PAM Configuration is set up and that the Gateway is running and attached to this configuration.
Okta API Token: You will need an Okta API Token to interact with the Okta API.
Follow the steps in the official Okta documentation to generate an API token.
Store this API token in a Keeper record. The record can be of any type, but for this example, we will use a "Login" type.
Store the API Token in the "password" field.
Store the Organization URL in the "Website Address" field.
Name this record "Okta API Access Details" as this title will be used to fetch the record in the script later.
Create a new PAM User record to store Okta User details whose password will be rotated.
Set the username to match the Okta user's email address.
Set the password to the current password set for the user.
Okta SDK only supports password rotation if the current password is valid. If the password is incorrect, the rotation will fail.
Attach the below Python script that will perform the password rotation. The script has additional comments inside that describe each line.
Add the "Rotation Credential" record, which is the record created in Step 1 containing the Okta API Token and Organization URL.
Enable No-Operation (NOOP) atomic execution:
In the current PAM User record where user's details are stored, create a new custom text field labeled NOOP
and set its value to True
.
Rotation Type: Set it to "On-Demand" for this example.
Password Complexity: Leave it as default unless you have specific requirements.
Rotation Settings: Point to the PAM Configuration set up earlier.
Administrative Credentials Record: Can should be left empty
Below is a screenshot of a fully loaded Okta Rotation record.
The below steps are related to the environment where the Keeper Gateway is running.
Ensure that the Python environment has all necessary dependencies installed.
If you want to use a virtual environment, add a shebang line at the top of the script.
Ensure that the shebang line does not contain spaces. If it does, create a symbolic link without spaces.
Below is an example to create a symbolic link on Linux:
sudo ln -s "/Users/john/PAM Rotation Example/.venv/bin/python3" /usr/local/bin/pam_rotation_venv_python3
The Python script below is well-commented and follows best practices. It imports necessary modules, initializes variables, and defines functions for various tasks like finding a password by its title, fetching all Okta users, and rotating the password for the particular user.
Method | Descripton |
---|---|
Key | Description |
---|---|
Record Type | Attached Post Execution Script will execute on |
---|---|
was_failure
boolean, return True if failure, False if success
was_success
boolean, returns True if success, False if failure
providerRecordUid
The UID of the Keeper Vault Provider record
resourceRecordUid
The UID of the Keeper Vault Resource record
userRecordUid
The UID of the Keeper Vault User record
newPassword
The new password for the User
oldPassword
The prior password for the User
user
The username for the User
records
Base64, JSON, array of record dictionaries. Additional info in the below section
PAM Network Configuration
Gateway
PAM Machine
The Device specified in record
PAM Database
The Device specified in record
PAM Directory
The Device specified in record
PAM User
Gateway
To update the 'Log On As' property on a Windows Scheduled Task, you will need a credential with the appropriate permissions, such as an Administrator account.
When attaching a PAM script to a record, you have the option to add a Resource Credential that is passed to the Gateway as part of the BASE64-encoded JSON data. The above credential will need to be attached as a Resource Credential.
As many Resource Credentials can be attached to a PAM script, knowing the UID
of the Resource Credential you have attached helps ensure your script uses the correct one to update the Service's 'Log On As' property.
You can use the schtasks
command to update the credentials on the Scheduled Task. This command also requires the admin credentials mentioned above to perform the task.
Unfortunately, as the schtasks
command is not a PowerShell cmdlet, so its output will not be captured by $error
. Without additional error checking, regardless of the exit status of the schtasks
command, the gateway will always show success. To solve for this, you can check $LastExitCode
after each call to schtasks
.
Example of a generic Bash script, equipped with error handling and input validation, to efficiently decode and process Base64-encoded JSON strings using the `jq` tool.
Example command to simulate how the script will be executed by the Gateway:
To update the 'Log On As' property on a Windows Scheduled Task, you will need a credential with the appropriate permissions, such as an Administrator account.
When attaching a PAM script to a record, you have the option to add a Resource Credential that is passed to the Gateway as part of the BASE64-encoded JSON data. The above credential will need to be attached as a Resource Credential.
As many Resource Credentials can be attached to a PAM script, knowing the UID
of the Resource Credential you have attached helps ensure your script uses the correct one to update the Service's 'Log On As' property.
PowerShell 7 makes it easy to update service credentials. By default, even in PowerShell 7, when remoting, the default PSSession will be Windows Powershell (v5). To remote using PowerShell 7, you can specify the built-in PowerShell 7 configuration: PowerShell.7
. Once the rotation is complete, we will also log the service status to DEBUG.
As mentioned above, a BASE64 string will be piped into your script, which includes the username and new password (among other data), which you will use to rotate the Windows Scheduled Task credentials.
Using the below snippet, we can take the piped input and use certutil
to decode the BASE64 string. These will be saved to temporary files and cleaned up later, as is the custom in bat
scripts, as certutil
only accepts files as input.
jq
can be used on the resulting JSON file to get the values of user
and newPassword
.
To update the 'Log On As' property on a Windows Scheduled Task, you will need a credential with the appropriate permissions, such as an Administrator account.
When attaching a PAM script to a record, you have the option to add a Resource Credential that is passed to the Gateway as part of the BASE64-encoded JSON data. The above credential will need to be attached as a Resource Credential.
As many Resource Credentials can be attached to a PAM script, knowing the UID
of the Resource Credential you have attached helps ensure your script uses the correct one to update the Service's 'Log On As' property.
We can use jq
to access the attached Resource Credential and filter by the records UID.
The schtasks
command is used to update the desired Scheduled Task using the values you just extracted. In addition to the new credentials, you will need the Admin credentials from above.
The following code snippets update the credential on a Windows Service running as a Service Account after its password has been rotated via Keeper Rotation.
The data in the record being rotated is made available to your script via a BASE64-encoded JSON
string. This is passed into your script for consumption. When your script has finished execution, Clear-History
is executed to ensure that the record data is not available for future PowerShell sessions.
To rotate the credential of a service account, the user (which in this case is the Gateway's user account) will need to be part of the Administrator's group on the target machine. This means the Gateway must run as a Service account that is assigned the appropriate level of privilege to achieve this and not run as the default SYSTEM user.
The data in the record being rotated is made available to your script via a BASE64-encoded JSON
string. This is passed into your script for consumption.
To run this script, SSH public key authentication must be set up and enabled between the gateway server and the target server.
In the below example, you will hard code three values:
The name of the service for which you wish to rotate the credential.
The DNS resolvable name of the server the service is running on.
The username of the SSH user
Native SSH remoting is still not fully implemented into PowerShell and is only reliably possible in PowerShell 7. The gateway defaults to Windows PowerShell (v5) when running a .ps1
script. However, when attaching the script, you can also specify an alternative script command and point to the path of your PowerShell 7 executable.
Once the rotation is complete, we will log the service status to DEBUG.
In the below example, you will hard code two values:
The name of the service for which you wish to rotate the credential.
The DNS resolvable name of the server the service is running on.
You can decode the BASE64 string and convert it to a useable PowerShell object with:
The sc.exe
command is used to update the desired Windows service using the values extracted from the JSON
.
Note: sc is an aliase in Windows PowerShell for Set-Content. Therefore you must include the file extension or provide a full path to the executable.
After updating the Windows Service, we will restart it, which will confirm that the credentials have been updated successfully.
Note: The SC command has particular syntax. The whitespace after
=
matters! All server names must start with a double backslash.
Unfortunately, as the sc.exe
command is not a PowerShell cmdlet, so its output will not be captured by $error
. Without additional error checking, regardless of the exit status of the sc.exe
command, the gateway will always show success. To solve for this, you can check $LastExitCode
after each call to sc.exe
.
To update the 'Log On As' property on a Windows Service, you will need a credential with the appropriate permissions, such as an Administrator account.
When attaching a PAM script to a record, you have the option to add a Resource Credential that is passed to the Gateway as part of the BASE64-encoded JSON data. The above credential will need to be attached as a Resource Credential.
As many Resource Credentials can be attached to a PAM script, knowing the UID
of the Resource Credential you have attached helps ensure your script uses the correct one to update the Service's 'Log On As' property.
PowerShell 7 makes it easy to update service credentials. By default, even in PowerShell 7, when remoting, the default PSSession will be Windows Powershell (v5). To remote using PowerShell 7, you can specify the built-in PowerShell 7 configuration: PowerShell.7
. Once the rotation is complete, we will log the service status to DEBUG
.
The target server must be running Windows Server 2012 and above and have the IISAdministration
module installed and enabled.
To update the 'Log On As' property on a IIS Application Pool, you will need a credential with the appropriate permissions, such as an Administrator account.
When attaching a PAM script to a record, you have the option to add a Resource Credential that is passed to the Gateway as part of the BASE64-encoded JSON data. The above credential will need to be attached as a Resource Credential.
As many Resource Credentials can be attached to a PAM script, knowing the UID
of the Resource Credential you have attached helps ensure your script uses the correct one to update the Service's 'Log On As' property.
Using the IISServerManager
, you can update the credentials and restart the ISS App Pool by invoking the script block below.
Automatically any cloud-based account using a REST API with Keeper Secrets Manager
This guide includes pre-requisites, step-by-step instructions, and a Python script example.
KSM Application: Ensure that the Keeper Secrets Manager (KSM) application is set up.
Shared Folder: A shared folder should be set up where all the records will be stored.
PAM Configuration: Ensure that the PAM Configuration is set up and that the Gateway is running and attached to this configuration.
REST API Token: You will need an API Token to interact with the arbitrary API.
Follow the steps in your target application or service to generate an API token.
Store this API token in a Keeper record. The record can be of any type, but for this example, we will use a "Login" type.
Store the API Token in the "password" field.
Store the Organization URL in the "Website Address" field.
Name this record "API Access Details" as this title will be used to fetch the record in the script later.
Create a new PAM User record to store target User details whose password will be rotated.
Set the username to match the user's login ID.
Set the password to the current password set for the user (this really depends on the REST endpoint)
Add the "Rotation Credential" record, which is the record created in Step 1 containing the API Token and URL.
Enable No-Operation (NOOP) atomic execution:
In the current PAM User record where user's details are stored, create a new custom text field labeled NOOP
and set its value to True
.
Rotation Type: Set it to "On-Demand" for this example.
Password Complexity: Leave it as default unless you have specific requirements.
Rotation Settings: Point to the PAM Configuration set up earlier.
Administrative Credentials Record: Can should be left empty
Below steps are related to the environment where the Keeper Gateway is running.
Ensure that the Python environment has all necessary dependencies installed.
If you want to use a virtual environment, add a shebang line at the top of the script.
Note: Ensure that the shebang line does not contain spaces. If it does, create a symbolic link without spaces. Example to create a symbolic link on Linux:
sudo ln -s "/Users/john/PAM Rotation Example/.venv/bin/python3" /usr/local/bin/pam_rotation_venv_python3
The Python script is well-commented and follows best practices. It imports necessary modules, initializes variables, and defines a rotation function to call an arbitrary REST API that changes user's password.
To use these scripts, PowerShell 7 must be available on the target machine and should be set up and configured to enable remoting using PowerShell 7 using .
The Remote Procedure Call (RPC) and services should be enabled and running on the target server to run the scripts in the examples below.
This example uses the commonly used tool , for parsing the JSON data passed to the script containing the records data. This example assumes you have it installed and the jq
command is in PATH.
This documentation provides generic instructions on how to set up password rotation using any cloud-based application or API endpoint and PAM Gateway using "NOOP mode". This is a which tells the Gateway to skip the primary rotation method and directly execute your custom Post-Rotation script.
Attach the below that will perform the password rotation. The script has additional comments inside that describe each line.
Example guide for setting up WinRM on target machines
Customers are responsible for the configuration of their servers and environments. For reference and testing, the below PowerShell script can be run on a target machine to enable WinRM with a self-signed certificate. We recommend creating a certificate with a public CA in your production environment.
Below is a breakdown of what this script performs to configure WinRM on a Windows machine:
Set the network connection profile to Private:
Configure and enable WinRM:
Allow non-SSL (unencrypted) traffic on port 5985:
Create a self-signed SSL certificate for encrypted traffic on port 5986:
Create Windows Firewall rules to allow inbound traffic on ports 5985 (non-SSL) and 5986 (SSL):
After running this script, WinRM will be configured to allow both unencrypted (port 5985) and encrypted (port 5986) remote connections. Additionally, Windows Firewall rules will be created to allow inbound traffic on these ports.
From a Windows server, you can test the connectivity to the target machine through PowerShell:
Example guide for setting up SSH on target machines
Customers are responsible for the configuration of their servers and environments.
Secure Shell (SSH) allows confidential and authenticated remote access to a computer. SSH traffic is fully encrypted and, by default, runs on port 22
. For reference and testing, see below for instructions and guidance on enabling SSH for your target operating system.
Linux requires the SSH daemon to be running in order to accept SSH connections. Most Linux distributions will have the OpenSSH server installed, but may not have the service enabled. The service needs to be enabled, started, and added to the list of services to be started upon reboot.
To verify that ssh is running on your Linux system, invoke the following command:
If ssh is not running, you may need to install OpenSSH or/and enable ssh. The following commands demonstrate this in Ubuntu:
Note:
you may need sudo permissions to install and enable ssh
The installation command may be different based on your linux distribution
SSH is normally not installed on Windows. However, SSH can easily be installed via Windows capability packages which are maintained by Microsoft. The following PowerShell script will 1) install SSH, 2) start the SSH service and makes sure it starts with each reboot, and 3) make sure the firewall allows SSH connections:
Windows SSH can either default to PowerShell or CMD. Keeper Rotation uses PowerShell commands. If the default shell is CMD, Keeper Rotation will invoke rotation commands via PowerShell Invoke-Command -ScriptBlock { COMMANDS }
. To change the default shell to PowerShell, invoke the following PowerShell command:
SSH is installed on macOS and usually not turned on for the user.
To enable it via the UI, enable Remote Login on the General->Sharing panel.
To enable it via the command line, invoke the following command:
Note:
you will require Full Disk Access privileges for this command line method.
Defining alternative ports in PAM Configurations
Rotation relies on the port field in resource records to determine its connection method.
For example, in a PAM Machine record, port 22 tells the gateway to use SSH, port 5985 for WinRM (http) and port 5986 for WinRM (https).
The expected standard ports are listed in the following table.
To use a non-standard port, specify the alternative port in two places:
In the PAM Configuration port mapping field, enter {port}=
{connection}
, for example, 32636=ldaps.
For {connection}
: refer to the labels under Standard Port in the standard ports table.
In the PAM Machine/Directory/Database record, enter the chosen port in the port field
For example, to connect to a MySQL database using port 3307, your PAM Configuration should have 3307=mysql
under port mapping, and your PAM Database record should reference port 3307.
Multiple port mappings are comma-separated in the PAM Configuration.
Managing rotation with the Commander CLI / SDK interface
Keeper Commander commands have been created to automate and manage the Keeper PAM capabilities including:
Managing Gateways
Managing PAM Configurations
Managing Password Rotation and Discovery
Managing jobs
Keeper rotation event reporting in the Advanced Reporting & Alerts module
A new set of Keeper Rotation events are included in the Advanced Reporting & Alerts module within the Keeper Admin Console.
For the following events, two status codes are included in the status message: one for Rotation, and one for Post-Rotation (if applicable).
If no post-rotation script is present, the event status reflects rotation only.
If multiple-post rotation scripts are present, a success event is generated only if all scripts complete execution without errors.
To receive immediate feedback on any rotation related events, Keeper's "Alerts" capability can push these events to email, SMS, webhooks, Slack, Teams, etc.
Record Type Details for PAM Machine, Database, and Directory
When Keeper Rotation is activated on a Keeper account, Rotation record types are added to the account. Records created using these types facilitate record rotation.
The following are supported configurations for record type associated to each Device or Account type:
The following tables provides more details on each configurable field in PAM Machine, PAM Database, and PAM Directory records:
Resource Type | Connection Type | Standard Port |
---|---|---|
For more information see the .
In addition, Rotation leverages existing . For example, when a Gateway is registered, the app_client_added event is generated.
Event | Description |
---|
Event | Description |
---|
To learn more about the Keeper Advanced Reporting & Alerts module .
Resource Type | Sub-type | Record Type |
---|
Field | Description | Notes |
---|
Field | Description | Notes |
---|
Field | Descrpiton | Notes |
---|
PAM Machine
SSH
22=ssh
PAM Machine
WinRM
5986=winrm
PAM Directory
Active Directory
636=ldaps
PAM Directory
OpenLDAP
636=ldaps
PAM Database
Postgresql
5432=postgresql
PAM Database
MySQL
3306=mysql
PAM Database
MariaDB
3306=mariadb
PAM Database
Microsoft SQL
1433=mssql
PAM Database
Oracle
1521=oracle
PAM Database
MongoDB
27017=mongodb
event_record_rotation_scheduled_ok | A scheduled rotation has completed successfully |
event_record_rotation_scheduled_fail | A scheduled rotation has encountered an error in either rotation or post-rotation |
event_record_rotation_on_demand_ok | An on-demand rotation has completed successfully |
event_record_rotation_on_demand_fail | An on-demand rotation has encountered an error in either rotation or post-rotation |
event_pam_configuration_created | PAM Configuration has been created |
event_pam_configuration_updated | PAM Configuration has been modified |
event_pam_configuration_deleted | PAM Configuration has been deleted |
event_record_rotation_created | Rotation settings have been added to a record |
event_record_rotation_updated | Rotation settings have been modified on a record |
event_record_rotation_disabled | Rotation settings have been removed from a record |
Database | MySQL, MySQL Flexible | PAM Database |
Database | PostgreSQL, PostgresSQL Flexible | PAM Database |
Database | SQL Server | PAM Database |
Database | Mongo | PAM Database |
Database | MariaDB | PAM Database |
Machine | Windows, macOS, Linux | PAM Machine |
Machine | EC2 Instance | PAM Database |
Machine | Azure VM | PAM Database |
Directory | Active Directory | PAM Directory |
Directory | OpenLDAP | PAM Directory |
Hostname or IP Address | Address of the machine resource | Required |
Port | Port to connect on. The Gateway uses this to determine connection method. | Must be a port for SSH or WinRM Keeper expects 22, 5985, 5986, or an alternative port for SSH or WinRM specified in the PAM Configuration port mapping |
Login | Admin account username |
Password | Password for admin account | If Port is 22, or an alternative port mapped to ssh: Private PEM key can used instead |
Private PEM Key | PEM Key for ssh connection (optional) | The key take precedence if both a key and password are provided |
OS | Operating System | For human reference only. Operating system is detected during rotation |
SSL Verification | Verify certificate of host when connecting with SSH |
Instance Name | Azure or AWS Instance Name | Not used for rotation |
Instance Id | Azure or AWS Instance ID | Not used for rotation |
Provider Group | Provider Group for directories hosted in Azure | Not used for rotation |
Provider Region | AWS region of hosted directory | Not used for rotation |
Hostname or IP Address | Address of the Database Resource | Required |
Port | Port to connect on. The Gateway uses this to determine connection method. | A Port must be provided. Standard ports are: postgresql: 5432 MySQL: 3306 Maria DB: 3306 Microsoft SQL: 1433 Oracle: 1521 Mongo DB: 27017 |
Use SSL | Use SSL when connecting |
Login | Admin account username |
Password | Admin account password |
Connect Database | Database to connect to (Postgres only) | Required for connecting to Postgres, MongoDB, and MS SQL Server |
Database Id | Azure or AWS Resource ID | Required for AWS and Azure rotations |
Database Type | Appropriate database type from supported databases. | If a non-standard port is provided, the Database Type will be used to determine connection method. |
Provider Group | Azure or AWS Provider Group | Required for Azure rotations |
Provider Region | Azure or AWS Provider Region | Required for AWS rotations |
Hostname or IP Address | Address of the directory resource | Required |
Port | Port to connect on | Typically 389 or 636 (LDAP/LDAPS) |
Use SSL | Use SSL when connecting |
Login | Username of domain account with rotation privilege | Example: "administrator" |
Password | Domain account password | Password is masked |
Distinguished Name | Distinguished name of the domain login provided above | Example: CN=Jeff Smith,OU=Sales,DC=demo,DC=COM If left blank, defaults are attempted depending on the provider type |
Directory ID | Instance ID for AD resource in Azure and AWS hosted environments | Required for Azure Active Directory and AWS Directory Service AWS Example: "d-9a423d0d3b' |
Directory Type | Directory type, used for formatting of messaging | Must be Active Directory or OpenLDAP |
Domain Name | domain managed by the directory | Example: some.company.com |
Provider Group | Provider Group for directories hosted in Azure | Required for directories hosted in Azure |
Provider Region | AWS region of hosted directory | Required for directories hosted in AWS Example: us-east-2 |