Keeper Connection Manager provides support for OpenID Connect for authentication.

Docker Environmental Variables

The image keeper/guacamole can be modified to support OpenID using environmental variables. See the OPENID_* variables defined in the documentation.

Keeper Connection Manager

Keeper Connection Manager (KCM) is a self-hosted, agentless remote desktop gateway that provides instant and secure access to desktops, servers, databases and web applications from a web browser.

Benefits of the KCM On-Prem platform:

• Self-hosted

• Agentless

• Lightning Fast and Responsive

• Simple Access Controls

• Customizable

• Works in air-gapped environments

Features include:

• Support for RDP, SSH, VNC, K8s remote access protocols

• Support for MySQL, PostgreSQL, SQL Server database protocols

• Support for web application protection through Remote Browser Isolation technology

• Session Recording and playback

• Privileged Session Management

• Multi-User Session Sharing

• Role-Based Access Controls

• MFA Options: TOTP, Duo

• PIV/CAC smart card authentication

• SSO, OpenID Connect, Active Directory, LDAP Integration

• Custom Branding

Video Overview

System Diagram

Keeper is typically deployed as a Docker container. The system architecture diagram is below.

Apache Guacamole

Keeper Connection Manager is the commercially-supported solution produced by the original creators of Apache Guacamole, the open source platform used by millions of people for accessing remote desktops. Keeper Connection Manager is built on top of the Guacamole gateway, with expanded capabilities, advanced integrations and ongoing feature development. Glyptodon was Acquired by Keeper Security in December 2021.

KeeperPAM Licensing

Keeper Connection Manager (self-hosted container) is included in your license of KeeperPAM. KeeperPAM is a modern, cloud-based privileged access management platform. Learn more about KeeperPAM at the links below:

Getting Started

Ready to get started with Keeper Connection Manager? Proceed to the .

When using the Auto Docker Install method, packages can be added by directly modifying the generated Docker Compose file. For example, adding SSO or LDAP support.

To modify your Keeper Connection Manager environment, you'll need to edit the docker-compose.yml file located here:

/etc/kcm-setup/docker-compose.yml

Applying Configuration Changes

The kcm-setup.run script has an apply feature which allows you to apply configuration changes without updating the containers. From the Linux command line, update to the latest installer script using the curl command.

Apply the changes

Update and Restart the Containers

To update the environment, use the kcm-setup.run upgrade command to update the containers and start with the latest configuration:

or.....

For convenience, a Docker image for SSL termination using NGINX is provided which automatically configures itself with an SSL certificate:

This image:

• Is based off Docker's official image for NGINX, and thus each accepts the same core environment variables.

• Accepts a set of Keeper-specific environment variables defining the Guacamole instance that will be behind SSL termination.

• Can automatically retrieve a certificate from Let's Encrypt, generate its own self-signed certificate for testing, or use an existing certificate that you have already obtained from a certificate authority.

• Requires the same ACCEPT_EULA environment variable as the and images.

See the to view configuration examples.

Keeper Connection Manager provides support for Duo as a second authentication factor, automatically verifying user identity with Duo after the user is initially authenticated. This integration utilizes the V4.

Duo Setup

From the DUO Security Admin portal:

• Select "Protect an Application"

• Search for "Web SDK" (Do NOT select Keeper Security - this is for the Vault only)

• Select Web SDK and click "Protect"

• Capture the Client ID, Client Secret, and API Hostname

• Provide these 3 configuration options as DUO_* environment variables in the keeper/guacamole Docker image.

Docker Environment Variables

The image keeper/guacamole section in the docker-compose.yaml file can be modified to support Duo using environment variables.

Data can be imported to a PostgreSQL connection from a file on your machine, or exported and downloaded to you machine.

Import

Import data from a file on your machine into the PostgreSQL connection.

To import data from a csv file, is the COPY command:

In the example above, "<table>" should be replaced with the SQL table to import data into. The other parts of the command are required for CSV-formatted files. If your uploaded file uses different termination characters update the query accordingly.

After running the query, Keeper Connection Manager will prompt you to supply the data file. To upload the file, simply drag and drop it from your machine onto the browser window.

Export

Data from the connected PostgreSQL database can be exported to a file on your machine. To do this, use the following query:

The result of the given <query> will be put into a CSV file with the given name and downloaded from the browser to your machine.

In a Docker install environment, it's possible to establish a connection to the Keeper Connection Manager host instance using a special host name called host.docker.internal.

To configure this, update the file /etc/kcm-setup/docker-compose.yml guacd section to include the "extra_hosts" parameter, as seen below:

Update the docker environment for the change to take effect.

Then, from within Keeper Connection Manager, you can create a new connection which simply references the Hostname of host.docker.internal.

For more information, see the below helpful article:

Overview

It may be necessary to create a connection into a target system which blocks ingress connections or is behind a firewall, particularly if you cannot install Keeper Connection Manager on a device within the target network.

For this use case, Keeper Connection Manager supports the use of reverse SSH tunnels. This guide provides a method of setting up a reverse SSH tunnel to access a system that is otherwise inaccessible due to inbound network restrictions.

This guide covers reverse SSH tunnels using the Auto Docker Install method and a target endpoint. Once the tunnel and configuration is complete, Keeper Connection Manager can establish a connection to the remote endpoint through the tunnel. You can use any supported connection within the tunnel, one established.

Using KeeperPAM instead of Reverse SSH Tunnels

Keeper's cloud-based product called KeeperPAM provides zero-trust encrypted connections through the Keeper vault. This eliminates the need for reverse SSH tunnels.

Overview

The Keeper Connection Manager home screen provides quick access to any connection that you have been granted access to.

If you have access to multiple connections, you will be taken to the dashboard where all available connections are listed. If you only have access to a single connection, you will be routed directly to that connection.

My Connections

The home screen contains a list of all connections to which you have access, along with thumbnails of any recently used or active connections. Thumbnail images update dynamically while a machine is being accessed. If you have access to a large number of connections and wish to quickly locate a specific connection, you can also enter search terms within the “Filter” field to filter the list of connections by name.

Clicking on any connection will open that connection within the current window or tab, but multiple connections can be used simultaneously.

Each connection you use will remain active until explicitly disconnected, or until you navigate away from Keeper Connection Manager entirely. Active connections can be seen as thumbnails updating in real-time on the home screen.

User Menu

With the exception of the client connection screen, all Keeper Connection Manager screens contain a menu in the upper-right corner called the “user menu”. This menu displays your username and contains several options which depend on your level of access.

Home

Navigates back to the home screen, if you are not already there. If you only have access to one connection, this will be replaced with a link to that connection.

Settings

Navigates to the settings interface, which provides the core Administrative functions (if you have rights to access this area) and and user preferences such as display language.

Logout

Logs out of Keeper Connection Manager completely, closing all current connections and ending the Keeper Connection Manager session.

Image: keeper/guacamole-db-mysql

keeper/guacamole-db-mysql is a Dockerized deployment of MySQL, built off Docker's official MySQL image which is automatically initialized with the Apache Guacamole database schema. It is built using the packages provided by Keeper Connection Manager and made available under the same EULA. It is normally used to provide a MySQL database for a container using the keeper/guacamole image.

Environment variables

In addition to the environment variables documented below, all environment variables supported by the official Docker MySQL image are accepted, as the official MySQL image forms the basis of this image.

ACCEPT_EULA

The ACCEPT_EULA environment variable must be set to "Y" to indicate your acceptance of the Keeper Connection Manager EULA. This Docker image may not be used except under the terms of the EULA.

MYSQL_RANDOM_ROOT_PASSWORD

This is an optional variable. Set to a non-empty value, like yes, to generate a random initial password for the root user (using pwgen). The generated root password will be printed to stdout (GENERATED ROOT PASSWORD: .....).

GUACAMOLE_DATABASE

The name of the database to create and initialized for use with Apache Guacamole. This environment variable is required and ultimately maps to the MYSQL_DATABASE environment variable of the official MySQL image.

The GUACAMOLE_DATABASE variable is provided here for consistency with the other Guacamole-specific variables, but may be omitted if MYSQL_DATABASE is provided.

GUACAMOLE_ADMIN_PASSWORD

This is the Administrator password for the guacadmin user.

GUACAMOLE_USERNAME and GUACAMOLE_PASSWORD

The username and password to use for the MySQL database user specific to the Guacamole web application. This pair of variables differ from the MYSQL_USER and MYSQL_PASSWORD environment variables provided by the official MySQL image in that the created user has limited privileges, being granted only what privileges are absolutely required for Guacamole to run.

The GUACAMOLE_USERNAME and GUACAMOLE_PASSWORD are not strictly required, as the user created with MYSQL_USER and MYSQL_PASSWORD may be used instead, however they are strongly recommended to ensure the Principle of Least Privilege is followed.

Docker secrets

Rather than pass data directly in environment variables, a _FILE suffix may be added to any environment variable supported by this image to force that variable to be read from the named file within the container. As Docker secrets store sensitive data within files beneath /run/secrets/ within the container, this can be used to load sensitive data from Docker secrets.

For example, to load the username and password for the limited-privilege user specific to the Guacamole web application from Docker secrets:

docker run --name some-guacamole-db \
    -e ACCEPT_EULA=Y \
    -e MYSQL_RANDOM_ROOT_PASSWORD=yes \
    -e GUACAMOLE_ADMIN_PASSWORD=some_password \
    -e GUACAMOLE_DATABASE=guacamole_db \
    -e GUACAMOLE_USERNAME_FILE=/run/secrets/mysql-username \
    -e GUACAMOLE_PASSWORD_FILE=/run/secrets/mysql-password \
    -d keeper/guacamole-db-mysql

Image: keeper/guacamole-db-postgres

keeper/guacamole-db-postgres is a Dockerized deployment of PostgreSQL, built off Docker's official PostgreSQL image which is automatically initialized with the Apache Guacamole database schema. It is built using the packages provided by Keeper Connection Manager and made available under the same EULA. It is normally used to provide a PostgreSQL database for a container using the keeper/guacamole image.

Environment variables

In addition to the environment variables documented below, all environment variables supported by the official Docker PostgreSQL image are accepted, as the official PostgreSQL image forms the basis of this image.

ACCEPT_EULA

The ACCEPT_EULA environment variable must be set to "Y" to indicate your acceptance of the Keeper Connection Manager EULA. This Docker image may not be used except under the terms of the EULA.

POSTGRES_PASSWORD

The PostgreSQL administrator password.

GUACAMOLE_DATABASE

The name of the database to create and initialized for use with Apache Guacamole. This environment variable ultimately maps to the POSTGRES_DB environment variable of the official PostgreSQL image. If omitted, the default value defined by the official PostgreSQL image will be used.

The GUACAMOLE_DATABASE variable is provided here for consistency with the other Guacamole-specific variables and may be omitted if POSTGRES_DB is provided.

GUACAMOLE_ADMIN_PASSWORD

This is the Administrator password for the guacadmin user.

GUACAMOLE_USERNAME and GUACAMOLE_PASSWORD

The username and password to use for the PostgreSQL database user specific to the Guacamole web application. This pair of variables differ from the POSTGRES_USER and POSTGRES_PASSWORD environment variables provided by the official PostgreSQL image in that the created user has limited privileges, being granted only what privileges are absolutely required for Guacamole to run.

The GUACAMOLE_USERNAME and GUACAMOLE_PASSWORD are not strictly required, as the user created with POSTGRES_USER and POSTGRES_PASSWORD may be used instead, however they are strongly recommended to ensure the Principle of Least Privilege is followed.

Docker secrets

Rather than pass data directly in environment variables, a _FILE suffix may be added to any environment variable supported by this image to force that variable to be read from the named file within the container. As Docker secrets store sensitive data within files beneath /run/secrets/ within the container, this can be used to load sensitive data from Docker secrets.

For example, to load the username and password for the limited-privilege user specific to the Guacamole web application from Docker secrets:

docker run --name some-guacamole-db \
    -e ACCEPT_EULA=Y \
    -e GUACAMOLE_DATABASE=guacamole_db \
    -e POSTGRES_PASSWORD=some_password \
    -e GUACAMOLE_ADMIN_PASSWORD=some_password \
    -e GUACAMOLE_USERNAME_FILE=/run/secrets/postgres-username \
    -e GUACAMOLE_PASSWORD_FILE=/run/secrets/postgres-password \
    -d keeper/guacamole-db-postgres

To update all of the Keeper Connection Manager docker images when using the Docker Compose Install method, run the below command (assuming docker-compose.yml is in the current folder):

sudo docker-compose pull
sudo docker-compose up -d

If you originally installed with the Auto Docker Install method (kcm-setup.run script), run the below command:

sudo ./kcm-setup.run stop
sudo ./kcm-setup.run upgrade

Select "Y" when prompted.

If you run into any issues with the upgrade, see our troubleshooting page.

Keeper Connection Manager is packaged and installed in your environment. As such, backups should be taken in order to recover the environment if required.

It is highly recommended to perform backups of the following components:

1. Server backup

2. Database snapshots

3. Docker compose and other critical files

Server Backup Instructions

• We recommend performing daily snapshots of your Keeper Connection Manager instances.

• In most installations, a database running locally or within the Docker containers includes the connection and user data. When backing up the instance, ensure that the database is included.

• When using the Advanced Linux Install method, ensure that the /etc/guacamole/ folder is included in the snapshot.

Database Snapshots

• For Docker and Auto Docker install methods, the kcm-setup.run backup command will run a backup locally.

• For other installation methods, please use the database platform's backup features, for example mysqladmin on MySQL-backed installs.

Docker compose

• Back up and protect the files located in /etc/kcm-setup/ which include docker-compose.yml and any other files which are being utilized by your container.

Keeper Connection Manager provides support for TOTP as a second authentication factor, verifying the identities of enrolled users using authentication codes generated with the TOTP standard.

Docker Environmental Variables

To enable TOTP add the following lines to the "environment" section of the "guacamole" service in the docker-compose.yml file. Only the EXTENSIONS: totp line is required, the rest are optional.

TOTP_ISSUER: "KCM"
TOTP_DIGITS: "6"
TOTP_PERIOD: "30"
TOTP_MODE: "sha1"
EXTENSIONS: "totp"

For example:

        environment:
            ACCEPT_EULA: "Y"
            GUACD_HOSTNAME: "guacd"
            MYSQL_HOSTNAME: "db"
            MYSQL_DATABASE: "guacamole_db"
            MYSQL_USERNAME: "guacamole_user"
            MYSQL_PASSWORD: "XXXXXXXXX"
            KSM_CONFIG: ""
            TOTP_ISSUER: "KCM"
            TOTP_DIGITS: "6"
            TOTP_PERIOD: "30"
            TOTP_MODE: "sha1"
            EXTENSIONS: "totp"

The image keeper/guacamole can be modified to support TOTP using environmental variables. See the TOTP_* variables defined in the documentation.

TOTP with SAML / OIDC

Keeper Connection Manager supports the use of 2FA with TOTP in addition to supporting SAML or OIDC authentication. If TOTP is configured along with SAML, the user will be prompted for 2FA after successfully authenticating with the identity provider.

If multiple authentication methods are installed, Keeper Connection Manager will poll each method as it attempts to authenticate users, and will retrieve connection data from each method once a user has successfully authenticated. This behavior is designed to allow authentication methods to work together, and can be leveraged to authenticate Keeper Connection Manager users against LDAP while storing the connection data for those users within MySQL, PostgreSQL, or SQL Server.

Keeper Connection Manager's definition of identity

When reading data from multiple authentication methods, Keeper compares the unique identifiers of users (usernames) and groups to determine identity. This means that user accounts from different authentication systems will be automatically combined by Keeper upon successful authentication as long as those user accounts have the same username, and group memberships will take effect across authentication systems so long as the unique names of those groups match.

If both LDAP and a database authentication method have been configured, Keeper will automatically attempt to authenticate against both systems whenever a user attempts to log in. The LDAP account will be considered equivalent to the database user if the username is identical, and that user will have access to any data associated with them via the database, as well as any visible objects within the LDAP directory. If that user has permission to query their group memberships within LDAP, and Keeper has been configured to query groups within LDAP, then the user's group membership will also be retrieved upon authentication, and the user will have access to any data associated with those groups via the database.

Administering LDAP users within Keeper Connection Manager

Rather than having to manually look up users or groups within the LDAP directory, and then manually create those same users and groups within Keeper Connection Manager, it is possible to set up administrative user accounts which can already see and manage available LDAP objects. This streamlines the administrative process, reducing the number of users which must be manually created to one.

To see LDAP objects within Keeper Connection Manager's administrative interface, one of the following tasks must be performed:

1. An administrative user within the Keeper Connection Manager database, such as the default “guacadmin” user, must be manually created within LDAP with the same username and with sufficient privileges to query all Guacamole users and groups defined within LDAP.

2. An administrative user must be manually created within Keeper Connection Manager having the same username as an LDAP user with sufficient privileges to query all Guacamole users and groups defined within LDAP.

Because a Keeper Connection Manager user created as defined above would have access to LDAP users and groups, database users and groups, and database connections, all of this data will be unified within the same administrative interface within Keeper Connection Manager. The user will be able to grant LDAP users and groups access to connections within the database to just as they would if only the database were in use.

Data can be imported to a MySQL connection from a file on your machine, or exported and downloaded to you machine.

Import

Import data from a file on your machine into the MySQL connection.

To import data from a csv file, is the LOAD DATA MySQL command:

LOAD DATA LOCAL INFILE "input.csv" INTO TABLE <table> FIELDS
  TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\r\n'

In the example above, "<table>" should be replaced with the SQL table to import data into. The other parts of the command are required for CSV-formatted files. If your uploaded file uses different termination characters update the query accordingly.

After running the query, Keeper Connection Manager will prompt you to supply the data file. To upload the file, simply drag and drop it from your machine onto the browser window.

Export

Data from the connected MySQL database can be exported to a file on your machine. To do this, use the following query:

 SELECT <query> INTO LOCAL OUTFILE "<name>.csv"

The result of the given <query> will be put into a CSV file with the given name and downloaded from the browser to your machine.

Data can be imported to a SQL Server connection from a file on your machine, or exported and downloaded to you machine.

Import

Import data from a file on your machine into the SQL Server connection.

To import data from a csv file, is the COPY command:

BULK INSERT <table> FROM LOCAL FILE

In the example above, "<table>" should be replaced with the SQL table to import data into. The other parts of the command are required for CSV-formatted files. If your uploaded file uses different termination characters update the query accordingly.

After running the query, Keeper Connection Manager will prompt you to supply the data file. To upload the file, simply drag and drop it from your machine onto the browser window.

Export

Data from the connected PostgreSQL database can be exported to a file on your machine. To do this, use the following query:

 SELECT <query> INTO LOCAL OUTFILE "<name>.csv"

The result of the given <query> will be put into a CSV file with the given name and downloaded from the browser to your machine.

Starting with Keeper Connection Manager version 2.19, customers are required to obtain a license key from Keeper in order to continue the use of the application.

Obtaining a License Key

To obtain a license key, please contact Keeper Support directly at: https://www.keepersecurity.com/support.html

Upon request, Keeper staff will generate your KCM on-prem license key. It can then be accessed directly from the Keeper Admin Console:

To install your license key, follow the steps below:

New Customers

During the installation process, you will be prompted to input the license key.

Existing Customers

If using the Auto Docker Install or Docker Compose Install method, simply update the keeper/guacamole container definition with the license as the value of the KCM_LICENSE environment variable.

Example:

    guacamole:
        image: keeper/guacamole:2
        restart: unless-stopped
        environment:
            ACCEPT_EULA: "Y"
            .
            .
            .
            KCM_LICENSE: "XXXXXXXXXXXXXXXXXXXXXXXXXX"
        volumes:
            - "common-storage:/var/lib/guacamole:rw"

• (Optional) If the license will be present within a file in your container, you may alternatively use the KCM_LICENSE_FILE environment variable to point to that file.

• (Optional) If using the RPM packages, you must provide the license as the sole contents of /etc/guacamole/kcm.license, which must be readable by the guacamole group.

After adding the license key, restarting the container is necessary. If using the Auto Docker Install method, simply run:

sudo ./kcm-setup.run apply

Update Instructions

From the Linux command line, update to the latest installer script using the curl command.

curl -O https://keepersecurity.com/kcm/kcm-setup.run

To update all of the underlying software and Docker containers when using the Docker Automated Install method, run the below commands:

sudo ./kcm-setup.run stop
sudo ./kcm-setup.run upgrade

Select "Y" when prompted.

Once the upgrade is complete, the service is started again automatically after a minute.

If you run into any issues with the upgrade, see our troubleshooting page.

For convenience, Docker images for both MySQL and PostgreSQL are provided which automatically initialize themselves using the Apache Guacamole database schema:

Each of these images:

• Is based off Docker's official images for the same databases, and thus each accepts the same core environment variables.

• Accepts a common set of Guacamole-specific environment variables defining the name to be used for Guacamole's database and the reduced-privilege credentials to be used by Guacamole to execute queries.

• Requires the same ACCEPT_EULA environment variable as the keeper/guacamole and keeper/guacd images.

The images may be used as part of an entirely Dockerized deployment of Apache Guacamole, or separately as an easier method of deploying a functional, pre-initialized, and supported database. When combined with the keeper/guacamole and keeper/guacd images using docker-compose, an entire deployment of Apache Guacamole can be created and managed using a single docker-compose.yml.

Keeper Connection Manager supports multiple authentication mechanisms which can be enabled through installing additional packages.

Authentication Methods

• SAML 2.0

• OpenID Connect

• LDAP

Multi-Factor Authentication

If you wish to enable multi-factor authentication in front of Keeper Connection Manager, you may do so with Duo or TOTP.

• TOTP

• Duo

Google Workspace Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider using Google Workspace.

(1) Login to Google Workspace

Visit the Apps > Web and Mobile Apps screen.

(2) Select "Add App" and select "Add Custom SAML App".

Enter an application name and description. You can also upload a Keeper Connection Manager logo. The image logo is here:

Click Continue.

(3) Download the metadata.xml file

...and then click Continue

(4) Configure the SAML Settings

Update 3 fields: ACS URL, Entity ID and Name ID format.

• The ACS URL needs to start with your Keeper Connection Manager domain followed by "/api/ext/saml/callback".

• The Entity ID is just the Keeper Connection Manager domain.

• The Name ID format must be EMAIL

Click Continue.

(5) Assign group membership (Optional)

You can now assign Group Membership to the Keeper Connection Manager application, which is optional. If you would like to assign a group, make sure that the "App Attribute" is groups (lowercase). Then click FINISH.

(6) Enable Access

After creating the SAML app, it is not yet active for all users. To enable access, click on View details and turn the application ON.

The Google Workspace side of the setup is complete. Note if you change anything, you need to re-download a new metadata.xml file.

OneLogin Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider.

You must have OneLogin developer account.

Configure OneLogin

1. Log in to the OneLogin Dashboard, and click Administration. Then Applications > Add App.

2. Search for SAML, and select SAML Test Connector (IdP).

3. When prompted, change the Display Name of your app. Enter an application name and description. You can also upload a Keeper Connection Manager logo. Click save.

4. Go to the Configuration tab, Update 3 fields: Recipient, ACS (Consumer) URL Validator, and ACS (Consumer) URL with your KCM server URL and /api/ext/saml/callback on the end as shown below.

1. Click on the More Actions dropped-down menu. Select SAML Metadata to download and save the .XML file.

2. Under the Users tab on the top, find the users that need to log in using SSO, click into them and on the applications tab on the left, add the new SAML application to them.

Auto Docker or Docker Compose

When using the docker version of KCM, you can list the multiple LDAP servers in your docker-compose.yml file using the environment variable LDAP_SERVERS in the environment section of the guacamole service, as shown below:

version: "3"
services:
    guacamole:
        image: keeper/guacamole:2
        restart: unless-stopped
        depends_on:
            - guacd
            - db
        environment:
            ACCEPT_EULA: "Y"
            GUACD_HOSTNAME: "guacd"
            LDAP_SERVERS: |
              - hostname: server1.example.net
                user-base-dn: OU=Users,DC=example,DC=net
                username-attribute: sAMAccountName
                search-bind-dn: CN=Guacamole,OU=Services,DC=example,DC=net
                search-bind-password: SomePassword!

              - hostname: server2.example.net
                user-base-dn: OU=Users,DC=example,DC=net
                username-attribute: sAMAccountName
                search-bind-dn: CN=Guacamole,OU=Services,DC=example,DC=net
                search-bind-password: SomePassword! 
                

User Management in Keeper Connection Manager

Keeper Connection Manager offers flexible user management capabilities that allow administrators to control access, apply account restrictions, assign permissions, and configure connection visibility for individual users or groups.

Accessing User Settings

To manage user accounts:

1. Log in to your Keeper Connection Manager instance as an administrator.

2. Navigate to the Settings tab.

3. From here, you can create new users or edit existing ones.

Account Restrictions

When configuring a user account, the following restrictions can be applied:

• Login Disabled: Prevents the user from logging in to the system.

• Password Expired: Forces the user to reset their password at next login.

• Allow Access After: Grants access starting at a specific date and time.

• Do Not Allow Access After: Prevents access after a specific date and time.

• Enable Account After: Activates the user account at a scheduled time.

• Disable Account After: Deactivates the account after a scheduled time.

Keeper Secrets Manager

Individual users can be assigned a specific Keeper Secrets Manager configuration, allowing the user to use credentials from their vault for establishing privileged sessions to any target. See the Multiple Vaults Integration page for more info.

User and Group Permissions

Permissions can be granted at the individual user level or inherited from a user group. Available permissions include:

• Administer System: Full administrative rights over the instance.

• Create New Users: Ability to create and manage user accounts.

• Create New User Groups: Ability to create and assign user groups.

• Create New Connections: Permission to define new connection entries.

• Create New Connection Groups: Ability to group related connections.

• Create New Sharing Profiles: Manage sharing templates and permissions.

• Change Own Password: Allows users to update their own credentials.

Group Assignments and Connection Access

Users can be assigned to one or more groups, inheriting the group’s permissions and restrictions.

In addition, administrators can assign:

• Specific Connections: Restrict the user to a defined set of connections.

• All Connections: Grant access to all available connections in the environment.

Keeper Connection Manager provides flexible user management options that include account restrictions, administrative permissions and connection targets.

Keeper Connection Manager provides access to the functionality of a desktop from within your web browser. The interface is designed to be as seamless and unobtrusive as possible.ogin

Login Screen

Login options and customization.

Home Screen

Selecting connections and user settings.

Launching Connections

Features and functionality of the connection session and the sidebar menu.

Connection Screen

Manage the clipboard, view multiple connections at once, upload or download files, and change input settings within a connection session

Creating Connections

How to create Keeper Connection Manager connections for each supported protocol type

File Transfer

Configure and use Keeper Connection Manager drag-and-drop file transfer

Sharing Connections

Share access to Keeper Connection Manager connections with anyone with an internet browser

Session Recording

How to configure screen and keystroke recording for all session types.

AWS EC2 Discovery

Automatically discover your EC2 instances for dyanamic connections.

Credential Pass-Through

Pass through tokens from the login screen to the target connections.

Dynamic Connections

Launch connections using arbitrary parameters through signed JSON requests.

Custom Branding

Customize the look and feel of the Keeper Connection Manager instance.

About

The login screen is the first screen users see when they access Keeper Connection Manager. Users use a username and password, or SSO credentials to authenticate into the rest of the platform.

Logging In

Username

Users use their username to login to Keeper Connection Manager. This username is set when creating or importing users.

Password

The user's password. Set when creating or importing the user. Passwords can also be reset by users if allowed.

Other Login Methods

See the authentication documentation pages for more information about setting up additional login methods such as LDAP, SAML 2.0, and OpenID Connect as well as information on setting up 2FA

Login Attempt Limits

As of KCM version 2.9.6, KCM can be configured to limit a user's ability to login after multiple consecutive failed login attempts. This blocks brute-force login attacks on KCM instances.

This setting can be removed, and the number of attempts before a user is locked out and how long they are locked for can be configured with the following guacamole properties or environment variables (depending on installation method):

Adding your logo to KCM

1. Download the zip file above and extract everything to a folder.

2. Replace /resources/images/logo.png with your logo.png file.

3. Open /translations/en.json and replace "Custom Title" with your text for the title of the webpage.

4. (Optional) Replace the favicon icons in /resources/images/, bothsmall.png and large.pngwith yours. (you can use the same one for both if needed)

5. From inside the folder, select all of the files and folders and create a new zip file.

1. Make sure that you are viewing file extensions, and change your zip file name and extension to kcm-branding.jar

2. Transfer the kcm-branding.jar file to your KCM server into/etc/kcm-setup/

3. In your docker-compose.yml guacamole section, within environment, add USE_DEFAULT_BRANDING: "N" and in volumes add the following line:

- "/etc/kcm-setup/kcm-branding.jar:/etc/guacamole/extensions/kcm-branding.jar:ro"

1. Run these commands:

sudo ./kcm-setup.run stop
sudo ./kcm-setup.run apply

Complete! Now you will see your logo on your Keeper Connections Manager.

To refresh the favicons press Ctrl/Cmd + F5 for a hard reload.

Keeper is Fanatical About Data Protection

Keeper utilizes best-in-class security with a zero-trust framework and zero-knowledge security architecture to safeguard your infrastructure and mitigate the risk of a data breach.

Overview

Keeper Security, Inc. (KSI) is passionate about protecting its customer's information and infrastructure with Keeper desktop and mobile security software. Millions of consumers and businesses trust Keeper to secure and access remote systems, passwords and private information. Keeper's software is constantly improved and updated to provide our customers with the latest in technology and protection. This page provides an overview of Keeper's security architecture and encryption methodologies.

System Architecture

The Keeper Connection Manager Gateway is a platform that is fully hosted by the customer in any cloud, on-prem or virtual environment. Keeper provides customers with the and method of installation.

The Docker container is made up of several core components including:

• Apache Guacamole web application software

• Apache Guacamole "guacd" protocol service

• NGINX for SSL termination and reverse proxy

• Apache Tomcat services

• MySQL, PostgreSQL or other supported databases

Additional packages that support Enterprise capabilities such as SAML 2.0 / SSO, OpenID Connect, TOTP, Vault Integration and components are provided as part of the package installers or as separate add-on components.

Apache Guacamole™

The engineering team at Keeper Security that built Keeper Connection Manager (formerly Glyptodon) are the inventors and primary maintainers of the open source project. Keeper Security is proud to support the open source community and millions of users who use the Apache Guacamole remote desktop software.

Least Privilege Access

The packages provided by Keeper Connection Manager have been designed to follow best practices with respect to security, particularly with respect to the . This is accomplished through careful delegation of rights through users and groups which are automatically created by the Keeper Connection Manager packages, and through strict file permissions.

Production Configuration

Once ready to deploy Keeper Connection Manager to production, it is critically important that customers configure SSL encryption. You will need to obtain an SSL certificate for your server such that all Keeper Connection Manager traffic is encrypted.

If you have have deployed Keeper Connection Manager using the or method, you may have already configured SSL.

Upgrade Methods

• Customers who deploy the Auto Docker Install version can use the .

• Customers who deploy the Docker Compose Install version can use the .

Compliance & Audits

Certified SOC 2 Compliant

Customer vault records are protected using stringent and tightly monitored internal control practices. Keeper is certified as SOC 2 Type 2 compliant in accordance with the AICPA Service Organization Control framework. SOC 2 certification helps ensure that your vault is kept secure through the implementation of standardized controls as defined in the AICPA Trust Service Principles framework.

ISO 27001 Certified (Information Security Management System)

Keeper Security is ISO 27001 certified, covering the Keeper Security Information Management System which supports the Keeper Enterprise Platform. Keeper's ISO 27001 certification is scoped to include the management and operation of the digital vault and cloud services, software and application development, and protection of digital assets for the digital vault and cloud services.

GDPR Compliance

Keeper is GDPR compliant and we are committed to ensuring our business processes and products continue to maintain compliance for our customers in the European Union. to learn more about Keeper's GDPR compliance and download data processing agreements.

Protection of Patient Medical Data

Keeper software is compliant with global, medical data protection standards covering, without limitation, HIPAA (Health Insurance Portability and Accountability Act) and DPA (Data Protection Act).

HIPAA Compliance and Business Associate Agreements

Keeper is a SOC2-certified and ISO 27001-certified zero-knowledge security platform that is HIPAA compliant. Strict adherence and controls covering privacy, confidentiality, integrity and availability are maintained. With this security architecture, Keeper cannot decrypt, view or access any information, including ePHI, stored in a user’s Keeper Vault. For the foregoing reasons, Keeper is not a Business Associate as defined in the Health Insurance Portability and Accountability Act (HIPAA), and therefore, is not subject to a Business Associate Agreement.

To learn more about the additional benefits for healthcare providers and health insurance companies, please read our and visit our .

Penetration Testing

Keeper performs quarterly pen testing with 3rd party experts including and . In addition, Keeper works with independent security researchers who test against all of our products and systems through our .

Third-Party Security Scanning & Penetration Tests

Keeper Security environments are tested daily by TrustedSite to ensure that the Keeper web application and KSI's Cloud Security Vault are secure from known remote exploits, vulnerabilities and denial-of-service attacks. A comprehensive external security scan is conducted monthly on the Keeper websites, Keeper web application, and Keeper Cloud Security Vault by TrustedSite. Keeper staff periodically initiate on-demand external scans.

Payment Processing and PCI Compliance

Keeper Security uses PayPal and Stripe for securely processing credit and debit card payments through the KSI payment website. PayPal and Stripe are PCI-DSS compliant transaction processing solutions. Keeper Security is certified PCI-DSS compliant.

EU-US Privacy Shield

The Keeper web client, Android App, Windows Phone App, iPhone/iPad App and browser extensions have been certified Privacy Shield compliant with the U.S. Department of Commerce's EU-U.S. Privacy Shield program, meeting the European Commission's Directive on Data Protection. For more information about the U.S. Department of Commerce U.S. Privacy Shield program, see

FIPS 140-2 Validated

Keeper utilizes FIPS 140-2 validated encryption modules to address rigorous government and public sector security requirements. Keeper’s encryption has been certified by the NIST CMVP and validated to the FIPS 140 standard by accredited third party laboratories. Keeper has been issued under the NIST CMVP. For the best FIPS experience use KCM version 2.9.6+ for improvements including:

• Improved FIPS compliance support for SSH and RDP connections

• Better log messaging when a compliant connection cannot be made

U.S. Department of Commerce Export Licensed Under EAR

Keeper is certified by the U.S. Department of Commerce Bureau of Industry and Security under Export Commodity Classification Control Number 5D992, in compliance with Export Administration Regulations (EAR). For more information about EAR:

24x7 Remote Monitoring

Keeper is monitored 24x7x365 by a global third-party monitoring network to ensure that our website and Cloud Security Vault are available worldwide. If you have any questions regarding this security disclosure, please .

Phishing or Spoofed Emails

If you receive an email purporting to be sent from KSI and you are unsure if it is legitimate, it may be a “phishing email” where the sender's email address is forged or “spoofed”. In that case, an email may contain links to a website that looks like KeeperSecurity.com but is not our site. The website may ask you for your Keeper Security master password or try to install unwanted software on your computer in an attempt to steal your personal information or access your computer. Other emails contain links that may redirect you to other potentially dangerous web sites. The message may also include attachments, which typically contain unwanted software called "malware." If you are unsure about an email received in your inbox, you should delete it without clicking any links or opening any attachments. If you wish to report an email purporting to be from KSI that you believe is a forgery or you have other security concerns involving other matters with KSI, please .

Hosting Infrastructure Certified to the Strictest Industry Standards

Keeper Connection Manager is hosted by the customer. The Keeper website and cloud storage runs on secure Amazon Web Services (AWS) cloud computing infrastructure. The AWS cloud infrastructure which hosts Keeper's system architecture has been certified to meet the following third-party attestations, reports and certifications:

• SOC 1 / SSAE 16 / ISAE 3402 (SAS70)

• SOC 2

• SOC 3

• PCI DSS Level 1

• ISO 27001, 27017 and 27018

• FedRamp

• DIACAP

• FISMA

• ITAC

• FIPS 140-2

• CSA

• MPAA

Vulnerability Reporting and Bug Bounty Program

Keeper Security is committed to the industry best practice of responsible disclosure of potential security issues. We take your security and privacy seriously and, we are committed to protecting our customers’ privacy and personal data. KSI’s mission is to build world’s most secure and innovative security apps, and we believe that bug reports from the worldwide community of security researchers is a valuable component to ensuring the security of KSI’s products and services.

Keeping our users secure is core to our values as an organization. We value the input of good-faith researchers and believe that an ongoing relationship with the cybersecurity community helps us ensure their security and privacy, and makes the Internet a more secure place. This includes encouraging responsible security testing and disclosure of security vulnerabilities.

The Keeper Connection Manager team actively monitors the upstream Apache Guacamole project for newly-disclosed security vulnerabilities, and has procedures in place for releasing security updates outside the normal release cycle. Should a vulnerability be found in Guacamole, the patch for that vulnerability will made be immediately available through the Keeper Connection Manager repository, and can be applied automatically using the upgrade process based on your installation method.

Guidelines

Keeper's Vulnerability Disclosure Policy sets out expectations when working with good-faith researchers, as well as what you can expect from us.

If security testing and reporting is done within the guidelines of this policy, we:

• Consider it to be authorized in accordance with Computer Fraud and Abuse Act,

• Consider it exempt from DMCA, and will not bring a claim against you for bypassing any security or technology controls,

• Consider it legal, and will not pursue or support any legal action related to this program against you,

• Will work with you to understand and resolve the issue quickly, and

• Will recognize your contributions publicly if you are the first to report the issue and we make a code or configuration change based on the issue.

If at any time you are concerned or uncertain about testing in a way that is consistent with the Guidelines and Scope of this policy, please contact us at before proceeding.

To encourage good-faith security testing and disclosure of discovered vulnerabilities, we ask that you:

• Avoid violating privacy, harming user experience, disrupting production or corporate systems, and/or destroying data,

• Perform research only within the scope set out by the Bugcrowd vulnerability disclosure program linked below, and respect systems and activities which are out-of-scope,

• Contact us immediately at if you encounter any user data during testing, and

• You give us reasonable time to analyze, confirm and resolve the reported issue before publicly disclosing any vulnerability finding.

Submitting a Report

Keeper has partnered with Bugcrowd to manage our vulnerability disclosure program.

Please submit reports through .

Additional Information

Keeper Security utilizes best-in-class security with a Zero-Knowledge security architecture and Zero-Trust framework. Additional technical documentation about Keeper's Zero-Knowledge encryption model can be found at the links below:

Keeper is SOC 2 Type 2, ISO27001 certified, FedRAMP Authorized. Customers may request access to our certification reports, 3rd party penetration reports and technical architecture documentation with a signed mutual NDA.

Supported Operating Systems:

The recommended method to install Keeper Connection Manager is via the. This removes any operating system, system pre-requisites and other requirements. If the underlying system supports a current version of Docker, the container is fully supported.

Supported KCM Versions:

• Glyptodon 1.x - Full support for 2 years after any major release

• Glyptodon 2.x - Full support for 2 years after any major release

• Keeper Connection Manager 2.x - Full support for 2 years after any major release

Minimum system specs for production deployment:

Minimum host recommendations:

For anything over 200 concurrent sessions, we have several options, and it may be best to talk through this with our sales engineering team to find the right solution based on your needs and connection types.

Disk space requirements

A single session recording can vary based on the content being shown. This is affected by the type of connection. GUIs typically have higher recording sizes versus CLI connections like SSH, which can be quite small.

Network throughput for concurrent connections

Network throughput also varies based on activity, type of session and connection settings. From actual examples, we've found that for a system running about 100 concurrent sessions, network traffic varies between 9Mbit/s and 15Mbit/s for all 100 connections. Each connection would be on average 1/100th of the 15Mbit value.

In the same above scenario with 100 connections, we would expect about 15gb total traffic per hour on the network adaptor. Comparing inbound and outbound traffic, just over 90% of the traffic is outbound from the server to the clients.

Preparing for Installation

Keeper Connection Manager will serve your secure "jumpbox" and you'll use your web browser to access it. First, choose a URL that you'd like to use for accessing KCM.

You'll need the following:

1. A designated machine (usually a Linux VM) with a static IP address 2. Choose a fully-qualified domain name (FQDN) 3. Your DNS record set to point your FQDN to the IP of your designated machine 4. An SSL certificate

No cert? Don't worry, you can:

1. Start by choosing "use a self-signed certificate" (for testing)

2. Choose "Let's Encrypt" to generate a 90 day auto-renewing cert (requires 80 and 443 open)

3. Bring your own cert during setup or add it in later using the reconfigure command

You can either bring your own SSL certificate, or you can generate one during the installation by choosing the option for . If planning to use Let's Encrypt, make sure that ports 80 and 443 are open to the internet during the installation.

To prepare for installation:

1. Create/Identify and establish root access to the server that will run the Keeper Connection Manager gateway

2. Decide if you want your KCM gateway to be public-facing (assign public IP), or internal-only (assign private IP)

3. Add internal/external DNS A Record (or AAAA record) to point your domain to your KCM server's IP address

4. Make sure that ports 80 and 443 are open to the public if you plan to use Let's Encrypt.

Check your firewall to make sure that traffic can flow between your server and Docker. Some domains that it will need to reach include docker.com, docker.io and others.

Platform-specific Setup

Virtual Machines with Depletable Entropy Bits

To check your that your Linux system's entropy level is at least 1000, use the command:

To increase the speed of entropy generation, you can install the haveged service to ensure that the environment can efficiently create secure random numbers.

RHEL / Rocky Linux 8 (and derivatives)

If Podman is installed, you must run the following two commands before installation:

PingIdentity Configuration

1. Login as an Administrator for PingIdentity. From the PingIdentity menu, click Applications > Add Application

2. Give the Application a name such as "KCM," select SAML and Save.

1. Next, you'll encounter the SAML configuration. Select Manually Enter, then add the URL of your KCM server to the ACS URLs box as follows: https://<YOUR DOMAIN>/api/ext/saml/callback

2. Then add the URL of your KCM server to the Entity ID box as follows: https://<YOUR DOMAIN> and press Save.

1. Next, Edit Attribute Mappings. Since saml_subject is immutable, leave it as is. Add an attribute named EMAIL that has a Mapping of Username, and an attribute named groups that has a Mapping of Group Names.

1. Then Edit Configuration and scroll down to SUBJECT NAMEID FORMAT and select the option urn:oasis:names:to:SAML:1.1:nameid-format:emailAddress. And hit Save.

1. On the Overview section, verify that Access is for All Users (or the group you specified). Leave the Signon URL as the Default Signon Page. And Enable the Application by clicking the slider at the top of the application.

1. Download the Metadata file from the Configuration tab, and ensure that it is named to metadata.xml.

1. Ensure that all users are added with a Username that matches the email address of a user in your Keeper Connection Manager. **When you add users to Keeper Connection Manager use the matching email address, but leave the password blank.

Video Example

In an environment where KCM users may be automatically created from an SSO system, such as SAML or OpenID or PIV/CAC, administrators may wish to more tightly control whether those users are allows to use KCM. To facilitate this, KCM provides administrators an approve/deny workflow to decide whether an individual user should be allowed to authenticate with KCM using that SSO method.

Configuring the KCM user creation workflow

To require approval for users signing in with a particular authentication method, use the require-account-approval property (or, for Docker, the REQUIRE_ACCOUNT_APPROVAL environment variable). This property accepts a comma-separated list of the names of all authentication methods that should require administrator approval. KCM supports the following authentication types:

For example, to require administrator approval for SAML and LDAP, you would specify:

The following examples shows a docker.yaml file with the SAML Authentication method enabled:

Once you have successfully configured and setup the authentication method, the corresponding SSO login method will be displayed on the login screen of the application. In the following image, the instance has been configured to use the saml authentication method:

Users with at least one authentication method that needs to be approved or denied will be shown in the user list with a “Pending Login Request” badge next to their username:

Administrators can approve/deny access for that user via that authentication method by editing the user account in KCM:

Overview

Keeper Secrets Manager integrates with Keeper Connection Manager to provide dynamic retrieval of credentials that are stored in the Keeper Vault. This integration allows the Admin to provide privileged sessions with credentials that are stored and protected in the encrypted Keeper vault.

Using , Keeper Connection Manager can securely access RDP, SSH, MySQL, VNC and other credentials from the Keeper Vault. With this integration, connection credentials are protected in the encrypted Keeper vault and never stored in plain text. In the connection properties, you can simply reference the hostname or specified Vault record identifier and Keeper will pull the necessary credentials at runtime. Access credentials are never exposed to the user.

Integration Features

• Securely store connection secrets like SSH keys and Admin passwords in your Keeper Vault

• Dynamically pull credentials from Keeper on-demand when establishing connections

• Eliminate hard-coded credentials and secrets

• Securely store guacamole properties in the Keeper Vault such as MySQL passwords

For a cloud-based solution that is fully integrated into the Keeper Vault, make sure to check out the new KeeperPAM product. KeeperPAM is a next-gen privileged access management solution that secures and manages access to critical resources, including servers, web apps, databases and workloads.

KeeperPAM consolidates enterprise password management, secrets management, connection management, zero-trust network access, remote browser isolation and an cloud-based access control plane in one unified product. Customers who purchase KeeperPAM may also use Keeper Connection Manager for self-hosted use cases.

To learn more about KeeperPAM or sign up for a trial:

For a quick animated demo, click Play below:

Overview

The Auto Docker Method installs Docker and 4 containers (if you selected all options) which start up automatically after the installer completes:

• Database (MySQL or PostgreSQL depending on selection)

• Guacamole (Tomcat)

• Guacd

• SSL (NGINX)

The installer also creates a docker-compose.yml file that can be found in the filesystem:

/etc/kcm-setup/docker-compose.yml

This Docker Compose file is the configuration file which manages the multi-docker container system. If you need to make further changes to the environment, you can modify this file and restart the docker services using the kcm-setup.run script or by directly using Docker functionality.

Managing the Service

When using the Docker Simple Install method, the kcm-setup.run script can be used to manage the entire service and the underlying docker containers. The purpose of this script is to make management of the Keeper Connection Manager platform very simple.

Usage:

sudo ./kcm-setup.run [OPTIONS] [COMMAND] [ARG...]

Install, maintain, or uninstall Keeper Connection Manager automatically.

Shared Volume

When using the Auto Docker Install method, a shared volume is automatically added to store file transfers and session recordings. The created volumes are located at /var/lib/guacamole/ which contains the drives and recordings.

Keeper Connection Manager is installed as a gateway in your cloud, virtual or on-prem environment. There are several methods of deployment, and installation only takes a few minutes.

Install Methods

For Auto Docker Install method, we support any version of Linux.

For Docker Compose Install, Keeper Connection Manager will run on any platform that supports Docker or Docker Desktop, including all versions of Windows and Linux.

Customers who directly installed via Linux RPMs can refer to our advanced linux install docs.

Configure DNS

In a production deployment, select a domain name to access the endpoint, e.g. kcm.company.com and create a new DNS record to map it to your server's public IP. You will be prompted to enter the domain name during the installation.

Ensure that the DNS record maps to your server's public IP address, or an IP that is internally available to your end-users over HTTPS port 443.

Decide on Let's Encrypt or Existing Cert

Keeper Connection Manager requires an SSL certificate for installation. Decide before starting installation if you want to use Let'sEncrypt, or if you have your own certificate file and private key.

LetsEncrypt is a certificate authority that is free, automated, open, and is also the world's largest CA. During installation using the Auto Docker Install method, Keeper Connection Manager will provide an option to utilize LetsEncrypt (option 1), which will generate a 3-month trusted certificate for your domain.

However, if you would like to use your own certificate obtained by a different CA, you can do so by choosing (option 2) during the installation prompt.

If you would like to use your own certificate, Keeper Connection Manager installation will prompt you to enter the full path and file name first for your .crt file, and next for your .pem file. Make sure to transfer these files to your server before beginning installation.

Select an Install Method

Keeper Connection Manager can be installed using one of the following methods.

Option 1: Auto Docker Install

An automated installer script is available for Linux which performs several of the Docker setup steps, such as generating a Docker Compose file, setting up SSL certificates and other options.

Go to: Installation Instructions for Auto Docker Install

This method is recommended for users who are new to Docker and prefer Linux.

Option 2: Docker Compose Install

This advanced and customized Docker install for Keeper Connection Manager provides the Docker Compose file to deploy in any Docker environment with support for additional packages such as SSO, LDAP, TOTP and more.

Go to: Installation Instructions for Docker Compose Install

This method is required for Windows and recommended for users who are familiar with Docker.

Azure Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider using Microsoft Azure.

(1) In Azure, go to Enterprise Applications and Create a new application.

(2) Give the Enterprise Application a name, and then select "non-gallery" application.

(3) Set up Single Sign On with SAML.

(4) Configure for SAML

(5) Set up the SAML properties to point Azure to your Keeper Connection Manager installation URL:

(6) To support Azure Group to Keeper Connection Manager User Group mappings, you can add a Group claim by editing the Attributes & Claims then adding a Group Claim.

When prompted, you can decide whether the group claim is always sent, or only for specific groups or assigned users. If unsure, choose all groups.

If you would like to automatically map group assignments in the identity provider to Keeper Connection Manager Groups, ensure that the saml-group-attribute parameter is defined to match the Identity Provider Group Attribute. The name of the Group in Keeper Connection Manager needs to match this identifier exactly in order for the mapping to work.

(7) Assign users and/or groups to the Keeper Connection Manager application, as you would normally do with any SAML connected app.

(8) Copy the URL of the App Federation Metadata and paste it into the prompt on your KCM server.

(9) Add the KCM Logo

From the "Properties" screen of the Enterprise Application, upload the KCM logo. The file can be downloaded below.

Here's how the logo will look:

Go to your Oracle Admin Console and navigate to the Identity Domains Overview page, then select Applications as depicted above.

Click on Add Application.

Select SAML as the application type.

Apply the appropriate settings to the Application Information as needed for your security posture. Click on Edit SSO Configuration. Download the Metadata and rename the file to metadata.xml. Set the Entity ID to the URL of your Connection Manager server. For example: https://kcm.somedomain.com. For the Assertion Consumer URL, add /api/ext/saml/callback to the end of the domain URL. For example: https://kcm.somedomain.com/api/ext/saml/callback. Next, set the Name ID Format to Email Address and the Name ID Value to Primary Email. Leave the Signed SSO setting as Assertion. Uncheck the box to Include Signing Certificate in Signature, and leave the Signature Hashing Algorithm as SHA-256.

Assign attributes for email as listed above mapped to the value User Name. Add another attribute for groups with the settings of Type Value Group Membership and a Condition of All groups.

Assign users and groups as appropriate to your SAML application. You'll need to assign at least one user for testing purposes.

Connection Manager Server Configuration

Upload the metadata.xml file to your KCM server and move it into the directory /etc/kcm-setup.

Run the reconfigure command after production hours on your Connection Manager server.

Say Y to the option when presented to setup SAML support.

Select 1 for Local Metadata file. Then input the path of your metadata file as /etc/kcm-setup/metadata.xml and press enter. Answer N to Does your SAML IDP require signed requests? Input your SAML entity ID as the URL of your Connection Manager instance. For example: https://kcm.somedomain.com. Then enter groups as the SAML group attribute.

Choose which setting best applies to your security posture with regard to the default authentication method. If you want Just-In-Time provisioning of users, then answer Y to Would you like user accounts to be automatically created for each successful login?

Click the SAML link to authenticate to the main sign on page.

Your user email address should display in the top right corner after authenticating.

Overview

Keeper Connection Manager supports on-demand, shared, and collaborative access to sessions through a simple, shareable URL. This enables teams to easily grant access to server or application sessions—even to users without a Keeper Connection Manager account.

Key use cases include:

• Training or remote assistance with monitored access to a server or web app

• Collaborative sessions with multiple users in view-only or full-control mode

• Granting temporary access without consuming a user license

To enable this feature:

1. Create a Sharing Profile on the desired connection

2. Generate and distribute a Share URL

Create a Sharing Profile

The first step to connection sharing is to create a Sharing Profile. This needs to be made for each connection that will be shared.

To create a sharing profile, head to the "Connection" tab of the Settings menu and click the arrow next to the connection you would like to add a sharing profile to.

You will see a list of all the sharing profiles created for this connection, click "New Sharing Profile" to create a new profile, or click an existing sharing profile to edit it.

The Sharing Profile form will open. Fill in the name and options to configure the sharing profile.

Click "Save" to create the sharing profile.

Generate and distribute a Share URL

To initiate a connection share, from within a connection session first open the connection menu using Ctrl+Shift+Win (Ctrl+Shift+Cmd for Mac). When at least one sharing profile exists for the connection, the "Sharing" menu will appear next to the user's name.

Click "Sharing" to see a list of the sharing profiles for this connection.

Select which profile to use and click it to create a sharing URL which can be shared to give anyone access to this connection session.

When someone without an account in this Keeper Connection Manager system connections to the session, they will have full access to the connection (unless "Read Only" was selected in the sharing profile settings) however they will not have a user menu, or sharing menu.

Join & Leave Notifications for Shared Connections

When joining a shared connection via a share link or the “Active Sessions” tab of the admin/settings area, the original user of that connection will now receive a notification in the upper-right corner of the connection view showing that a user has joined:

If the user that joined was authenticated with KCM at the time, the original user will also be able to see that user’s username. A similar notification will appear whenever a user leaves the connection.

An indicator showing the number of other users currently sharing the connection will remain visible to the original user for as long as there are other users on the connection. If the user hovers the mouse over the indicator, a tooltip appears showing the usernames of all other users and how many concurrent connections they have to the current shared connection:

If the user sharing the session has no associated username (common for share links), the user appears as “Anonymous”:

Config Parameter Protection

The Keeper Vault can be utilized to protect and store configuration secrets that would normally be hard-coded into the guacamole.properties or Docker Compose file.

Auto Docker Install Method

If you installed Keeper Connection Manager using the Auto Docker Install method, configuration secrets are protected in the auto-generated Docker Compose file.

As root, edit the /etc/kcm-setup/docker-compose.yml file.

For each configuration secret that you want to protect, you can replace the entry with a direct lookup in the Keeper vault. A good example of this is replacing the hard-coded MySQL database password with a vault record.

BEFORE:

MYSQL_HOSTNAME: "db"
MYSQL_DATABASE: "guacamole_db"
MYSQL_USERNAME: "guacamole_user"
MYSQL_PASSWORD: "your_mysql_database_password"

AFTER:

MYSQL_HOSTNAME: "db"
MYSQL_DATABASE: "guacamole_db"
MYSQL_USERNAME: "guacamole_user"
MYSQL_PASSWORD_KSM_SECRET: keeper://2ZlOFQAYi4DubJWBtSbRxw/field/password

The token syntax is using Keeper Notation. The name of the parameter must follow the format of *_KSM_SECRET. In this example, the MySQL database password is pulled directly from a Keeper record in the Shared Folder.

The value of each *_KSM_SECRET variable should be the Keeper notation of the secret that should be used to pull the necessary configuration value. For example, if SOME_VARIABLE_KSM_SECRET were set to valid Keeper notation, then the value of the Guacamole property normally associated with SOME_VARIABLE will be pulled from that secret in KSM.

Once the file changes have been saved, update the containers:

$ sudo ./kcm-setup.run upgrade

Docker Compose Install Method

Edit your docker-compose.yml file.

For each configuration secret that you want to protect, you can replace the entry with a direct lookup in the Keeper vault. A good example of this is replacing the hard-coded MySQL database password with a vault record:

MYSQL_HOSTNAME: "db"
MYSQL_DATABASE: "guacamole_db"
MYSQL_USERNAME: "guacamole_user"
MYSQL_PASSWORD_KSM_SECRET: keeper://2ZlOFQAYi4DubJWBtSbRxw/field/password

The token syntax is using Keeper Notation. In this example, the MySQL database password is pulled directly from a Keeper record in the Shared Folder as seen below:

The value of each *_KSM_SECRET variable should be the Keeper notation of the secret that should be used to pull the necessary configuration value. For example, if SOME_VARIABLE_KSM_SECRET were set to valid Keeper notation, then the value of the Guacamole property normally associated with SOME_VARIABLE will be pulled from that secret in KSM.

Once the file changes have been saved, update the containers:

sudo su
docker-compose up -d

Other configuration options

In docker installations, the parameter ADDITIONAL_GUACAMOLE_PROPERTIES_KSM can be used to move parameters from the guacamole.properties file into guacamole.properties.ksm.

Overview

Auto Docker Install is Keeper's recommended installation method.

Make sure to read the section first.

The Auto Docker Install method creates a standard Keeper Connection Manager environment using a script that is easy to run. This method does not restrict any features and you can still utilize this installation with advanced control at a later time.

If you are already familiar with Docker, you may choose to use the method.

Licensing

Before installing KCM, please ensure you have a valid license key. Without a valid license key, users and administrators will be unable to use KCM after the update is applied

For more info, visit this .

Installation

(1) Download the Installer

From the linux command line, download the installer script using the curl command.

(2) Add the execute permission to the Installer

(3) Run the Installer as root

The next question asks if you already have SSL termination available. If unsure, select N for no.

At the next prompt, enter your FQDN, even if it is internal. This is where users will access KCM in their browser.

Then, choose an option for SSL. A self-signed certificate (option 3) is okay for testing. After testing is complete, make sure to put a proper SSL certificate in place.

Secrets Manager Integration (optional)

The next prompt will be to choose your database, and then it will prompt for "Your one-time access token or base64 configuration". This value is (a tab in your vault). If this doesn't apply to you, just press enter. You can always add it later, too.

Set up SSO Login (optional)

Next up is SAML. You can choose "no" to skip it (you can come back and set it up later), or you can choose "yes" to set up SSO now.

Save the credentials and URL in your Vault

After installation is completed, an admin login and password is created for you. Make sure to store this in your Keeper vault, as it's not provided again later.

Navigate to the URL in your Browser

Now that the installation is complete, simply go to the URL/hostname that you designated. You'll be able to login as the guacadmin default user with the credentials provided at the completion of the installation.

🎉 Installation Complete!

Now that your Keeper Connection Manager instance is running, you can login as guacadmin and start setting up some connections. Need to import connections in bulk?

The next section of this documentation reviews the process of managing, upgrading and adding packages to the Docker Compose environment.

Image: keeper/guacd

keeper/guacd is a Dockerized deployment of guacd, the Apache Guacamole proxy daemon, with support for VNC, RDP, SSH, K8s, MySQL, PostgreSQL, SQL Server and telnet. It is normally used to provide a guacd instance for a container using the image.

Starting a guacd instance

To start a guacd instance which listens on TCP port 4822:

where some-guacd is the name you wish to assign to your container.

Viewing the guacd logs

The guacd logs are useful if debugging unexpected behavior of the remote desktop or failure to connect, as it is guacd that handles protocol-specific communication. To view the guacd logs:

By default, these logs will show messages only at the "info" level or above. This can be overridden when the container is created using the LOG_LEVEL environment variable.

Environment variables

ACCEPT_EULA

The ACCEPT_EULA environment variable must be set to "Y" to indicate your acceptance of the Keeper Connection Manager EULA. This Docker image may not be used except under the terms of the .

CA_CERTIFICATES

This variable is optional and specifies the contents of one or more certificates used by your internal certificate authority (CA), in PEM form. When specified, SSL/TLS connections to other servers will be verified against these certificates, including connections to RDP servers and Remote Browser Isolation sessions that use SSL/TLS.

Below is an example guacd section of docker-compose.yml with 2 certificates:

GUACD_UID

This variable is optional and specifies the numeric UID which should be assigned to the user that the guacd service runs as. If omitted, the guacd service will run with the UID of the reduced-privilege user created by the Keeper Connection Manager package for guacd.

This is mainly useful if guacd will need to write to a volume mount whose file permissions may not match those of the keeper/guacd Docker image.

GUACD_GID

This variable is optional and specifies the numeric GID which should be assigned to the group that the guacd service runs as. If omitted, the guacd service will run with the GID of the reduced-privilege group created by the Keeper Connection Manager package for guacd.

This is mainly useful if guacd will need to write to a volume mount whose file permissions may not match those of the keeper/guacd Docker image.

LOG_LEVEL

This variable is optional and specifies the lowest level of log message that should be displayed. In order of increasing verbosity, valid values are: "error", "warning", "info", "debug", "trace".

The default log level is "info".

AUTOFILL_RULES

This variable is optional and specifies the full contents of the /etc/guacamole/autofill-rules.yml file that can be used to configure autofill of username/password in the protocol.

This page provides details on how to create an SSL certificate for use with the Keeper Connection Manager service.

Generate and Prepare the SSL Certificate

The process of generating an SSL certificate varies depending on the provider, but the general flow is documented here.

(1) On your local workstation, Generate a private key

(2) Generate a CSR, making sure to use the hostname which you plan to use for KCM. In this case, we will be using demo3.kcmdemo.com. The important item here is that the Common Name matches exactly to the domain.

(3) Purchase an SSL certificate and Submit the CSR to your SSL certificate provider.

If you don't have a provider already, a good site is:

Create a certificate for a domain that is specific for this KCM instance, e.g. demo3.kcmdemo.com. The SSL certificate provider will deliver you a zip file that contains a signed certificate (.crt file) and intermediate CA cert.

(4) After the certificate has been issued, combine the certificate (.crt) and bundle (bundle.crt) into a single file that is PEM-encoded.

The file needs to be formatted like this:

Note that a newline exists after each "END CERTIFICATE" line. KCM will reject a malformed certificate.

The private key file will be PEM-encoded, formatted like this:

(5) Transfer the 2 files to the KCM server

Copy the files to a location in the server which is running Keeper Connection Manager.

If you are using the Auto Docker install method of Keeper Connection Manager, a good place to put the files is in /etc/kcm-setup. Make sure to set the permissions appropriately, e.g.:

(6) Update the docker-compose.yml file with the SSL cert

Using your preferred editor, update the Docker Compose file. If you used the Auto Docker install method of KCM, the file will be located in /etc/kcm-setup/docker-compose.yml. The section to edit is below:

Make sure to edit the SSL_HOSTNAME and volume mount paths and filenames.

To restart the service with the new certificate:

Annual Renewal

Multiple Hostnames/Configurations for SSL Termination

The keeper/guacamole-ssl-nginx image is specifically intended to provide SSL termination for the Guacamole image provided by Keeper for KCM. Historically, this image supported only a single hostname and configuration:

As of KCM 2.12.0, the keeper/guacamole-ssl-nginx image can be used with multiple hostnames and configurations via a special SERVERS environment variable that accepts YAML (or JSON).

The SERVERS variable must contain a YAML (or JSON) array of objects, where each object contains the name/value pairs of environment variables that should apply to that additional configuration. Any variable that is not specified is inherited from the top-level environment. For example:

The above configuration would result in an NGINX instance that handles both example.net and *.example.net hostnames equivalently. Both will get their own self-signed certificates because SELF_SIGNED is set to Y.

A more complex example:

The above configuration would result in an NGINX instance that generates and uses a self-signed certificate for *.example.net, but obtains a certificate for example.net from Let’s Encrypt.

IMPORTANT: The value of SERVERS must be a string, hence the | symbol within the above examples. If this symbol is omitted, then the YAML that follows is parsed as an object, and validation of the docker-compose.yml will fail, as all Docker environment variables must be strings.

NOTE: NGINX will use the first server as the default for any request that does not match any configured hostname. If any server declared in SERVERS should have this behavior, it must be the first server listed.

The values of connection parameters can contain "tokens" which will be dynamically replaced by Keeper Connection Manager when used. These tokens allow the values of connection parameters to vary dynamically by the user using the connection, and provide a simple means of forwarding authentication information without storing that information in the connection configuration itself, so long as the remote desktop connection uses the same credentials as Keeper Connection Manager.

Common uses for these tokens include:

• Automatically authenticating users with their remote desktops by. This is typically useful when both Keeper Connection Manager and the remote desktops authenticate against the same, central authority, such as.

• Providing remote desktops with, as may be required for licensing, auditing, or logging.

• Automatically organizing session recordings using

Each token is of the form ${TOKEN_NAME}, where TOKEN_NAME is some descriptive name for the value the token represents. Tokens with no corresponding value will never be replaced, but should you need such text within your connection parameters, and wish to guarantee that this text will not be replaced with a token value, you can escape the token by adding an additional leading "$", as in "$${TOKEN_NAME}".

Username/password pass-through

When a user authenticates with Keeper Connection Manager, the credentials that they used may be automatically passed through to their connections using the "${GUAC_USERNAME}" and "${GUAC_PASSWORD}" tokens. These may be specified within any connection parameters, including the parameters which specify the username and password to be used to connect to the remote desktop, thus allowing the administrator to explicitly define how and whether user credentials are passed through. Unless these tokens are specified by the administrator, no such pass-through will take place.

Client hostname/address information

The hostname (if known) or IP address of the machine that the current Keeper user is connecting from may be included within connection parameters using the "${GUAC_CLIENT_HOSTNAME}" and "${GUAC_CLIENT_ADDRESS}" tokens respectively. Note that the client address may not be the true address of the user if they are connecting through one or more proxies, or if they are connecting through a VPN, and there may be no associated hostname for that address.

Current date and time

Timestamps representing when the user started the connection may be included within connection parameters using the "${GUAC_DATE}" and "${GUAC_TIME}" tokens. Each of these tokens are replaced by values that consist only of digits. It is common to use these tokens within the parameter specifying the name of the session recording to be created, perhaps together with the "${GUAC_USERNAME}" token, to allow recordings to be given reasonably unique names and to be organized automatically.

For example, if connection were configured to record sessions to files names "${GUAC_USERNAME}-${GUAC_DATE}-${GUAC_TIME}.guac", and a user named "someuser" connected to that connection on January 1st, 2020, at exactly midnight, the session recording created would be named "someuser-20200101-000000.guac".

Extension API Overview

Keeper Connection Manager is designed to be integrated with third-party systems and applications using the Extension API, which allows arbitrary systems to serve as methods of authentication and as data sources.

The Extension API was used to implement the authentication mechanisms supported by Keeper Connection Manager and Apache Guacamole out-of-the-box. For Keeper Connection Manager 2.x, regardless of any updates, the extension API is compatible with upstream Apache Guacamole 1.0.0 through 1.3.0.

Example Project

We have published an example custom extension project which can be used to inject arbitrary parameter tokens when a user initiates a connection.

The example is published here:

Additional Documentation

• (referenced by parts of the extension API)

If you are not sure where to begin with integrating Keeper Connection Manager, or are having difficulties with your existing integration,

As of KCM version 2.9.6, KCM can be configured to limit a user's ability to login after multiple consecutive failed login attempts. This blocks brute-force login attacks on KCM instances.

Use the following properties to change the login attempt settings

Keeper Connection Manager provides support for LDAP authentication.

Docker Environmental Variables

The image keeper/guacamole can be modified to support LDAP using environmental variables. See the LDAP_* variables defined in the documentation.

Auto Docker and Docker Compose Install Method

If you installed Keeper Connection Manager using the Docker Install method, this does not come preconfigured with LDAP support. The instructions for activating LDAP are below:

(1) On the local instance, stop the containers.

Auto Docker Install:

sudo ./kcm-setup.run stop

Docker Compose Install:

cd /path/to/docker-compose.yml
docker-compose stop

(2) Edit the docker-compose file

Using the simple or custom docker method requires modification of docker-compose.yml file to add LDAP support. As root, edit your docker-compose.yml file and find the "guacamole" section.

    guacamole:
        image: keeper/guacamole:2
        environment:
            ACCEPT_EULA: "Y"
            GUACD_HOSTNAME: "guacd"
            MYSQL_HOSTNAME: "db"
            MYSQL_DATABASE: "guacamole_db"
            MYSQL_USERNAME: "guacamole_user"
            MYSQL_PASSWORD: "xxxxxxx"
            
            # LDAP Connection
            LDAP_HOSTNAME: "localhost"
            LDAP_PORT: 389
            LDAP_ENCRYPTION_METHOD: "none"
            
            # Mapping Guacamole usernames to LDAP DN’s
            LDAP_USER_BASE_DN: "ou=people,dc=example,dc=net"
            
            ## Optional Settings ##
            LDAP_USERNAME_ATTRIBUTE: "sAMAccountName"
            
            # Indirect Username Mapping
            LDAP_SEARCH_BIND_DN: "cn=someUser,ou=people,dc=example,dc=net"
            LDAP_SEARCH_BIND_PASSWORD: "some_password"
            
            # Mapping Guacamole groups to LDAP DN's
            LDAP_GROUP_BASE_DN: "ou=groups,dc=example,dc=net"
            LDAP_GROUP_NAME_ATTRIBUTE: "cn"

Optional settings

            # Mapping Guacamole usernames to LDAP DN’s
            LDAP_USER_BASE_DN: "ou=people,dc=example,dc=net"
            LDAP_USERNAME_ATTRIBUTE: "sAMAccountName"

            # Indirect Username Mapping
            LDAP_SEARCH_BIND_DN: "cn=someUser,ou=people,dc=example,dc=net"
            LDAP_SEARCH_BIND_PASSWORD: "some_password" 

            # Mapping Guacamole groups to LDAP DN's
            LDAP_GROUP_BASE_DN: "ou=groups,dc=example,dc=net"
            LDAP_GROUP_NAME_ATTRIBUTE: "cn"

(3) Restart the containers

Simple Install:

sudo ./kcm-setup.run upgrade

The containers should restart after the upgrade. If not run:

sudo ./kcm-setup.run start

Custom Install:

sudo su
docker-compose up -d

Custom Root Certificate

If you require the use of a custom Root Certificate for your LDAP server, you can volume mount the file /etc/pki/ca-trust/extracted/java/cacerts in your Docker Compose to override this certificate in the guacamole docker container.

• Import the certificate into a Java truststore using "keytool".

• Volume mount the cacerts file to your target guacamole docker container

Defining the guacConfigGroup object class

When connection data is stored within your LDAP directory, each connection is represented by a special type of LDAP group, and permissions related to Keeper Connection Manager's connections can be managed directly with LDAP based on user membership of these groups. Doing this requires schema modifications which add a new object class called guacConfigGroup.

An LDIF file defining the schema changes in a manner compatible with OpenLDAP is provided by the kcm-guacamole-auth-ldap package within /opt/keeper/share/guacamole-auth-ldap/schema/guacConfigGroup.ldif. This file can be applied to your OpenLDAP server using the “ldapadd” command:

$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /opt/keeper/share/guacamole-auth-ldap/schema/guacConfigGroup.ldif

Once this is done, connections can be defined by creating new guacConfigGroup objects within the LDAP directory. Each guacConfigGroup accepts a single guacConfigProtocol attribute, defining the protocol associated with the connection, and any number of guacConfigParameter attributes, each defining a connection parameter name/value pair. Users that should have access to the connection must be added as members of the guacConfigGroup using the member attribute.

For example, a connection accessible to two users which uses VNC to connect to localhost at port 5900 with the password “secret” could be defined with the following LDIF file:

dn: cn=Example Connection,ou=groups,dc=example,dc=net
objectClass: guacConfigGroup
objectClass: groupOfNames
cn: Example Connection
guacConfigProtocol: vnc
guacConfigParameter: hostname=localhost
guacConfigParameter: port=5900
guacConfigParameter: password=secret
member: cn=user1,ou=people,dc=example,dc=net
member: cn=user2,ou=people,dc=example,dc=net

Configuring KCM to read connections from LDAP

Auto Docker And Docker Compose Install Methods:

To read connection data from LDAP, modify the /etc/kcm-setup/docker-compose.yml file.

The base DN of all connections defined within LDAP must be specified using the LDAP_CONFIG_BASE_DN property. This base DN should be the DN of the portion of the LDAP directory whose subtree contains all Keeper connections accessible via LDAP. Only connections defined within the subtree of this base DN will be visible.

The EXTENSION_PRIORITY property specifies the order that extensions should be loaded relative to each other. In the following example, all other extensions take priority over LDAP:

   guacamole:
        image: keeper/guacamole:2
        environment:
            ACCEPT_EULA: "Y"
            GUACD_HOSTNAME: "guacd"
            MYSQL_HOSTNAME: "db"
            MYSQL_DATABASE: "guacamole_db"
            MYSQL_USERNAME: "guacamole_user"
            MYSQL_PASSWORD: "xxxxxxx"
            
            # LDAP Connection
            LDAP_HOSTNAME: "localhost"
            LDAP_PORT: 389
            LDAP_ENCRYPTION_METHOD: "none"
            
            ## Optional Settings ##
            # Read Connections from LDAP
            LDAP_CONFIG_BASE_DN: "ou=connections,dc=example,dc=net"
            # Force all other extensions to take priority over LDAP
            EXTENSION_PRIORITY: "*, ldap" 

Controlling access using group membership

Auto Docker and Docker Compose Install Method

To control group membership using LDAP, modify the /etc/kcm-setup/docker-compose.yml file.

It is also possible grant entire groups access to connections using the seeAlso attribute. This attribute is a standard LDAP attribute, and will be taken into account by Keeper if the LDAP_GROUP_BASE_DN property is defined. This property defines the root of the subtree containing all groups which may apply to Keeper Connection Manager users authenticated using LDAP:

  guacamole:
        image: keeper/guacamole:2
        environment:
            ACCEPT_EULA: "Y"
            GUACD_HOSTNAME: "guacd"
            MYSQL_HOSTNAME: "db"
            MYSQL_DATABASE: "guacamole_db"
            MYSQL_USERNAME: "guacamole_user"
            MYSQL_PASSWORD: "xxxxxxx"
            
            # LDAP Connection
            LDAP_HOSTNAME: "localhost"
            LDAP_PORT: 389
            LDAP_ENCRYPTION_METHOD: "none"
            
            ## Optional Settings ##
            # Mapping Guacamole groups to LDAP DN's
            LDAP_GROUP_BASE_DN: "ou=groups,dc=example,dc=net"
            LDAP_GROUP_NAME_ATTRIBUTE: "cn"

Completing installation

Auto Docker Install Method

sudo ./kcm-setup.run stop
sudo ./kcm-setup.run upgrade

Docker Compose Install Method

docker-compose stop
docker-compose up -d

File Types

Three file types are supported for connection import: CSV, JSON, and YAML.

The same data may be specified by each file type. This must include the connection name and protocol. Optionally, a connection group location, a list of users and/or user groups to grant access, connection parameters, or connection protocols may also be specified. KSM tokens may be used in connection parameters if KSM integration is set up. Any users or user groups that do not exist in the current data source will be automatically created. Note that any existing connection permissions will not be removed for updated connections, unless "Reset permissions" is checked.

CSV Format

A connection import CSV file has one connection record per row. Each column will specify a connection field. At minimum the connection name and protocol must be specified.

The CSV header for each row specifies the connection field. The connection group ID that the connection should be imported into may be directly specified with "parentIdentifier", or the path to the parent group may be specified using "group" as shown below. In most cases, there should be no conflict between fields, but if needed, an " (attribute)" or " (parameter)" suffix may be added to disambiguate. Lists of user or user group identifiers must be semicolon-separated.

name,protocol,username,password,private-key,hostname,group,users,groups,guacd-encryption (attribute) conn1,vnc,alice,pass1,,conn1.web.com,ROOT,guac user 1;guac user 2,Connection 1 Users,none conn2,rdp,bob,pass2,,conn2.web.com,ROOT/Parent Group,guac user 1,,ssl conn3,ssh,${KEEPER_SERVER_USERNAME},,${KEEPER_SERVER_KEY},conn3.web.com,ROOT/Parent Group/Child Group,guac user 2;guac user 3,, conn4,kubernetes,,,,,,,,

JSON Format

A connection import JSON file is a list of connection objects. At minimum the connection name and protocol must be specified in each connection object.

The connection group ID that the connection should be imported into may be directly specified with a "parentIdentifier" field, or the path to the parent group may be specified using a "group" field as shown below. An array of user and user group identifiers to grant access to may be specified per connection.

[
  {
    "name": "conn1",
    "protocol": "vnc",
    "parameters": { "username": "alice", "password": "pass1", "hostname": "conn1.web.com" },
    "parentIdentifier": "ROOT",
    "users": [ "guac user 1", "guac user 2" ],
    "groups": [ "Connection 1 Users" ],
    "attributes": { "guacd-encryption": "none" }
  },
  {
    "name": "conn2",
    "protocol": "rdp",
    "parameters": { "username": "bob", "password": "pass2", "hostname": "conn2.web.com" },
    "group": "ROOT/Parent Group",
    "users": [ "guac user 1" ],
    "attributes": { "guacd-encryption": "none" }
  },
  {
    "name": "conn3",
    "protocol": "ssh",
    "parameters": { "username": "${KEEPER_SERVER_USERNAME}", "private-key": "${KEEPER_SERVER_KEY}", "hostname": "conn3.web.com" },
    "group": "ROOT/Parent Group/Child Group",
    "users": [ "guac user 2", "guac user 3" ]
  },
  {
    "name": "conn4",
    "protocol": "kubernetes"
  }
]

YAML Format

A connection import YAML file is a list of connection objects with exactly the same structure as the JSON format.

---
  - name: conn1
    protocol: vnc
    parameters:
      username: alice
      password: pass1
      hostname: conn1.web.com
    group: ROOT
    users:
      - guac user 1
      - guac user 2
    groups:
      - Connection 1 Users
    attributes:
      guacd-encryption: none
  - name: conn2
    protocol: rdp
    parameters:
      username: bob
      password: pass2
      hostname: conn2.web.com
    group: ROOT/Parent Group
    users:
      - guac user 1
    attributes:
      guacd-encryption: none
  - name: conn3
    protocol: ssh
    parameters:
      username: ${KEEPER_SERVER_USERNAME}
      private-key: ${KEEPER_SERVER_KEY}
      hostname: conn3.web.com
    group: ROOT/Parent Group/Child Group
    users:
      - guac user 2
      - guac user 3
  - name: conn4
    protocol: kubernetes

Import Notes

• The "groups" object refers to User Groups

• The "group" object refers to Connection Groups

• A connection group must exist when importing, or the import will fail.

Duo application integration details

The API hostname, integration key, and secret key are provided for you by Duo when you registered Guacamole within Duo's "Admin" panel. Each of these values is required and is generated by Duo.

Duo application key

An arbitrary and random key must be provided for communicating with the Duo service. This key MUST be manually generated and MUST BE AT LEAST 40 CHARACTERS.

Any random value containing at least 40 characters will suffice. To quickly grab 40 random characters from /dev/random:

$ tr -dc 'a-zA-Z0-9' < /dev/random | head -c40; echo
xqZKJODwg7ouwxdqU9hvuaWhE6lQFspijY0ofg8I
$

Overview

Keeper Connection Manager can be configured to authenticate users with any SAML 2.0 compatible identity provider. Users can be forced to login with SAML, or you can make SAML an optional login link from the login page as shown below.

Auto Docker Install Method

Run the reconfigure command listed below and press enter to accept all the pre-populated selections until you get to the SAML prompt.

sudo ./kcm-setup.run reconfigure

Retreive your IdP Metadata

Instructions for setting up your identity provider and retrieving the XML metadata are found in the guides blow. Any SAML 2.0 identity provider is compatible.

Complete the Prompts

• Enter your SAML IdP URL.

• When asked about signed requests, if unsure, select no.

• Enter your SAML entity ID, and then the group attribute (this must match to your IdP's group attribute).

• Next, you're asked if you want SAML as the default login process. If you want SAML login to be an option (link) on the login page, select no. If you want SAML as the only possible method of authentication, select yes.

• Answer yes when asked if you want user accounts created automatically. If you select no, you'll need to create each account manually within KCM.

SSO Configuration is complete!

Docker Compose Install Method

If you installed Keeper Connection Manager using the Docker Compose Install method, this does not come preconfigured with SAML support. The instructions for activating SAML are below:

(1) On the local instance, stop the containers.

cd /path/to/docker-compose.yml
docker-compose stop

(2) Edit the docker-compose file

Using the custom docker method requires modification of docker-compose.yml file to add SAML support. As root, edit your docker-compose.yml file and find the "guacamole" section.

Create a volume mount for sharing the metadata.xml file with the container. If you already have a shared volume for this purpose, you can use that one. There is also another section needed which needs SAML environmental variables. A sample file is listed below.

    guacamole:
        image: keeper/guacamole:2
        restart: unless-stopped
        environment:
            ACCEPT_EULA: "Y"
            GUACD_HOSTNAME: "guacd"
            MYSQL_HOSTNAME: "db"
            MYSQL_DATABASE: "guacamole_db"
            MYSQL_USERNAME: "guacamole_user"
            MYSQL_PASSWORD: "xxxxxxxx"
            SAML_CALLBACK_URL: "https://demo.lurey.com"
            SAML_IDP_METADATA_URL: "file:///etc/guacamole/metadata.xml"
            SAML_ENTITY_ID: "https://demo.lurey.com"
            SAML_GROUP_ATTRIBUTE: "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
            ADDITIONAL_GUACAMOLE_PROPERTIES: "extension-priority: *, saml"
     volumes:
            - common-storage:/var/lib/guacamole
            - "/etc/kcm-setup/metadata.xml:/etc/guacamole/metadata.xml:ro"

Notes:

• Replace "/var/lib/guac_home" with the local path to your volume

• Replace "https://demo.lurey.com" in 2 spots with your Keeper Connection Manager login URL

• Only use this SAML group attribute if you're using Azure. Other identity providers will use a different Group attribute ID.

• If you want ALL users to login with SAML, then remove the ADDITIONAL_GUACAMOLE_PROPERTIES line. As written, it will give users the choice of password or SAML login.

(3) Create the local folder volume if it doesn't exist yet

(4) Copy the metadata.xml file from your local computer (downloaded from step 8 above) into the location of the volume mount referenced in the guacamole section of the docker-compose file.

(5) Restart the containers

sudo su
docker-compose up -d

Configuration is complete.

Complete

Once you have activated the SAML module, there will be a new "Sign in with SAML" link on the login screen of the application as seen below:

Okta Configuration

The first step regardless of installation method is to configure your SAML 2.0 identity provider using Okta.

(1) In Okta, go to Admin > Applications > Create App Integration and select SAML 2.0. Click Next.

(2) Give the Enterprise Application a name and upload the logo file linked below then click Next.

The image logo is here:

(3) Configure the SAML Settings

The SAML configuration should match the format as seen below:

• Replace demo3.lurey.com with the URL of your Keeper Connection Manager domain.

• Ensure the full path appears, e.g. https://DOMAIN/api/ext/saml/callback

• For the Audience URI, use the path to the Login screen (remove the trailing slash). For example, https://demo3.lurey.com

Scroll down to the Group Attribute Statements. To send the group attribute, set the name to "groups", and the name format to "Basic". If you would like ALL groups assigned to the user to be sent to Keeper Connection Manager, select the "Matches regex" with a value of ".*"

Click Next.

(4) In the Feedback section, make the selections as appears below.

(5) Assign users and/or groups to the Keeper Connection Manager application, as you would normally do with any SAML connected app.

(6) Download the Okta Metadata file and save to your local machine as metadata.xml

The location of the metadata file depends on your version of the Okta interface. In this example there is a link called "Identity Provider metadata" on the application page. There may also be a text box that contains the metadata which you can copy and paste into a local file on your computer.

The metadata XML file could also be linked in the Sign On tab > SAML Signing Certificate section under "Actions".

Save the resulting metadata.xml file by selecting "Save page as..." in your browser.

The Okta side of the setup is complete. Note if you change anything, you need to re-download a new metadata.xml file. Transfer this metadata.xml file to your KCM server machine.

Overview

Keeper Connection Manager can pull secrets from different vaults or different shared folders of the Keeper Vault, via the Keeper Secrets Manager integration. There are two main ways which KCM can connect to multiple Keeper Vaults for retreiving secrets:

1. Connection Groups can be assigned to different secrets manager configurations. Any connection defined within a Connection Group will retrieve secrets from the group assignment.

2. Users can be assigned Secrets Manager configurations, and connections can retrieve secrets from configurations defined by each individual user profiles. This allows different users to connect to the same set of connections with their own set of secrets.

Connection Groups

Each Keeper Connection Manager "Connection Group" can use a Keeper Secrets Manager configuration for the connections in the group. When this is activated, each connection group will look for records in the corresponding Secrets Manager configuration to retrieve secrets and replace tokens in the connection settings.

In order to use a Keeper Secrets Manager with a Connection Group, enter a Keeper Secrets Manager One-Time Access Token, or Configuration into the "KSM Service Configuration" field of the connection group form.

All connections created within this Connection Group will then use the Secrets Manager configuration defined to retrieve secrets when establishing connections, instead of using the root level Secrets Manager configuration.

The Secrets Manager configuration can come from the same vault, or any other vault.

See the Dynamic Tokens documentation for more information on the available tokens and how to use them.

User-Specified Configuration

Each Keeper Connection Manager User profile can be assigned to a Keeper Secrets Manager configuration for any connection. When the connection is updated to allow user-specific vaults, Keeper Connection Manager will pull the secret from the user's corresponding configuration. This feature allows multiple users to share the same set of connections, using secrets that originate from the user's own vault.

In order to use user-specific secrets manager connections, the Keeper Connection Manager installation needs to have the feature enabled. It is disabled by default.

Docker Install Method

An additional environmental variable must be added to the keeper/guacamole Docker image in your docker-compose.yml file.

KSM_ALLOW_USER_CONFIG

For example:

            ....
            MYSQL_DATABASE: "guacamole_db"
            MYSQL_USERNAME: "guacamole_user"
            KSM_CONFIG: "XXX"
            ....
            ....
            KSM_ALLOW_USER_CONFIG: "true"
            ....

In the Edit User screen, fill in the KSM Service Configuration that has been set up for that user. This is also available to each user to set up the KSM Service Configuration for themselves.

When creating or editing a connection, there is a field which appears called "Allow user-provided KSM configuration".

When this option is selected, Keeper Connection Manager will look for corresponding secrets in the user's vault corresponding to the Keeper Secrets Manager configuration.

Order of Precedence

Keeper Connection Manager will always use the base (or Connection Group) secrets if any are applicable. It will only use user-provided secrets if there isn't an admin-provided secret for the same, to ensure that users cannot override the intent of the admin.

Before you start

Step 1. Create a working folder and save the Compose file

• Sign in to your server and run:

• In a browser, visit the page

• Scroll to Step 2 — Create Docker Compose File.

• Copy the YAML block and paste the text into the file /opt/kcm/docker‑compose.yml with a text editor.

Step 2. Download the hardened seccomp profile

Keeper’s docs place this file automatically if you use their install script. With Compose we pull it ourselves:

The command starts a temporary container, reads the JSON file inside, and saves it on the host.

Step 3. Install Podman & helper tools

RHEL / Alma / Rocky / Fedora

Ubuntu / Debian

Check: podman --version should show 5.x or newer.

Step 4. Modify the Compose file for Podman

Open /opt/kcm/docker‑compose.yml again and make these small edits:

1. Security profile (under the guacd service):

2. SELinux hosts only (RHEL/Fedora): add :Z after each bind‑mount, for example: - "common-storage:/var/lib/guacamole:rw,Z"

3. Optional: Replace any :latest tags with the current major tag :2 (e.g. keeper/guacamole:2).

That’s it—no other changes are required.

Step 5. Start Keeper Connection Manager

Check that three containers are Up:

Open your browser to http://<server‑IP>:8080. You should see the Keeper login page.

Step 6. Open the firewall (RHEL/Fedora)

(Ubuntu’s UFW or Debian’s nftables users perform the equivalent rule.)

Step 7. Set up automatic startup

Now KCM will survive server reboots without any extra commands.

Step 8. First‑run checks

Troubleshooting

When in doubt, run podman logs <container-name> and read the last few lines—it usually tells you what went wrong.

You’re done! Keeper Connection Manager is now running on Podman without Docker. Enjoy your lighter, daemon‑free setup.

Definitions

KCM Server: The instance running Keeper Connection Manager.

Remote Endpoint: A target Linux instance in a protected network without data ingress which cannot yet be accessed directly by the KCM Server.

Install KCM Server

If you have not set up a Keeper Connection Manager instance, follow the instructions on any instance within any cloud environment. This service will be your KCM Server.

Reverse Tunnel Setup

The instructions below outline how to establish a connection from a KCM Server in the cloud, to an internal Remote Endpoint without network ingress.

(1) Allow inbound SSH on KCM Server

On the KCM Server, ensure that inbound SSH port 22 connections are open from the Remote Server to the KCM instance. We will be establishing an outbound connection from the Remote Server to the KCM instance to set up the reverse tunnel.

(2) Generate SSH Key on the Remote Endpoint

On the Remote Endpoint, create an SSH key pair which will be used to establish an outbound connection from the Endpoint to the KCM Server.

This will create two files, a private key and a public key. Leave the private key as is, and copy only the .pub file to your KCM Server.

Now we need to add the contents of the public key file into a special file in your KCM server directory. Check your <home>/.ssh directory and if it doesn't already have a file called "authorized_keys" then create the file. Take the text from the public key file id_ed25519.pub and put the text into the the file~/.ssh/authorized_keys on the KCM server.

The text should have the following format:

Save the authorized_keys file as ~/.ssh/authorized_keys

(3) Verify SSH Connectivity from Remote Endpoint to KCM Server

You should now be able to SSH from the remote server into the KCM server, without any password prompt (using the keys).

(4) Install autossh on the Remote Endpoint

The Linux program autossh is a helper utility for creating a persistent SSH tunnel. Installation of autossh depends on the platform, but a typical command to install it would be:

Or, to build from source, follow these steps (for example, on an Amazon Linux 2 AMI):

(5) Update GatewayPorts setting on KCM Server

On the KCM Server, the SSH process (sshd) must be modified to permit remote hosts (e.g. the guacd Docker container) to be allowed to connect to forwarded ports. By default, sshd binds remote port forwards to the loopback address. Setting the value of GatewayPorts to "clientspecified" allows the client to select the address to which the forwarded port is bound.

• Edit the file /etc/ssh/sshd_config

• Update the GatewayPorts line to this:

• Restart sshd

(6) Command to Create Persistent Reverse SSH Tunnel

In order to establish an SSH connection from the KCM Server to the Remote Server, we need to first create a persistent reverse tunnel, initiated from the Remote Server.

On the Remote Endpoint, execute autossh in the background, using parameters similar to below. Note that the full path to the private SSH key is provided. Autossh will then run in the background and the tunnel will remain active as long as the instance is running.

The reverse tunnel is now established between the Remote Server and the KCM Server.

To verify connectivity, you can now establish an SSH session from the KCM Server to the Remote Server over localhost on the port defined by the tunnel (in this case, port 9000).

From the KCM Server this can be tested using the command below:

(7) Update docker-compose to reference the host

In the Docker install environment, it's possible to establish a connection to the Keeper Connection Manager host instance using a special host name called host.docker.internal.

To configure this, update the file /etc/kcm-setup/docker-compose.yml guacd section to include the "extra_hosts" parameter, as seen below:

Update the docker environment for the change to take effect.

(8) Create Connection to the target Remote Server

Now that the reverse SSH tunnel is set up, and the docker container is able to access the reverse tunnel, you can now simply create a connection from the Keeper Connection Manager interface.

For this example, you can create a new connection which simply references the Hostname of host.docker.internal and the port of 9000.

As usual, ensure that the proper Authentication parameters are populated in the connection for the remote server. In this case, the remote server is being accessed via the established reverse SSH tunnel.

Save the connection, navigate back to the "My Connections" or "Home" screen, and then click on the connection you just created to verify the routing was successful.

Creating More Connections

If you would like to establish more connections using reverse SSH tunneling, repeat Step 6 of this guide on a different port (e.g. 9001, 9002, etc...). Then reference host.docker.internal with the specified port number when creating Connections inside Keeper Connection Manager.

References

Several references and guides posted online contain helpful information about this configuration.

Static Tokens

Connection Manager supports configuring custom static tokens which can correspond to a specific field of a specific Keeper Vault record contained within the Shared Folder. These static tokens must be specified in either the Docker compose or directly in the guacamole configuration file, depending on the installation method of the platform. In most cases, the Dynamic Tokens are a preferable method of integration.

Auto Docker Install Method

If you installed Keeper Connection Manager using the Auto Docker Install method, you will need to modify the auto-generated Docker Compose file to define your static tokens.

As root, edit the /etc/kcm-setup/docker-compose.yml file.

Edit the "environment" section underneath the "guacamole" docker image. Insert an environmental variable called KSM_TOKEN_MAPPING that includes a multi-line definition of your custom tokens. In the example below, there are 3 custom tokens for specific fields within the Keeper vault shared folder. The token syntax is using .

Once the file changes have been saved, update the containers:

Docker Compose Install Method

Edit your docker-compose.yml file. Look for the "guacamole" docker image and the "environment" section which defines environmental variables.

Insert an environmental variable called KSM_TOKEN_MAPPING that includes a multi-line definition of your custom tokens. In the example below, there are 3 custom tokens for specific fields within the Keeper vault shared folder. The token syntax is using .

Once the file changes have been saved, update the containers:

Custom Token Usage

When using custom tokens, the records can be setup in any way. Keeper notation in the mapping file can identify any specified field.

The tokens can then be used with the ${XXX} format within the Connection Manager parameters screen. A couple of examples are seen below:

About

You can store SSH Keys and Windows passwords in your Keeper vault for connecting to EC2 instances alongside the KCM Cloud Connector.

See the for more details on connecting KCM with AWS EC2 instances.

Setup

Enable

The feature must first be enabled using either the Docker environment variable or the guacamole properties.

Docker Environment Variable

For Auto Docker Install and Docker Compose Install methods, in the keeper/guacamole-db-mysql image, a new environmental variable must be defined:

AWS_DISCOVERY_KSM_CONFIG

This must contain a Keeper Secrets Manager configuration. It can be the same config used with the KSM_CONFIG variable.

For example:

For Advanced Linux Install method, update the guacamole.properties file.

Remove volume mount for PEM key files

If you are using Keeper to store the PEM key files, you can remove the volume mount in the Docker Compose file that references the location /var/lib/guac_keys/ as this will not be used.

Configure a Record for use with Cloud Connect

The EC2 cloud connector recognizes Keeper records with specific fields automatically.

To create a record for use with the EC2 Cloud connector, you can either create a record that contains a pem file attachment containing your key, or a record that contains the key as text.

PEM File Record

Create a new record which will contain the pem file. The File Attachment record type is a good match, but any type other than General will work.

The record can have any title, In this example we're using "AWS key: my-machine"

With the record created, attach the pem file.

Lastly, ensure that the new record is in a shared folder that is accessible to KCM via the Secrets Manager vault connection.

Private Key Record

Create a new record which will contain your machine's private key. The record is required to have a "private key" field. The SSH standard record type can be used for this.

The record can have any title.

The new record will need a custom text field named "Instance ID". Add a "Text" type custom field from the Custom Field menu, click "Edit Label" and enter "Instance ID".

With the record ready, enter your machine's private key into the Private Key field, and your AWS instance ID in the new custom field.

Lastly, make sure that the record is in a shared folder that is accessible to KCM via Secrets Manager integration.

Installing and configuring included extensions

Supported extensions, such as those provided by the Keeper Connection Manager packages, are installed through installing their corresponding packages. If you are using extensions are automatically installed using the above packages depending on the environment variables provided when the container is first started.

The Keeper Connection Manager packages for supported extensions will automatically create symbolic links to install themselves and any needed libraries/drivers. You do not need to manually create links, copy files, etc. for the extensions which are provided within the Keeper Connection Manager repository.

Custom Extensions

The functionality of Keeper Connection Manager can be extended throught the use of custom extensions. describes how to create a custom extension with examples.

Shared JSON secret key

A shared secret key is used by systems generating JSON data to encrypt and sign the JSON, and by the Guacamole server to verify and decrypt received data. This key must be 128 bits, specified with 32 hexadecimal digits.

This key can be essentially anything as long as it is unpredictable. An easy way of generating such a key is to echo a passphrase through the "md5sum" utility. This is the technique OpenSSL itself uses to generate 128-bit keys from passphrases. For example:

Source network restrictions

By default, received encrypted JSON will be accepted as long as it is valid and properly signed with the secret key. This can be further restricted to accept encrypted JSON only from machines which match a comma-separated list of trusted IP addresses and/or CIDR subnets.