Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Keeper Connection Manager installation instructions in the cloud or on-prem environments.
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.
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.
The container running Keeper Connection Manager needs network access to the target desktops/systems that will be managed.
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.
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.
If you plan to use Let's Encrypt as your CA, you should open port 80 and 443. LetsEncrypt uses port 80 to perform automated SSL certificate generation.
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.
Keeper Connection Manager can be installed using one of the following methods.
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.
--> Installation Instructions for Auto Docker Install
This method is recommended for users who are new to Docker and prefer Linux.
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.
--> Installation Instructions for Docker Compose Install
This method is required for Windows and recommended for users who are familiar with Docker.
Instantly access your infrastructure with zero-trust security.
Keeper Connection Manager (KCM) is an agentless remote desktop gateway that provides IT Admins and DevOps with secure easy access to RDP, SSH, database and K8s endpoints through a web browser.
Benefits of the platform:
Agentless
Lightning Fast and Responsive
Simple Access Controls
Deployment options for cloud, on-prem and air-gapped environments
Features include:
Support for RDP, SSH, VNC, K8s remote access protocols
Support for MySQL, PostgreSQL, SQL Server database protocols
Session Recording
Privileged Session Management
Multi-User Session Sharing
Role-Based Access Controls
MFA Options: TOTP, Duo
PIV/CAC smart card login
SSO, OpenID Connect, Active Directory, LDAP Integration
Custom Branding
Keeper is typically deployed as a Docker container. The system architecture diagram is below.
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.
Ready to get started with Keeper Connection Manager? Proceed to the installation instructions.
Keeper Connection Manager security and encryption model
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.
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.
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 Auto Docker Install and Docker Compose Install 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.
The engineering team at Keeper Security that built Keeper Connection Manager (formerly Glyptodon) are the inventors and primary maintainers of the open source Apache Guacamole project. Keeper Security is proud to support the open source community and millions of users who use the Apache Guacamole remote desktop software.
The packages provided by Keeper Connection Manager have been designed to follow best practices with respect to security, particularly with respect to the Principle of Least Privilege. 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.
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 Auto Docker Install or Docker Compose Install method, you may have already configured SSL.
Customers who deploy the Auto Docker Install version can use the built-in update capabilities.
Customers who deploy the Docker Compose Install version can use the Docker update capabilities.
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.
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.
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. Click here to learn more about Keeper's GDPR compliance and download data processing agreements.
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).
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 Security Disclosure and visit our Enterprise Guide.
Keeper performs quarterly pen testing with 3rd party experts including NCC Group and Cybertest. In addition, Keeper works with independent security researchers who test against all of our products and systems through our Bugcrowd bug bounty program.
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.
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.
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 https://www.privacyshield.gov
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 certificate #3967 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
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: https://www.bis.doc.gov
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 contact us.
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 contact us.
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
FedRamp
DIACAP
FISMA
ITAC
FIPS 140-2
CSA
MPAA
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.
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 security@keepersecurity.com 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 security@keepersecurity.com 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.
Keeper has partnered with Bugcrowd to manage our vulnerability disclosure program.
Please submit reports through [https://bugcrowd.com/keepersecurity].
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:
Secrets Manager Encryption Model
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.
Get your environment, network, and system ready and prepared.
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:
Start by choosing "use a self-signed certificate" (for testing)
Choose "Let's Encrypt" to generate a 90 day auto-renewing cert (requires 80 and 443 open)
Bring your own cert during setup or add it in later using the reconfigure command
To prepare for installation:
Create/Identify and establish root access to the server that will run the Keeper Connection Manager gateway
Decide if you want your KCM gateway to be public-facing (assign public IP), or internal-only (assign private IP)
Add internal/external DNS A Record (or AAAA record) to point your domain to your KCM server's IP address
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.
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.
If Podman is installed, you must run the following two commands before installation:
Detailed list of system and operating system requirements for Keeper Connection Manger
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
The generalized formula for sizing Keeper Connection Manager is 1 CPU core and 2 GB of memory for every 25 concurrent users anticipated.
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.
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.
There are far too many variables in play to accurately predict disk space needs for recordings. The best practices are to monitor the recordings folder and offload them to another location as needed.
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.
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.
On RHEL, the haveged
package is not available from the Red Hat repositories and must instead be installed from the EPEL repository. EPEL provides instructions for configuring their repository here: . After EPEL is installed, run the following commands:
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.
# Concurrent connections | CPU | Memory |
---|
0-25 | 2 | 2gb |
26-50 | 3 | 6gb |
51-100 | 4 | 8gb |
101-200 | 8 | 16gb |
200+ | Contact us | Contact us |
Automated Linux Docker installer for users without Docker experience
Auto Docker Install is Keeper's recommended installation method.
Make sure to read the Preparing for Installation 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 Docker Compose Install method.
(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.
If you want to use Let's Encrypt (option 1) to quickly and easily generate and install an SSL certificate, you must have public DNS in place pointing to your static public IP. Also, Let's Encrypt requires HTTP port 80 and HTTPS port 443 to be open during the install process.
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 generated from Keeper Secrets Manager (a tab in your vault). If this doesn't apply to you, just press enter. You can always add it later, too.
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. Follow the SSO setup steps here.
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.
Store the provided username, password, and URL in your Keeper Vault
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.
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? Follow the steps here.
The next section of this documentation reviews the process of managing, upgrading and adding packages to the Docker Compose environment.
Upgrading Keeper Connection Manager with the Docker Automated Install method
From the Linux command line, update to the latest installer script using the curl command.
To update all of the underlying software and Docker containers when using the Docker Automated Install method, run the below commands:
Select "Y" when prompted.
Once the upgrade is complete, the service is started again automatically after a minute.
Auto Docker Install service management
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.
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.
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.
Command | Description |
---|
backup | Backup all database data to a file. |
check | Perform an automated self-check of all services. |
install | Install Keeper Connection Manager (DEFAULT). |
logs | Display the log files from all installed services. |
reconfigure | Modify the configuration of an existing KCM installation. |
restart | Restart all installed services, starting any that are stopped. |
restore | Restore database data from a prior backup. |
start | Start all installed services that are not started. |
status | Display the status of installed services. |
stop | Stop all installed services that are not stopped. |
uninstall | Completely remove the existing installation. This will delete all stored data in the database. |
upgrade | Upgrade the existing installation by pulling the latest docker images. Your data stored in the service is retained. |
apply | Strictly apply changes made externally to |
Docker deployment of Apache Guacamole with Keeper Connection Manager
Image: keeper/guacamole
Arbitrary third-party extensions may be used through volume mounts and setting ADDITIONAL_GUACAMOLE_PROPERTIES
variables as needed.
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.
ACCEPT_EULA
ADDITIONAL_GUACAMOLE_PROPERTIES
ALLOWED_LANGUAGES
This variable is optional and restricts the display languages within Guacamole to the comma-separated list of language keys. If specified, only the listed languages will be made available to the user, and only the listed languages will be selected from automatically based on the user's browser's preferred language. For example, to restrict Guacamole to only English and German, specify ALLOWED_LANGUAGES="en, de"
. As English is the fallback language, used whenever a translation key is missing from the chosen language, English should only be omitted from this list if you are absolutely positive that no strings are missing from your custom translations.
By default, all defined languages will be available.
API_*
All environment variables which start with API_
correspond to configuration properties for configuring the Guacamole web application as a whole. These variables control how Guacamole handles user sessions and any HTTP requests that it receives. Note that these variables control only aspects of the Guacamole web application. They do not control the behavior of remote desktop sessions.
AWS_DISCOVERY_*
The following environment variables are required if using EC2 discovery:
Other, optional environment variables are available for the other properties related to EC2 discovery:
BAN_*
All environment variables which start with BAN_
correspond to configuration properties for configuring how apparent brute-force authentication attempts against the web application are automatically blocked. Each of these variables is optional.
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 LDAP servers that use SSL/TLS.
CATALINA_OPTS
This variable is optional and specifies arbitrary command-line options that should be passed to the JVM running Tomcat. It corresponds to Tomcat's own CATALINA_OPTS
environment variable and is primarily used to pass additional system properties to the JVM, as may be necessary to configure platform-level options like whether an HTTP proxy should be used.
For example, if you wish to ensure that all outbound HTTPS connections go through an HTTP proxy, including API calls to services like Keeper Secrets Manager (KSM), you would set CATALINA_OPTS
to:
where "my.proxy
" is the hostname or IP address of the desired HTTP proxy and "3129
" is its TCP port number.
CONTEXT_PATH
This variable is optional and specifies the path that the Guacamole web application should be served under. By default, the web application will be served at the root directory (http://your-container:8080/
), but this can be overridden by setting CONTEXT_PATH
to the name of a different location.
DUO_*
The following environment variables are required if using Duo multi-factor authentication:
EXTENSIONS
This variable is optional and specifies a comma- or newline-separated list of the names of all extensions that should be activated in the image, regardless of which other environment variables may be specified. Empty names, whitespace, and trailing commas are ignored.
Extension names are dictated by the guacamole(*)
package capability of the corresponding Keeper Connection Manager package (part of the RPM package's metadata):
This variable is mainly of use for extensions which can be used without setting any configuration options, like TOTP two-factor authentication, or to force sanity checks on the presence of required environment variables even if all associated variables might be accidentally omitted. Extensions not listed within this environment variable will still be included if any of their corresponding environment variables are set.
EXTENSION_PRIORITY
This variable is optional and specifies the order that extensions should be loaded relative to each other. By default, extensions are loaded in alphabetical order based on their filenames.
To override the load order of extensions, list the names of each extension that should be loaded first, separated by commas. The special name *
may be used as a placeholder for all other extensions. For example:
GUACD_*
TCP connection information for guacd.
Other, optional environment variables are available for configuring other aspects of the connection to guacd:
JSON_*
The following environment variables are required if using encrypted JSON authentication:
Other, optional environment variables are available for the other properties related to encrypted JSON authentication:
KSM_*
LDAP_*
The following environment variables are required if using LDAP authentication (for a single LDAP server):
Other, optional environment variables are available for the other properties related to LDAP authentication:
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", "warn", "info", "debug", "trace".
The default log level is "info".
MYSQL_*
The following environment variables are required if using MySQL authentication:
Other, optional environment variables are available for the other properties related to MySQL authentication:
OPENID_*
Optional variables:
POSTGRES_*
The following environment variables are required if using PostgreSQL authentication:
Other, optional environment variables are available for the other properties related to PostgreSQL authentication:
REQUIRE_ACCOUNT_APPROVAL
This variable is optional and specifies the extensions that should require explicit approval from an administrator on a per-account basis before they can be used to authenticate a user. By default, any installed authentication method may be used.
To require approval for particular authentication methods, list the names of each extension that should require approval, separated by commas. For example:
Account approval status can only be stored and enforced on users with identities in the KCM database. Depending on which database you are using, you can request that KCM automatically create this storage for accounts that do not yet exist within the database by setting one of the following environment variables to "true":
SAML_*
The following environment variables are required if using SAML authentication:
Optional environmental variables:
SQLSERVER_*
The following environment variables are required if using SQL Server authentication:
Other, optional environment variables are available for the other properties related to SQL Server authentication:
SSL_*
The following environment variables are required if using SSL/TLS client authentication:
Other, optional environment variables are available for the other properties related to SSL/TLS client authentication:
TOTP_*
UDS_*
USER_MAPPING
As the contents of this file are inherently sensitive, the file will be stored purely in memory (within /dev/shm
) unless the USE_SHM
environment variable is set to "N" as documented below.
USE_DEFAULT_BRANDING
Keeper Connection Manager ships with its own default branding. If you will be using your own custom branding, the optional USE_DEFAULT_BRANDING
environment variable should be set to "N" to disable the Keeper branding and avoid conflicts with your branding extension.
USE_SHM
This variable is optional and may be used to force storage of known sensitive files on disk rather than in memory. To force storage to disk, set USE_SHM
to "N".
By default, the keeper/guacamole
image stores the contents of files that are known to be sensitive within /dev/shm
, thus storing those files only in memory and without potentially persisting sensitive data to disk. As such files are generated by the Docker image from environment variables during startup, this is particularly useful if Docker secrets are being used.
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. For example, to read /etc/guacamole/user-mapping.xml
from a file:
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:
To activate advanced features of Keeper Connection Manager, you simply add an environmental variable to the docker file that controls the feature, or you add one of the flags as documented below.
The Guacamole logs are useful if debugging unexpected behavior of the aspects of the web application which are not directly related to remote desktop, including authentication. To view the Tomcat/Guacamole logs follow the documentation.
The ACCEPT_EULA
environment variable must be set to "Y" to indicate your acceptance of the . This Docker image may not be used except under the terms of the EULA.
This variable is optional and specifies any additional content that should be appended to /etc/guacamole/guacamole.properties
during startup. This content is added via , thus environment variable substitution will be automatically performed on the content of this variable.
Variable name | Description |
---|
All environment variables which start with AWS_DISCOVERY_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
Variable name | Description |
---|
Variable name | Description |
---|
Variable name |
---|
Note that the location specified with CONTEXT_PATH
may not contain slashes. If you need to serve the web application beneath a more complex nested path, you will need to use a reverse proxy like or .
Variable name | Description |
---|
Extension name | Declared capability | Corresponding package |
---|
Description | Value of EXTENSION_PRIORITY |
---|
Variable name | Description |
---|
Variable name | Description |
---|
All environment variables which start with JSON_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
Variable name | Description |
---|
Variable name | Description |
---|
All environment variables which start with KSM_*
correspond to configuration properties for Keeper Secrets Manager. See the guide.
Variable name | Description |
---|
All environment variables which start with LDAP_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
Variable name | Description |
---|
, or if you prefer to provide LDAP server configuration in YAML format, the following environment variable is required:
Variable name | Description |
---|
Variable name | Description |
---|
All environment variables which start with MYSQL_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
If intending to use MySQL, you may wish to use which provides a MySQL database that is automatically initialized for use by Guacamole.
Variable name | Description |
---|
Variable name | Description |
---|
All environmental variables which start with OPENID_ correspond to configuration properties for which would normally be specified within guacamole.properties.
Variable Name | Description |
---|
Variable Name | Description |
---|
All environment variables which start with POSTGRES_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
If intending to use PostgreSQL, you may wish to use which provides a PostgreSQL database that is automatically initialized for use by Guacamole.
Variable name | Description |
---|
Variable name | Description |
---|
Description | Value of REQUIRE_ACCOUNT_APPROVAL |
---|
All environment variables which start with SAML_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
Variable Name | Description |
---|
Variable Name | Description |
---|
All environment variables which start with SQLSERVER_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
Variable name | Description |
---|
Variable name | Description |
---|
All environment variables which start with SSL_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
Variable name | Description |
---|
Variable name | Description |
---|
All environment variables which start with TOTP_
correspond to configuration properties for which would normally be specified within guacamole.properties
.
Variable name | Description |
---|
All environment variables which start with UDS_
correspond to configuration properties for that would normally be specified within guacamole.properties
.
Variable name | Description |
---|
This variable is optional and specifies the full contents of the /etc/guacamole/user-mapping.xml
file that can be used to test a Guacamole deployment without configuring a more complex authentication method like MySQL, PostgreSQL, or LDAP. This is the authentication mechanism described within the .
| The maximum number of bytes to accept within the entity body of any particular HTTP request to the REST API, including authentication requests. This limit does not apply to files transferred within a remote desktop session. Specifying 0 disables request size limitations. By default, requests are limited to 2097152 bytes (2 MB). |
| The amount of time, in minutes, a Guacamole session may remain valid despite being inactive. By default, Guacamole sessions are limited to one hour. This setting affects Guacamole sessions only, not remote desktop sessions. To enforce limits on the duration of remote desktop sessions, you must change the relevant setting within your remote desktop server, such as the session time limit GPOs provided by the Windows RDP server. Guacamole considers a connected remote desktop session to be user activity, and does not attempt to define what constitutes an idle but connected remote desktop session. |
| The access key ID for the AWS account that should be used to authenticate with AWS. |
| The secret key associated with the access key |
| Comma-separated list of regions to query for EC2 instances, such as |
| The name of the organizational connection group that should be used to house the EC2 instances for convenience. By default, this will be "Amazon EC2". |
| The name of the User Group in Keeper Connection Manager to require for any user to see the discovered EC2 instances. By default, this will be a group called "AWS EC2 Administrators". |
| If set to "true", screen recording will be enabled by default on all connections. Connection session recording can also be set at an individual machine level using the " |
| The base64-encoded Keeper Secrets Manager configuration to use to retrieve the private keys for EC2 instances from the Keeper vault. |
| The minimum number of milliseconds that must elapse between API calls to Keeper Secrets Manager. By default, KCM will wait 10 seconds between each call, using cached data from the last retrieval until another retrieval attempt is allowed. |
| The amount of time an IP address is temporarily blocked after repeatedly failing to authenticate, in seconds. By default, addresses are blocked for 5 minutes. |
| The maximum number of IP addresses that KCM will track to check for invalid attempts. By default, up to 10485760 addresses will be tracked. |
| The number of invalid attempts that may occur before the source IP address is temporarily blocked from further attempts. By default, 5 failed authentication attempts will result in a temporary block. |
| The hostname of the Duo API endpoint that will be used to verify user identities, assigned by Duo when Guacamole was added as a "Web SDK" application. This value can be found within the application details in Duo's "Admin" panel. |
| This is the Client ID provided for you by Duo when Guacamole was added as a "Web SDK" application. This value can be found within the application details in Duo's "Admin" panel. |
| The secret key provided for you by Duo when Guacamole was added as a "Web SDK" application. This value can be found within the application details in Duo's "Admin" panel. |
| An arbitrary, random key consisting of at least 40 characters. This value must be manually generated specifically for this deployment of Guacamole. |
Force SAML to take priority over all other extensions. |
|
Force all other extensions to take priority over SAML. |
|
Prefer LDAP over any other authentication method, and force all other extensions to take priority over SAML and OpenID. |
|
| The hostname of the machine hosting the guacd service. |
| The port used by the guacd service. |
| Whether the guacd service has been configured for SSL/TLS. |
| The shared secret key that will be used by systems generating JSON data to encrypt and sign that data. This key must be 128 bits, specified with 32 hexadecimal digits. |
| A comma-separated list of trusted IP addresses and/or CIDR subnets which should be allowed to send encrypted JSON. If omitted, any address will be allowed to send JSON. |
| The hostname or IP address of the LDAP server that Guacamole should use for authentication. |
| The common base DN shared by all Guacamole users within the LDAP directory. |
| The hostname or IP address of the MySQL or MariaDB server hosting the Guacamole database. |
| The name of the database that has been created for Guacamole on the MySQL or MariaDB server. |
| The username that Guacamole should use when authenticating with the MySQL or MariaDB server. |
| The password that Guacamole should provide when authenticating with the MySQL or MariaDB server. |
| The TCP port that the MySQL or MariaDB server is listening on. If omitted, the standard MySQL port of 3306 will be used. |
| The minimum length to require for user passwords. By default, password complexity is not enforced. |
| If set to "true", require that user passwords use both uppercase and lowercase characters. |
| If set to "true", require that user passwords contain at least one symbol. By default, password complexity is not enforced. |
| If set to "true", require that user passwords contain at least one digit. By default, password complexity is not enforced. |
| If set to "true", disallow user passwords that contain the user's username. By default, password complexity is not enforced. |
| The minimum number of days that must elapse following a password change before the user may change their password again. By default, users are not required to wait before changing their password. |
| The maximum number of days that may elapse since the last password change before the user is required to change their password. By default, users are not required to regularly change their password. |
| Remember this number of previous passwords and prohibit reuse of those passwords when the user's password is changed. By default, users are allowed to reuse previous passwords. |
| The maximum number of concurrent connections to allow to any particular connection, regardless of user, where a value of "0" indicates unlimited. By default, concurrent usage of connections is not limited. |
| The maximum number of concurrent connections to allow to any particular connection group, regardless of user, where a value of "0" indicates unlimited. By default, concurrent usage of connection groups is not limited. |
| The maximum number of concurrent connections to allow each user to hold to any particular connection, where a value of "0" indicates unlimited. By default, user-specific concurrent usage of connections is not limited. |
| The maximum number of concurrent connections to allow each user to hold to any particular connection group, where a value of "0" indicates unlimited. By default, user-specific concurrent usage of connection groups is limited to one. |
| The maximum number of concurrent connections to allow to overall, regardless of user, connection or connection group, where a value of "0" indicates unlimited. By default, overall concurrent usage is not limited. |
| If set to "true", require that each user have a corresponding account defined within the database, even if the user authenticated through some other mechanism (such as LDAP). By default, users that successfully authenticate through another mechanism are not required to also have an account within the database. |
| Whether connections that do not exist within the database should have connection history tracked in the database. If set to "true", connection history records will be created for any connection established. If set to "false", connection history records will be created only for connections defined in the database. By default, external connections will be tracked. |
| Whether access time restrictions imposed by the administrator on user accounts should be enforced while a user is logged in. If set to "true", users will be automatically logged out within roughly one minute of reaching their access time limits. If set to "false", access time restrictions will only be enforced at the moment a user attempts to log in. By default, access time restrictions are enforced while users are logged in. |
| Whether user account entries should automatically be created within the database for users that successfully authenticate through other means, such as an SSO provider or LDAP. This may be necessary if using an extension that requires account-specific storage, like TOTP or per-account approvals. If set to "true", user account entries will automatically be created. By default, administrators must manually create such entries if needed. |
| The authorization endpoint (URI) of the OpenID service. This value should be provided to you by the identity provider. For identity providers that implement OpenID Connect Discovery, this value can be retrieved from the "authorization_endpoint" property of your provider's ".well-known/openid-configuration" JSON file. |
| The OpenID client ID which should be submitted to the OpenID service when necessary. This value is typically provided to you by the OpenID service when OpenID credentials are generated for your application. |
| The issuer to expect for all received ID tokens. This value should be provided to you by the identity provider. For identity providers that implement OpenID Connect Discovery, this value can be retrieved from the "issuer" property of your provider's ".well-known/openid-configuration" JSON file. |
| The endpoint (URI) of the JWKS service which defines how received ID tokens (JSON Web Tokens or JWTs) shall be validated. This value should be provided to you by the identity provider. For identity providers that implement OpenID Connect Discovery, this value can be retrieved from the "jwks_uri" property of your provider's ".well-known/openid-configuration" JSON file. |
| The URI that should be submitted to the OpenID service such that they can redirect the authenticated user back to Keeper Connection Manager after the authentication process is complete. This must be the full URL that a user would enter into their browser to access Keeper Connection Manager. The URI that should be submitted to the OpenID service such that they can redirect the authenticated user back to Keeper Connection Manager after the authentication process is complete. This must be the full URL that a user would enter into their browser to access Keeper Connection Manager. |
| The amount of clock skew tolerated for timestamp comparisons between the Guacamole server and OpenID service clocks, in seconds. By default, clock skew of up to 30 seconds is tolerated. |
| The claim type within any valid JWT that contains the list of groups of which the authenticated user is a member. By default, the “groups” claim type is used. |
| The maximum amount of time that a nonce generated by the Guacamole server should remain valid, in minutes. As each OpenID request has a unique nonce value, this imposes an upper limit on the amount of time any particular OpenID request can result in successful authentication within Guacamole. By default, each generated nonce expires after 10 minutes. |
| The maximum amount of time that an OpenID token should remain valid, in minutes. By default, each OpenID token remains valid for 300 minutes (5 hours). |
| The space-separated list of OpenID scopes to request. OpenID scopes determine the information returned within the OpenID token, and thus affect what values can be used as an authenticated user’s username. To be compliant with OpenID, at least “openid profile” must be requested. By default, “openid email profile” is used. |
| The claim type within any valid JWT that contains the list of groups of which the authenticated user is a member. By default, the “groups” claim type is used. |
| The hostname or IP address of the PostgreSQL server hosting the Guacamole database. |
| The name of the database that has been created for Guacamole on the PostgreSQL server. |
| The username that Guacamole should use when authenticating with the PostgreSQL server. |
| The password that Guacamole should provide when authenticating with the PostgreSQL server. |
| The TCP port that the PostgreSQL server is listening on. If omitted, the standard PostgreSQL port of 5432 will be used. |
| The minimum length to require for user passwords. By default, password complexity is not enforced. |
| If set to "true", require that user passwords use both uppercase and lowercase characters. |
| If set to "true", require that user passwords contain at least one symbol. By default, password complexity is not enforced. |
| If set to "true", require that user passwords contain at least one digit. By default, password complexity is not enforced. |
| If set to "true", disallow user passwords that contain the user's username. By default, password complexity is not enforced. |
| The minimum number of days that must elapse following a password change before the user may change their password again. By default, users are not required to wait before changing their password. |
| The maximum number of days that may elapse since the last password change before the user is required to change their password. By default, users are not required to regularly change their password. |
| Remember this number of previous passwords and prohibit reuse of those passwords when the user's password is changed. By default, users are allowed to reuse previous passwords. |
| The maximum number of concurrent connections to allow to any particular connection, regardless of user, where a value of "0" indicates unlimited. By default, concurrent usage of connections is not limited. |
| The maximum number of concurrent connections to allow to any particular connection group, regardless of user, where a value of "0" indicates unlimited. By default, concurrent usage of connection groups is not limited. |
| The maximum number of concurrent connections to allow each user to hold to any particular connection, where a value of "0" indicates unlimited. By default, user-specific concurrent usage of connections is not limited. |
| The maximum number of concurrent connections to allow each user to hold to any particular connection group, where a value of "0" indicates unlimited. By default, user-specific concurrent usage of connection groups is limited to one. |
| The maximum number of concurrent connections to allow to overall, regardless of user, connection or connection group, where a value of "0" indicates unlimited. By default, overall concurrent usage is not limited. |
| If set to "true", require that each user have a corresponding account defined within the database, even if the user authenticated through some other mechanism (such as LDAP). By default, users that successfully authenticate through another mechanism are not required to also have an account within the database. |
| Whether connections that do not exist within the database should have connection history tracked in the database. If set to "true", connection history records will be created for any connection established. If set to "false", connection history records will be created only for connections defined in the database. By default, external connections will be tracked. |
| Whether access time restrictions imposed by the administrator on user accounts should be enforced while a user is logged in. If set to "true", users will be automatically logged out within roughly one minute of reaching their access time limits. If set to "false", access time restrictions will only be enforced at the moment a user attempts to log in. By default, access time restrictions are enforced while users are logged in. |
| Whether user account entries should automatically be created within the database for users that successfully authenticate through other means, such as an SSO provider or LDAP. This may be necessary if using an extension that requires account-specific storage, like TOTP or per-account approvals. If set to "true", user account entries will automatically be created. By default, administrators must manually create such entries if needed. |
Require approval for logins from SAML. |
|
Require approval for logins from SAML and LDAP. |
|
| The URI that should be submitted to the SAML service such that they can POST the authentication result to Keeper Connection Manager and redirect the user back to the application. This must be the full URL that a user would enter into their browser to access Keeper Connection Manager. |
| Enable compression of the HTTP requests sent to the SAML IdP. This property is optional and will default to true (compression enabled). |
| Request that the SAML response returned by the IdP be compressed. This property is optional and will default to true (compression will be requested). |
| The entity ID of the Guacamole SAML client, which is generally the URL of the Guacamole server, but is not required to be so. This property is required if either the saml-idp-metadata-url property is not specified, or if the provided metadata file does not contain the SAML SP Entity ID for Guacamole Client. |
| The name of the attribute provided by the SAML IdP that contains group membership of the user. These groups will be parsed and used to map group membership of the user logging in, which can be used for permissions management within Guacamole Client, particularly when layered with other authentication modules. This property is optional, and defaults to “groups”. |
| The URI of the XML metadata file that from the SAML Identity Provider that contains all of the information the SAML extension needs in order to know how to authenticate with the IdP. This URI can either be a remote server (e.g. https://) or a local file on the filesystem (e.g. file://). Often the metadata file contains most of the required properties for SAML authentication and the other parameters are not required. |
| The base URL of the SAML IdP. This is the URL that the SAML authentication extension will use to redirect when requesting SAML authentication. If the saml-idp-metadata-url property is provided, this parameter will be ignored. If the metadata file is not provided this property is required. |
| The full path of the private key in PEM format that should be used to sign SAML requests submitted to the SAML IdP. This is required only if the SAML IdP requires signed requests. By default, SAML requests are not signed. |
| The full path of the X.509 certificate in PEM format that should be used to sign SAML requests submitted to the SAML IdP. This is required only if the SAML IdP requires signed requests. By default, SAML requests are not signed. |
| The hostname or IP address of the SQL Server instance hosting the Guacamole database. |
| The name of the database that has been created for Guacamole on the SQL Server instance. |
| The username that Guacamole should use when authenticating with the SQL Server instance. |
| The password that Guacamole should provide when authenticating with the SQL Server instance. |
| The TCP port that the SQL Server instance is listening on. If omitted, the standard SQL Server port of 1433 will be used. |
| The minimum length to require for user passwords. By default, password complexity is not enforced. |
| If set to "true", require that user passwords use both uppercase and lowercase characters. |
| If set to "true", require that user passwords contain at least one symbol. By default, password complexity is not enforced. |
| If set to "true", require that user passwords contain at least one digit. By default, password complexity is not enforced. |
| If set to "true", disallow user passwords that contain the user's username. By default, password complexity is not enforced. |
| The minimum number of days that must elapse following a password change before the user may change their password again. By default, users are not required to wait before changing their password. |
| The maximum number of days that may elapse since the last password change before the user is required to change their password. By default, users are not required to regularly change their password. |
| Remember this number of previous passwords and prohibit reuse of those passwords when the user's password is changed. By default, users are allowed to reuse previous passwords. |
| The maximum number of concurrent connections to allow to any particular connection, regardless of user, where a value of "0" indicates unlimited. By default, concurrent usage of connections is not limited. |
| The maximum number of concurrent connections to allow to any particular connection group, regardless of user, where a value of "0" indicates unlimited. By default, concurrent usage of connection groups is not limited. |
| The maximum number of concurrent connections to allow each user to hold to any particular connection, where a value of "0" indicates unlimited. By default, user-specific concurrent usage of connections is not limited. |
| The maximum number of concurrent connections to allow each user to hold to any particular connection group, where a value of "0" indicates unlimited. By default, user-specific concurrent usage of connection groups is limited to one. |
| The maximum number of concurrent connections to allow to overall, regardless of user, connection or connection group, where a value of "0" indicates unlimited. By default, overall concurrent usage is not limited. |
| If set to "true", require that each user have a corresponding account defined within the database, even if the user authenticated through some other mechanism (such as LDAP). By default, users that successfully authenticate through another mechanism are not required to also have an account within the database. |
| Whether connections that do not exist within the database should have connection history tracked in the database. If set to "true", connection history records will be created for any connection established. If set to "false", connection history records will be created only for connections defined in the database. By default, external connections will be tracked. |
| Whether access time restrictions imposed by the administrator on user accounts should be enforced while a user is logged in. If set to "true", users will be automatically logged out within roughly one minute of reaching their access time limits. If set to "false", access time restrictions will only be enforced at the moment a user attempts to log in. By default, access time restrictions are enforced while users are logged in. |
| Whether user account entries should automatically be created within the database for users that successfully authenticate through other means, such as an SSO provider or LDAP. This may be necessary if using an extension that requires account-specific storage, like TOTP or per-account approvals. If set to "true", user account entries will automatically be created. By default, administrators must manually create such entries if needed. |
| A wildcard URI that points to this Guacamole instance and requests SSL/TLS client authentication. |
| A non-wildcard URI that points to this Guacamole instance and does not request SSL/TLS client authentication. |
| The name of the header to use to retrieve the URL-encoded client certificate from an HTTP request received from an SSL termination service providing SSL/TLS client authentication. By default, |
| The name of the header to use to retrieve the verification status of the certificate an HTTP request received from an SSL termination service providing SSL/TLS client authentication. This value of this header must be "SUCCESS" (all uppercase) if the certificate was successfully verified. By default, |
| The amount of time that the temporary, unique subdomain generated for SSL/TLS authentication may remain valid, in minutes. By default, temporary subdomains are valid for 5 minutes. |
| The amount of time that a temporary authentication token for SSL/TLS authentication may remain valid, in minutes. By default, temporary authentication tokens are valid for 5 minutes. |
| The base DN containing all valid subject DNs. If specified, only certificates asserting subject DNs beneath this base DN will be accepted. By default, all DNs are accepted as long as the certificate is valid. |
| The LDAP attribute or attributes that may be used to represent a username within the subject DN of a user's X.509 certificate. If the least-significant attribute of the subject DN is not one of these attributes, the certificate will be rejected. By default, any attribute is accepted and used as the username. |
| The human-readable name of the entity issuing user accounts. By default, this is "Apache Guacamole". |
| The number of digits which should be included in each generated code. TOTP allows for 6-, 7-, or 8-digit codes. Longer or shorter codes than this are not possible as they violate the TOTP standard. By default, 6-digit codes will be used. |
| The duration that each generated code should remain valid, in seconds. The code generation period is given in positive integer seconds and may be any value, however the value should be long enough to allow the user a reasonable amount of time to enter their code. Their authentication device will generate a new code after this period elapses. By default, generated codes are valid for 30 seconds. |
| The hash algorithm that should be used to generate codes. Valid TOTP modes (hashes) are "sha1", "sha256", and "sha512". By default, "sha1" is used. |
| The base URL of the UDS Enterprise deployment that may leverage Keeper Connection Manager to provide remote access. Keeper Connection Manager will use this URL to contact UDS to authenticate and authorize connection requests. |
guacamole.properties.docker
Docker deployment of guacd with Keeper Connection Manager
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 keeper/guacamole
image.
To start a guacd instance which listens on TCP port 4822:
where some-guacd
is the name you wish to assign to your container.
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.
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.
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 that use SSL/TLS.
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".
Docker deployment of MySQL with Keeper Connection Manager
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.
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.
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:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| If set to "true", users will be allowed to provide their own KSM configuration or one-time token. Vault records of users that provide this will be additionally considered for any connection that (1) an administrator enables for use with user vaults and (2) contains a token that cannot be satisfied with a record from the system-wide vault configured with |
| The minimum number of milliseconds that must elapse between API calls to Keeper Secrets Manager. By default, KCM will wait 10 seconds between each call, using cached data from the last retrieval until another retrieval attempt is allowed. |
| The Keeper Secrets Manager b64 configuration, generated by Keeper Commander. |
| If set to "true", Active Directory domains within KSM records and KCM connections will be considered when determining whether a record matches a username. By default, only the username itself is considered. |
|
| Static tokens used to identify specific Keeper vault records and fields. |
| Used for protection and storage of configuration values in the Keeper vault. |
|
| The TCP port that the LDAP server is listening on. If omitted, the standard LDAP or LDAPS port will be used, depending on the encryption method. Unencrypted LDAP uses the standard port of 389, while LDAPS uses port 636. |
| The encryption mechanism to use when communicating with your LDAP server, if any. Legal values are "none" for unencrypted LDAP, "ssl" for LDAP over SSL/TLS (commonly known as LDAPS), or "starttls" for STARTTLS. If omitted, encryption will not be used. |
|
| The maximum amount of time to allow for any LDAP query, in seconds. By default, LDAP queries will time out after 30 seconds. |
| The attribute which contains the username within all relevant user objects in the LDAP directory. If multiple attributes may contain the username, multiple attributes may be specified separated by commas, and a search DN is required. |
| The DN that the web application should bind as when determining the DN of the user attempting to authenticate. Specifying a search DN is required if usernames may be within any one of several attributes, or if the user's username is not part of their DN. |
| The password to use when authenticating with the search DN. |
| The common base DN shared by all |
| The common base DN shared by all user groups which may dictate |
| The maximum number of results to attempt to retrieve from the LDAP directory for any particular search. Searches which exceed this limit will fail. By default, searches are limited to 1000 entries. |
| The LDAP search filter to use when querying user accounts. If omitted, |
| The LDAP search filter to use when retrieving groups. If omitted, |
| Whether aliases should be automatically dereferenced. Legal values are "never", "searching" (dereference only after the base DN is located), "finding" (dereference only when locating the base DN), and "always". By default, aliases are not derefenced. |
| If "true", automatically follow referrals received from the LDAP directory. By default, LDAP referrals are not followed. |
| The maximum number of referrals that may be followed when resolving any particular LDAP referral. By default, if LDAP automatic following of referrals is enabled, up to 5 hops are allowed for any one referral. |
| 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 LDAP servers that use SSL/TLS. |
Docker deployment of Pre-Initialized Database Images with Keeper Connection Manager
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
.
Deployment of Keeper Connection Manager using Docker Compose
This section describes how to install Keeper Connection Manager using Docker by building a customized docker-compose orchestration file.
Windows
Install Docker Desktop following Docker's official instructions.
Amazon Linux 2
Install Docker on your instance. A nice step by step guide is published here.
CentOS7, RHEL
In addition to installing Docker, please install the haveged
package to ensure that the environment is capable of generating enough entropy for creating secure random numbers.
Ubuntu
Install the haveged
package to ensure that the environment is capable of generating enough entropy for creating secure random numbers.
Now that you have Docker running on your instance, you need to generate a docker-compose.yml file that must be transferred to a working directory on your machine.
An example docker-compose.yml
file for a deployment of Keeper Connection Manager which uses Let's Encrypt for its SSL certificate and an automatically-initialized database for authentication is provided below with a MySQL and PostgreSQL option.
Copy this file to your target KCM instance. Please note that you'll need to modify a few of the fields immediately:
GUACAMOLE_PASSWORD and MYSQL_PASSWORD need to match, and should be a randomly generated strong password. We recommend using your Keeper vault for generating a password. Avoid using special characters like backslashes, dollar signs and forward slashes.
GUACAMOLE_ADMIN_PASSWORD is the password for the default "guacadmin" user login. This should be a strong and randomly generated password. We recommend using your Keeper vault for generating a password. Avoid using special characters like backslashes, dollar signs and forward slashes.
SSL_HOSTNAME needs to be the FQDN you set up to point to this server. Make sure that the DNS is routable to the IP from the outside world, and ports 80/443 are open so that Let's Encrypt can register the certificate.
Copy this file to your target KCM instance. Please note that you'll need to modify a few of the fields immediately:
GUACAMOLE_PASSWORD and POSTGRES_PASSWORD need to match, and should be a randomly generated strong password. We recommend using your Keeper vault for generating a password. Avoid using special characters like backslashes, dollar signs and forward slashes.
GUACAMOLE_ADMIN_PASSWORD is the password for the default "guacadmin" user login. This should be a strong and randomly generated password. We recommend using your Keeper vault for generating a password. Avoid using special characters like backslashes, dollar signs and forward slashes.
SSL_HOSTNAME needs to be the FQDN you set up to point to this server. Make sure that the DNS is routable to the IP from the outside world, and ports 80/443 are open so that Let's Encrypt can register the certificate.
If you plan to use a custom SSL certificate instead of Let's Encrypt, replace the "ssl" section of the Docker Compose file with a section that looks like this:
In this case, CERTIFICATE_FILE
is the PEM-encoded certificate including the intermediate certificate chain. The PRIVATE_KEY_FILE
is the private key file.
Also, note that in the above snippet, there is a volume mount that assigns the local filesystem to the target container. You should only modify the C:\Users\Path\To\Cert
portion of the string. On linux environments it will be /path/to/cert
.
On Windows, open a Command Prompt. On Linux, open the terminal shell. Navigate to the location of the docker-compose.yml
file that was saved in step 2.
To start up the environment, simply type the below command:
Note: Some versions require "docker-compose" with a hyphen.
That's it. If everything is successful, you can open the Keeper Connection Manager login screen on the specified FQDN.
If you have not set up a proper domain name routing to the server, you can temporarily host-hack the local system in order to at least access the user interface and start testing.
If you're using your own SSL certificate, we don't recommend using a wildcard cert. A certificate that has been explicitly created for the Keeper Connection Manager endpoint is the best practice since you'll be storing the SSL private key on the device.
If you're using Windows, you will need to modify your Windows Defender Firewall to open up ports 443 to the Docker service.
Running docker compose down
will delete all data in the container including users, connections and history. To simply stop the containers, use docker compose stop
.
Below is a description of each of the images.
Now that your Keeper Connection Manager instance is running, you can login as guacadmin and start setting up some connections. Follow the Using Keeper Connection Manager documentation for next steps.
The next several sections of this installation guide provide detailed information about each specific Docker image, if you plan to customize or modify the environment.
Docker deployment of NGINX with Keeper Connection Manager for SSL Termination
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.
If set to "true", Active Directory domains within KSM records will be alternatively determined by splitting the record username into username and domain components. Splitting is performed based on . By default, usernames are not split, and Windows domains will be read only from a separate "Domain" field on the record.
The full contents of the file describing the LDAP servers that Guacamole should use for authentication.
The maximum amount of time to allow for any LDAP network operation, in milliseconds, including attempts to connect to the LDAP server. By default, LDAP network operations will time out after 30 seconds (30000 milliseconds). Note that this value is intentionally more granular than LDAP_OPERATION_TIMEOUT
, as failover to alternative LDAP servers may need to occur quickly
Image name | Base image | Description |
---|---|---|
Image name | Base image | Description |
---|---|---|
Image name | Base image | Description |
---|
Requires the same ACCEPT_EULA
environment variable as the and images.
See the to view configuration examples.
An instance of MySQL, automatically initialized with the Apache Guacamole database schema.
An instance of PostgreSQL, automatically initialized with the Apache Guacamole database schema.
The Apache Guacamole web application, deployed under Apache Tomcat.
The Apache Guacamole proxy daemon, guacd, with support for native protocols such as RDP and SSH.
An instance of MySQL, automatically initialized with the Apache Guacamole database schema.
An instance of PostgreSQL, automatically initialized with the Apache Guacamole database schema.
An instance of NGINX which automatically provides SSL termination for Keeper Connection Manager.
kcm-guacamole-auth-jdbc-mysql
kcm-guacamole-auth-jdbc-postgresql
kcm-guacamole-auth-jdbc-sqlserver
kcm-guacamole-auth-uds
Backup and recovery options
Keeper Connection Manager is packaged and installed in your environment. As such, backups should be taken in order to recover the environment if required.
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.
For Docker installs, 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 deployment of Postgres with Keeper Connection Manager
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.
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.
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:
How to deploy a custom SSL Certificate to Keeper Connection Manager
This page provides details on how to create an SSL certificate for use with the Keeper Connection Manager service.
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.
Ensure that the SSL certificate created for your KCM instance is only used for this purpose. Do not use a wildcard certificate that is shared with other services.
If you don't have a provider already, a good site is: https://www.ssls.com/
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:
On an annual basis, you will need to renew your cert. Most certificate providers will generate a new cert for you. After certificate renewal, you need to replace the certificate file and restart the service.
Docker deployment of NGINX for SSL termination with Keeper Connection Manager
Image: keeper/guacamole-ssl-nginx
keeper/guacamole-ssl-nginx
is a Dockerized deployment of NGINX, built off Docker's official Nginx image which is pre-configured to provide SSL termination for Guacamole. It supports:
Usage of an existing certificate that you have already obtained from a certificate authority.
This image is produced as part of Keeper Connection Manager and made available under the same EULA. It is normally used to provide SSL termination for a container using the keeper/guacamole
image.
The keeper/guacamole-ssl-nginx
supports several mechanisms for generating, retrieving, or using existing SSL certificates. The mechanism used depends on which environment variables are specified when the Docker container is created.
In addition to these mechanism-specific environment variables, there is a set of environment variables that must always be specified:
ACCEPT_EULA
- Whether you accept the Keeper Connection Manager EULA (acceptance of the EULA is required to use the image).
GUACAMOLE_HOSTNAME
- The hostname/address of the Guacamole instance.
SSL_HOSTNAME
- The public domain name that will be used to access Guacamole.
Let's Encrypt is used by default if no existing certificate is supplied and generation of a self-signed certificate is not requested. The keeper/guacamole-ssl-nginx
image will reach out to the Let's Encrypt service using the "certbot" tool to retrieve an SSL certificate.
Only one environment variable specific to Let's Encrypt is strictly required if using Let's Encrypt certificates:
LETSENCRYPT_ACCEPT_TOS
- Whether you accept the Let's Encrypt Terms of Service (acceptance of Let's Encrypt's Terms of Service is required to use that service).
In addition to accepting their Terms of Service, beware that Let's Encrypt strongly recommends providing an email address so that you can get important alerts regarding your certificate. You should additionally provide an email address unless you have a reason not to do so:
LETSENCRYPT_EMAIL
- The email address to submit to Let's Encrypt when requesting the certificate.
If you are just testing usage of Let's Encrypt, you should use the Let's Encrypt staging/testing environment instead of the production environment:
LETSENCRYPT_STAGING
- Set to "Y" to use Let's Encrypt's staging environment instead of production.
The retrieved certificate be automatically renewed by the image when necessary. If retrieval fails, the container will stop, details describing the failure will be logged, and the process will be retried the next time the container starts.
The keeper/guacamole-ssl-nginx
image leverages Docker volumes to enable Let's Encrypt certificates and state to persist across container recreation.
For example, below will generate a Let's Encrypt certificate in your docker-compose.yml file:
If you already have a certificate that you obtained from a certificate authority, you can use that certificate by pointing to the relevant files with the CERTIFICATE_FILE
and PRIVATE_KEY_FILE
environment variables. The relevant files will need to be exposed to the image using Docker volume mounts.
CERTIFICATE_FILE
- The full path to the certificate PEM file.
PRIVATE_KEY_FILE
- The full path to the private key PEM file.
When your certificate comes up for renewal with your CA, you will need to replace the certificate and private key and reload NGINX. Stop and start the Docker Compose after the certificate has been updated.
For Docker Compose configuration, the example below will load a custom certificate from a shared volume that will hold the keys.
If deploying for testing, the image can automatically generate and maintain its own self-signed certificate:
SELF_SIGNED
- Set to "Y" to automatically generate a self-signed certificate for testing.
The keeper/guacamole-ssl-nginx
image will regenerate the self-signed certificate on startup. As the certificate expires 30 days after generation, the image will also automatically regenerate the certificate every 21 days to ensure it does not expire.
The certificate expiration date and fingerprints will be logged each time the certificate is regenerated, allowing rudimentary server identity verification.
In addition to the environment variables documented below, all environment variables supported by the official Docker Nginx image are accepted, as the official NGINX 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.
SSL_HOSTNAME
The public-facing hostname of the server hosting Docker. This environment variable is required and should be the full public domain name that will be used to access Guacamole over the internet, already associated with the IP address that reaches the server running Docker and this image.
GUACAMOLE_HOSTNAME
The internal hostname or IP address of the Guacamole server. This environment variable is required, and should be the hostname/address that NGINX will connect to internally when servicing connections.
Note that the Guacamole service whose hostname/address is provided here should be reachable only on the internal network. Only the SSL terminating service (this image) should be public-facing.
GUACAMOLE_PORT
The TCP port number that the Guacamole server is listening on. This environment variable is optional. If omitted, the typical port 8080 will be used by default.
GUACAMOLE_CONTEXT_PATH
The path that Guacamole is being served beneath. This environment variable is optional. By default, this will be blank, representing that Guacamole is being served from the root path. As with the GUACAMOLE_CONTEXT_PATH
environment variable of the keeper/guacamole
image, this parameter may not contain slashes.
For example, if Guacamole is running internally at http://some-host/guacamole/
, you would set GUACAMOLE_CONTEXT_PATH
to guacamole
.
SELF_SIGNED
If set to "Y", requests that a self-signed certificate be automatically generated for SSL_HOSTNAME
rather than using an existing certificate or retrieving a new certificate from Let's Encrypt.
Self-signed certificates are inherently insecure. This option should be used only for testing.
CERTIFICATE_FILE
and PRIVATE_KEY_FILE
The paths of the PEM files for the SSL certificate and associated private key, respectively. These paths are relative to the filesystem of the Docker container. Externally-provided SSL certificate PEM files will need to be exposed within the container using Docker volume mounts.
These environment variables are only required if providing your own certificate. They will be ignored if using a self-signed certificate for testing with SELF_SIGNED
.
LETSENCRYPT_ACCEPT_TOS
If intending to use Let's Encrypt, the LETSENCRYPT_ACCEPT_TOS
environment variable must be set to "Y" to indicate your acceptance of the Let's Encrypt Terms of Service. Let's Encrypt cannot be used unless you agree to the relevant Terms of Service.
This environment variable is only required if using Let's Encrypt. It is ignored if providing your own certificate using CERTIFICATE_FILE
and PRIVATE_KEY_FILE
, or if using a self-signed certificate for testing with SELF_SIGNED
.
LETSENCRYPT_EMAIL
The email address that should be provided to Let's Encrypt when requesting a certificate. This environment variable is optional and is ignored if providing your own certificate using CERTIFICATE_FILE
and PRIVATE_KEY_FILE
, or if using a self-signed certificate for testing with SELF_SIGNED
.
While this environment variable is optional, beware that Let's Encrypt strongly recommends providing an email address when obtaining a certificate using their service. From the help content for the certbot tool:
... This is strongly discouraged, because in the event of key loss or account compromise you will irrevocably lose access to your account. You will also be unable to receive notice about impending expiration or revocation of your certificates. Updates to the Subscriber Agreement will still affect you, and will be effective 14 days after posting an update to the web site.
LETSENCRYPT_STAGING
If set to "Y", requests that the Let's Encrypt staging environment be used to retrieve an SSL certificate, rather than the production environment. This option should be used if you are just testing the Let's Encrypt functionality.
Content Security Policy (CSP) is a browser feature that allows web applications like KCM to declare to the browser what types of operations should be allowed in the context of that web application. In particular, CSP allows web applications to request that the browser block attempts to load resources or run scripts that the web application considers unsafe or unexpected. This is done by adding a Content-Security-Policy
header to HTTP responses.
A default Content-Security-Policy
header with known-good default value is set automatically by the keeper/guacamole-ssl-nginx
image unless configured otherwise using the CONTENT_SECURITY_POLICY
environment variable.
It is not typically necessary set this environment variable except in cases where custom KCM/Guacamole extensions require a more lenient policy.
Be careful if overriding the default policy is necessary. An overly-strict CSP can easily prevent KCM from performing core required tasks, such as decoding graphical data or making requests to its own REST API.
CONTENT_SECURITY_POLICY
Configures the value of the Content-Security-Policy
header that will be sent in responses from Nginx.
If set to "Y", a reasonable default Content-Security-Policy
value will be set that's known to work with most KCM installations: script-src 'self' 'unsafe-eval'; default-src 'self' data:; style-src 'self' 'unsafe-inline';
. This configuration allows loading of assets from the same domain as KCM, along with allowing eval()
for translations, and allowing JavaScript to dynamically load CSS.
If set to "N", the header will not be added to responses.
If this variable is set to any other value, the literal value of the variable will be sent with the response.
HTTP Strict Transport Security (HSTS) is a browser feature that allows the owners of a domain to advise browsers that connections should only use HTTPS, and that any HTTP connections should be upgraded to HTTPS before being sent.
As HSTS is not always appropriate for all deployments of KCM, particularly if KCM will share a domain with other web applications that do not all support HTTPS, installations of KCM do not enable HSTS by default.
The STRICT_TRANSPORT_SECURITY
environment variable must be set to a value to enable HSTS. A recommended default is available for convenience.
STRICT_TRANSPORT_SECURITY
Configures the value of the Strict-Transport-Security
header that will be sent in responses from Nginx.
If set to "Y", a reasonable default Strict-Transport-Security
value will be set: 'max-age=31536000; includeSubDomains; preload;' always
, as recommended by https://https.cio.gov/hsts/.
If set to "N", the header will not be added to responses.
If this variable is set to any other value, the literal value of the variable will be sent with the response.
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 Let's Encrypt account email from Docker secrets:
The environment variables in this section are only needed in unusual cases, such as when serving KCM from a non-standard port or when older ciphers or versions of SSL must be enabled. Do not set these variables unless you are certain that doing so is necessary.
SSL_CIPHERS
Configures the allowable SSL ciphers for the Nginx instance. For information on the allowable values for this parameter, see the Nginx documentation. If not otherwise specified, the value will default to "HIGH:!aNULL:!MD5"
.
SSL_PROTOCOLS
Configures the allowable SSL protocols for the Nginx instance. For information on the allowable values for this parameter, see the Nginx documentation. If not otherwise specified, TLS 1.2 and 1.3 will be enabled.
SSL_EXTERNAL_PORT
Configures value of the X-Forwarded-Port
header that will be sent to the KCM web application in requests from Nginx. This header advises the KCM server know that SSL requests are being received at a non-standard port.
If a non-standard port is used for SSL, this port must additionally be mapped to the standard port, e.g. -p 8443:443
. Setting this variable has no impact on the ports used by Nginx internally within the image.
If not specified, KCM will expect that inbound requests are coming from the standard HTTPS port (443).
ADDITIONAL_CONFIG
Arbitrary configuration for the server
block that points at the KCM web application in the Nginx configuration files generated by this image.
This variable functions as a catch-all for applying Nginx configuration options that do not have corresponding environment variables in the keeper/guacamole-ssl-nginx
image.
Any value provided via the ADDITIONAL_CONFIG
environment variable will be included in the main server
block pointing at the KCM web application. Only configuration options that Nginx will accept within a server
block may be included here.
An instance of NGINX which automatically provides SSL termination for Keeper Connection Manager. |
Configuration of Keeper Connection Manager Authentication methods
Instructions for authenticating users with a SAML 2.0 / SSO Identity Provider
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.
Run the reconfigure
command listed below and press enter to accept all the pre-populated selections until you get to the SAML prompt.
Make sure you have transferred your metadata XML file onto the KCM server first.
Select Local metadata file (option 1). Enter the proper path where the XML file is located.
Remote metadata file (option 2) is easiest if you can get a URL that points to your idP's metadata XML file (Azure provides this).
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.
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!
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.
(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.
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
Configuration is 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:
Keeper Connection Manager SAML configuration with Google Workspace
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.
Google Group to Keeper Connection Manager Group mapping is through the Group Name. If the Keeper Connection Manager contains a Group that has the name corresponding to the Google Group Name, the user will receive all Keeper connections assigned to that user group.
(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.
Keeper Connection Manager SAML configuration with Okta
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.
Okta Group to Keeper Connection Manager Group mapping is through the Group Name. If the Keeper Connection Manager contains a Group that has the name corresponding to the Okta Group Name, the user will receive all Keeper connections assigned to that user group.
(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.
Keeper Connection Manager SAML configuration with OneLogin
The first step regardless of installation method is to configure your SAML 2.0 identity provider.
You must have OneLogin developer account.
Configure OneLogin
Search for SAML, and select SAML Test Connector (IdP).
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.
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.
Click on the More Actions dropped-down menu. Select SAML Metadata to download and save the .XML file.
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.
Log in to the Dashboard, and click Administration. Then Applications > Add App.
This page documents the process of integrating PingIdentity with Keeper Connection Manager, which is also known as KCM. We will be adding SAML 2.0 application connectors between the two platforms.
Login as an Administrator for PingIdentity. From the PingIdentity menu, click Applications > Add Application
Give the Application a name such as "KCM," select SAML and Save.
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
Then add the URL of your KCM server to the Entity ID box as follows: https://<YOUR DOMAIN> and press Save.
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.
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.
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.
Download the Metadata file from the Configuration tab, and ensure that it is named to metadata.xml.
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.
Keeper Connection Manager SAML configuration with Microsoft Azure
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.
For hybrid environments, if the group originates from on-prem AD, you may need to change the display name of the security group.
If you would like to automatically mapp 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.
Azure Group to Keeper Connection Manager Group mapping is unique. KCM will not show a list of the members of a group, however, group member users will have access to any connections that are assigned to the group.
(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:
Integrating TOTP based authentication for 2FA
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.
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.
For example:
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.
Integrating Duo with Keeper Connection Manager for 2FA/MFA
Keeper Connection Manager provides support for Duo as a second authentication factor, automatically verifying user identity with Duo after the user is initially authenticated.
To set up Duo, see the DUO_* configuration parameters in the keeper/guacamole Docker image.
The Duo “Web SDK” requires that an arbitrary and random key be generated for each application. This key resides strictly on the side of the application, and is not registered with Duo.
Any random value containing at least 40 characters will suffice. To quickly grab 40 random characters from /dev/random
:
The image keeper/guacamole
can be modified to support TOTP using environmental variables. See the TOTP_* variables defined in the .
The image keeper/guacamole
can be modified to support Duo using environment variables. See the DUO_* variables defined in the .
Requiring SSL/TLS Client Authentication with KCM
Keeper Connection Manager can be configured to require SSL/TLS client authentication.
To implement device-based access security with Keeper Connection Manager, this can be accomplished using NGINX client certificates. A client certificate is installed into the web browser of your user's approved devices, and the server will only accept communication from a device with the client certificate installed.
The steps to activate this advanced level of protection is described in the steps below.
(1) Create a Certificate Authority (CA) Key
Generate a CA Key with a strong auto-generated passphrase. Make sure to store the passphrase in your Keeper vault.
(2) Create a CA Certificate
A certificate is created with the CA Key. When answering the questions, you can leave the Common Name and Email empty. Save the information that you entered for Country, State, Locality, and Organization, because you may need these later when renewing the certificate.
Side Note: to analyze the certificate parameters, you can run the below command.
(3) Create a Client Key
For the end-user devices, a client key must be generated. You can decide if you would like to generate one key for all devices, or each user can generate their own key and request a certificate. The process is up to you. Generate a client key with a strong auto-generated passphrase. Make sure to store the passphrase in your Keeper vault.
(4) Create a CSR
For each Client Key, generate a CSR to create a signed certificate.
(5) Sign the CSR with the CA Key
You'll need to enter the CA passphrase from Step 1 to sign the request.
At this point, you now have a signed Client Certificate (client.crt).
(6) Convert the Client Certificate to PKCS#12
To import the certificate into a web browser, a pfx file in PKCS#12 is typically required. Generate the client.pfx file using the command below. A passphrase will be required. This passphrase will be provided to each of the users who need to install the certificate, so it should be used specifically for this purpose.
(7) Add to NGINX Config
The keeper/guacamole-ssl-nginx
image can be configured to require SSL/TLS client authentication by specifying the CLIENT_CERTIFICATE_FILE
environment variable. A user will only be able to connect to the KCM instance of NGINX using their browser if their browser has access to a private key that is signed by this certificate.
This variable is similar to the CERTIFICATE_FILE
environment variable in that it points to a file within the container, but in this case it controls the certificate used to authenticate the client’s private key.
Example:
After updating the configuration, restart the containers.
(8) Test the configuration
Before installing the client certificate on the user's machine, load up the Keeper Connection Manager login screen to ensure that a 403 error is sent:
(9) Install the Client Certificate
For each end-user client device that will need access to Keeper Connection Manager, you will need to install the client certificate into the user's browser or machine. The installation of client certificates varies by platform.
On Windows
Double-click or right-click the client certificate (client.pfx) from Step 6 and enter the client certificate passphrase.
Restart the browser.
The next time Keeper Connection Manager is loaded, you can approve the certificate.
On Mac OS - Chrome
Import the client.pfx file by double-clicking or loading into the Keychain login Certificates section. In the "Trust" section of the certificate, mark as Always Trust.
Restart the browser and load the Keeper Connection Manager login screen to select the certificate.
On Mac OS - Firefox
Open Firefox > Preferences > search for Certificates and select Your Certificates tab. Click "Import" and select the client.pfx certificate file. Complete the import.
After successful import, the Keeper Connection Manager login screen will load.
Additional environment variables are also available to modify SSL/TLS auth behavior further:
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.
Approve or Deny User's ability to authenticate with KSM using SSO
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.
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 logic 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:
Login to Keeper Connection Manager with a PIV/CAC device
KCM allows authentication with the web application using the DoD's Common Access Cards (CAC), as well as with any smart card supported by the browser for SSL client auth such as Personal Identity Verification (PIV).
This feature allows users to authenticate to Keeper Connection Manager using CAC, this does not allow pass-through of CAC to the remote desktop.
A typical configuration for PIV/CAC would be the following:
PIV/CAC support installed and configured to authenticate users against *.login.kcm.example.net
and redirect them back to kcm.example.net
once ready.
Database backend configured to automatically create user accounts for users coming from SSO.
Support for PIV/CAC is configured using Keeper's new support for SSL/TLS client authentication. This support is provided by the “guacamole-auth-sso-ssl” extension, which we package as kcm-guacamole-auth-sso-ssl
. Setting any SSL_*
variable will implicitly include the kcm-guacamole-auth-sso-ssl
package.
The following options are also available, though it would be unusual to need to set them:
The example docker-compose.yml
below uses the following placeholders:
In practice, these values will vary, as will whether the user chooses to use MySQL or PostgreSQL. The example below was written using PostgreSQL.
Prior to configuring the user workflow, make sure to set the REQUIRE_ACCOUNT_APPROVAL
key to the appropriate authentication method.
For PIV/CAC, you would set it to ssl
:
Once you have successfully configured, there will be a new "Use Certificate or Smart Card" link on the login screen of the application as seen below:
For each end-user client device that will need access to Keeper Connection Manager, you may need to install the internal CA as a trusted authority into the user's browser. The installation of CA trusted authority varies by platform.
This support depends on an , a capability that was added to KCM version 2.12.0.
An SSL termination instance configured with : one for normal access (such as kcm.example.net
) and another just for handling , which should ideally be a wildcard domain (such as *.login.kcm.example.net
). The SSL client auth configuration would include the certificate of the CA providing the PIV/CAC cards.
to require approval for users that SSO from PIV/CAC.
The following options will need to be set in the Docker container definition (or in guacamole.properties for linux distributions):
Property | Environment Variable | Description |
---|
Property | Environment Variable | Description | Default Value |
---|
Authenticating with PIV/CAC (or any smart card) via the browser is using . This capability was further enhanced for PIV/CAC by adding convenient configuration options for testing whether certificates have been revoked via OCSP or a CRL. For reference, the following are all options related to SSL/TLS client authentication currently supported by the Docker image:
Environmental Variable | Description | Default Value |
---|
For additional details on user creation workflow, visit this .
Variable
Description
Default
ADDITIONAL_PROXY_CONFIG
Arbitrary, additional NGINX configuration statements that should be included within the location
block that configures NGINX to proxy Guacamole.
SSL_VERIFY_CLIENT
Controls how and whether NGINX requires and verifies the certificate presented by the client (browser), as provided by the NGINX ssl_verify_client
directive.
on
SSL_VERIFY_DEPTH
Controls how deep NGINX will follow through the client’s certificate chain when attempting to validate their certificate, as provided by the NGINX ssl_verify_depth
directive.
1
Authentication Method | Name |
Encrypted JSON |
|
LDAP |
|
OpenID |
|
SAML |
|
SSL/TLS Client Authentication (PIV/CAC) |
|
|
| REQUIRED. A wildcard URI that points to this Guacamole instance and requests SSL/TLS client authentication. |
|
| REQUIRED. A non-wildcard URI that points to this Guacamole instance and DOES NOT request SSL/TLS client authentication. |
|
| The base DN containing all valid subject DNs. If specified, only certificates asserting subject DNs beneath this base DN will be accepted. By default, all DNs are accepted. |
|
| The LDAP attribute or attributes that may be used to represent a username within the subject DN of a user's X.509 certificate. If the least-significant attribute of the subject DN is not one of these attributes, the certificate will be rejected. By default, any attribute is accepted. |
|
| The name of the header to use to retrieve the URL-encoded client certificate from an HTTP request received from an SSL termination service providing SSL/TLS client authentication. This should not normally need to be set, as the defaults of the |
|
|
| The name of the header to use to retrieve the verification status of the certificate an HTTP request received from an SSL termination service providing SSL/TLS client authentication. This value of this header must be "SUCCESS" (all uppercase) if the certificate was successfully verified. This should not normally need to be set, as the defaults of the |
|
|
| The amount of time that the temporary, unique subdomain generated for SSL/TLS authentication may remain valid, in minutes. This subdomain is used to ensure each SSL/TLS authentication attempt is fresh and does not potentially reuse a previous authentication attempt that was cached by the browser or OS. This interval must be long enough to allow for network delays in authenticating the user with the SSL termination service that enforces SSL/TLS client authentication, but short enough that an unused domain does not consume unnecessary server resources and cannot potentially be guessed while that subdomain is still valid. These subdomains are 128-bit secure random values. This should not normally need to be set, though it’s conceivable that an administrator may wish to reduce this value. | 5 |
|
| The amount of time that a temporary authentication token for SSL/TLS authentication may remain valid, in minutes. This token is used to represent the user's asserted identity after it has been verified by the SSL termination service. This interval must be long enough to allow for network delays in receiving the token, but short enough that unused tokens do not consume unnecessary server resources and cannot potentially be guessed while the token is still valid. These tokens are 256-bit secure random values. This should not normally need to be set, though it’s conceivable that an administrator may wish to reduce this value. | 5 |
| Arbitrary, additional NGINX configuration statements that should be included within the |
|
| The certificate that NGINX should use to verify the certificate presented by the SSL/TLS client. |
|
| Controls the certificate revocation list (CRL) file that NGINX should use to check whether a client’s certificate has been revoked, as provided by NGINX This variable will be ignored unless If available, OCSP is often preferable to using a CRL file. |
|
| Controls whether NGINX will use OCSP to check whether a client’s certificate has been revoked, as provided by NGINX This variable will be ignored unless If enabled, | off |
| The DNS server that NGINX should use to resolve domain names. This is only required if OCSP is enabled. |
|
| Controls how and whether NGINX requires and verifies the certificate presented by the client (browser), as provided by NGINX | on |
| Controls how deep NGINX will follow through the client’s certificate chain when attempting to validate their certificate, as provided by NGINX | 1 |
Placeholder | Description |
| Some reasonable password to assign to PostgreSQL’s |
| The name of the Guacamole database within PostgreSQL. This value is used automatically by |
| The limited-privilege PostgreSQL user that Guacamole should use to execute queries against its database. This value is used automatically by |
| Some reasonable password to assign to the PostgreSQL user that Guacamole will use to authenticate with the database as the limited-privilege account |
| The base DN of the subject DNs that should be accepted when presented via SSL/TLS client authentication (smart card authentication via browser). |
| The domain that users will visit with their browsers to use KCM. |
| The path on the Docker host containing the certificates and private keys used for SSL, including for client authentication. |
| The path within the Docker container that |
| The filename of the PEM-format certificate that NGINX should use to validate the certificates it receives from users when they attempt to authenticate with smart cards. |
Instructions for authenticating users with OpenID Connect
Keeper Connection Manager provides support for OpenID Connect for authentication.
The image keeper/guacamole
can be modified to support OpenID using environmental variables. See the OPENID_* variables defined in the documentation.
Instructions for authenticating users with LDAP
Keeper Connection Manager provides support for LDAP authentication.
The image keeper/guacamole
can be modified to support LDAP using environmental variables. See the LDAP_* variables defined in the documentation.
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:
Docker Compose Install:
(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.
Notes:
Replace "https://glyptodon.lurey.com" in 2 spots with your Keeper Connection Manager login URL
(3) Restart the containers
Simple Install:
The containers should restart after the upgrade. If not run:
Custom Install:
Configuration is complete.
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
guacConfigGroup
object classWhen connection data is stored within your LDAP directory, each connection is represented by a special type of LDAP group, and permissions related to Guacamole 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:
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:
To read connection data from LDAP, Guacamole’s main configuration file, 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 Guacamole connections accessible via LDAP. Only connections defined within the subtree of this base DN will be visible.
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 Guacamole if the LDAP_GROUP_BASE_DN
property is defined. This property defines the root of the subtree containing all groups which may apply to Guacamole users authenticated using LDAP:
The EXTENSION_PRIORITY
specifies the order that extensions should be loaded relative to each other. In the following example, all other extensions take priority over LDAP:
If multiple authentication methods are installed, Guacamole 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 Guacamole users against LDAP while storing the connection data for those users within MySQL, PostgreSQL, or SQL Server.
When reading data from multiple authentication methods, Guacamole 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 Guacamole 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, Guacamole 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 Guacamole 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.
For a user known to exist within LDAP, that user can be granted permissions to connections within the database by logging in as the administrative user (by default, “guacadmin”) and creating a corresponding database account having the same username. By leaving the password unspecified for the database account, the user will only be able to log in using LDAP, but will still have access to any associated connections defined within the database.
Rather than having to manually look up users or groups within the LDAP directory, and then manually create those same users and groups within Guacamole, 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 Guacamole’s administrative interface, one of the following tasks must be performed:
An administrative user within the Guacamole 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.
An administrative user must be manually created within Guacamole having the same username as an LDAP user with sufficient privileges to query all Guacamole users and groups defined within LDAP.
Because a Guacamole 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 Guacamole. 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.
Remote connection protocols supported by Keeper Connection Manager
Keeper Connection Manager and Apache Guacamole support multiple protocols through a common, centralized gateway. The "guacd" service sits between the Guacamole web application and the remote desktops and dynamically translates between low-level remote desktop protocols and the Guacamole protocol, applying additional optimization and compression in the process.
Within Keeper Connection Manager, support for each protocol is provided via separate packages. Only the packages for protocols that you will be using need be installed:
When using any particular connection, the package providing support for that connection's underlying protocol must already be installed on the server running the guacd service. If support for the underlying protocol has not been installed, users attempting to use the connection will see an error message, and system administrators will see a message like the following within the systemd journal:
When using one of the supported databases, administrators can define new connections using Guacamole's web interface, selecting the protocol to be used for that connection from a dropdown menu labeled "Protocol":
Advanced configuration of Remote Desktop Protocol connection type
If such an error appears within the guacd logs, simply installing kcm-libguac-client-rdp
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of RDP support to take effect.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
RDP connections are established over TCP to a specific port and a specific hostname or IP address. The hostname/address must be specified for all RDP connections, but you only need to specify a port if you are not using the standard RDP port (3389).
RDP provides authentication through the use of a username, password, and optional domain. All RDP connections are encrypted, with higher-grade encryption available in the form of TLS.
Microsoft's remote desktop server provides an additional gateway service which allows external connections to be forwarded to internal RDP servers which are otherwise not accessible. If you will be using Guacamole to connect through such a gateway, you will need to provide additional parameters describing the connection to that gateway, as well as any required credentials.
RDP sessions will typically involve the full desktop environment of a normal user. Alternatively, you can manually specify a program to use instead of the RDP server's default shell, or connect to the administrative console.
Although Guacamole is independent of keyboard layout, RDP is not. This is because Guacamole represents keys based on their identity ("press the Enter key"), while RDP uses identifiers based on the key's location ("press the rightmost key in the second row"). To translate between a Guacamole key event and an RDP key event, Guacamole must know ahead of time the keyboard layout of the RDP server.
Guacamole will automatically choose an appropriate display size for RDP connections based on the size of the browser window and the DPI of the device. The size of the display can be forced by specifying explicit width or height values. To reduce bandwidth usage, you may also request that the server reduce its color depth.
Guacamole provides bidirectional access to the clipboard by default for RDP connections. This behavior can be overridden on a per-connection basis, restricting access to the clipboard.
Device redirection refers to the use of non-display devices over RDP. Guacamole's RDP support currently allows redirection of audio (both output and input), printing, and disk access, some of which require additional configuration in order to function properly:
Audio output is always enabled by default. Configuration changes for audio output need only be made if this should be disabled.
Audio input, if enabled, allows users to make use of their local microphone within the remote desktop session. Enabling this typically also requires additional configuration within Windows, as group policy is often configured to disable this. Older versions of Windows may lack support for audio input via remote desktop entirely.
Printing, if enabled, allows users to print arbitrary documents directly to PDF. When documents are printed to the redirected printer, the user will receive a PDF download of that document within their web browser.
File transfer, if enabled, is provided by emulating a virtual disk drive. This drive will persist on the Guacamole server, confined within the drive path specified.
RDP provides several flags which control the availability of features that decrease performance and increase bandwidth for the sake of aesthetics, such as wallpaper, window theming, menu effects, and smooth fonts. These features are all disabled by default within Guacamole such that bandwidth usage is minimized, but you can manually re-enable them on a per-connection basis if desired.
Recent versions of Windows provide a feature called RemoteApp which allows individual applications to be used over RDP, without providing access to the full desktop environment. If your RDP server has this feature enabled and configured, you can configure Guacamole connections to use those individual applications.
If your remote desktop servers are behind a load balancer, sometimes referred to as a "connection broker" or "TS session broker", that balancer may require additional information during the connection process to determine how the incoming connection should be routed. RDP does not dictate the format of this information; it is specific to the balancer in use.
If you are using a load balancer and are unsure whether such information is required, you will need to check the documentation for your balancer. If your balancer provides .rdp
files for convenience, look through the contents of those files for a string field called "loadbalanceinfo
", as that field is where the required information/cookie would be specified.
If you are using Hyper-V, you will need to specify the ID of the destination virtual machine as the "preconnection BLOB". This value can be determined using PowerShell:
The preconnection PDU is intentionally generic. While its primary use is as a means for selecting virtual machines behind Hyper-V, other RDP servers may use it as well. It is up to the RDP server itself to determine whether the preconnection ID, BLOB, or both will be used, and what their values mean.
If you do intend to use Hyper-V, beware that its built-in RDP server uses slightly different parameters for both authentication and the port number, and Guacamole's defaults will not work. In most cases, you will need to do the following when connecting to Hyper-V:
Specify both the username and password appropriately, and set the security mode to "vmconnect
". Selecting the "vmconnect
" security mode will configure Guacamole to automatically negotiate security modes known to be supported by Hyper-V, and will automatically select Hyper-V's default RDP port (2179).
If necessary, ignore the TLS certificate used by Hyper-V, which may be self-signed.
Guacamole can provide file transfer over SFTP even when the remote desktop is otherwise being accessed through RDP and not SSH. This support is independent of the file transfer implemented through RDP's own "drive redirection" (RDPDR), and is particularly useful for RDP servers which do not support RDPDR.
Protocol | Keeper Connection Manager package |
---|
If a needed package was not installed and a message like that above is logged, installing the needed package will solve the problem. If using , all protocol support is already installed. If using the @kcm-guacamole
package group, as described within , protocol support for VNC, RDP, and SSH is installed.
If defining a connection through a mechanism which does not leverage one of the supported databases, such as via /etc/guacamole/user-mapping.xml
,, or, the protocol will must be specified using the unique, internal name for that protocol:
Protocol | Internal name |
---|
Support for the RDP protocol within Keeper Connection Manager is provided by the kcm-libguac-client-rdp
package. This package will be installed by default if the @kcm
package group was used during installation, and is already installed within the . If this package has not yet been installed, RDP connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
Keeper's support for the RDP protocol is controlled through the use of several parameters. When a database like MySQL or PostgreSQL is used, these parameters are presented through the web interface. If defining connections through another mechanism, such as through or parameters are specified using their internal parameter names.
Field header | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
If the necessary username and password will be the same as the username and password used to log into Guacamole (due to , for example), the Guacamole username and password can be passed through by specifying the ${GUAC_USERNAME}
and ${GUAC_PASSWORD}
tokens respectively.
Field header (web interface) | Parameter name | Description |
---|
If you have a corporate CA certificate root that is trusted, you can update the CA_CERTIFICATES
environment variable of the image.
Field header (web interface) | Parameter name | Description |
---|
By default, the US English qwerty keyboard will be used. If this does not match the keyboard layout of your RDP server, keys will not be properly translated, and you will need to explicitly choose a different layout in your connection settings. If your keyboard layout is not supported, please notify us by through your account.
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Some RDP servers host multiple logical RDP connections behind a single server listening on a single TCP port. To select between these logical connections, an RDP client must send the "preconnection PDU" - a message which contains values that uniquely identify the destination, referred to as the "RDP source". This mechanism is defined by the for the RDP protocol, and is implemented by Microsoft's Hyper-V hypervisor.
Field header (web interface) | Parameter name | Description |
---|
RDP sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the hosted at (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Keeper Connection Manager Session Recording Player can be found on GitHub, along with instructions for local deployment:
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the documentation page.
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Hostname: |
| REQUIRED: The hostname or IP address of the RDP server Guacamole should connect to. |
Port: |
| The port the RDP server is listening on. If this is not specified, the standard port for RDP (3389) or Hyper-V's default port for VMConnect (2179) will be used, depending on the security mode selected. |
Hostname: |
| The hostname of the remote desktop gateway that should be used as an intermediary for the remote desktop connection. If omitted, a gateway will not be used. |
Port: |
| The port of the remote desktop gateway that should be used as an intermediary for the remote desktop connection. By default, port 443 will be used. |
Username: |
| The username of the user authenticating with the remote desktop gateway, if a gateway is being used. This is not necessarily the same as the user actually using the remote desktop connection. |
Password: |
| The password to provide when authenticating with the remote desktop gateway, if a gateway is being used. |
Domain: |
| The domain of the user authenticating with the remote desktop gateway, if a gateway is being used. This is not necessarily the same domain as the user actually using the remote desktop connection. |
Width: |
| The width of the display to request, in pixels. If this value is not specified, the width of the connecting client display will be used instead. |
Height: |
| The height of the display to request, in pixels. If this value is not specified, the height of the connecting client display will be used instead. |
Resolution (DPI): |
| The desired effective resolution of the client display, in DPI. If this value is not specified, the resolution and size of the client display will be used together to determine, heuristically, an appropriate resolution for the RDP session. |
Color depth: |
| The color depth to request, in bits per pixel. Legal values 8, 16, or 24. Note that, regardless of what value is chosen here, Guacamole will always attempt to optimize image transmission, automatically using fewer bits per pixel if doing so will not visibly alter image quality. |
Force lossless compression: |
| Whether this connection should use lossless compression only. If set to "true", all graphical updates will use lossless compression algorithms. By default, lossy compression will automatically be used when Guacamole detects that doing so would likely outperform lossless compression. |
Resize method: |
| The method to use to update the RDP server when the width or height of the client display changes. If this value is not specified, no action will be taken when the client display changes size. Normally, the display size of an RDP session is constant and can only be changed when initially connecting. As of RDP 8.1, the "Display Update" channel can be used to request that the server change the display size. For older RDP servers, the only option is to disconnect and reconnect with the new size. Legal values are:
|
Read-only: |
| Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will be able to see the desktop or application but will be unable to interact. |
Disable copying from remote desktop: |
| If set to "true", text copied within the RDP session will not be accessible by the user at the browser side of the Guacamole session, and will be usable only within the remote desktop. By default, the user will be given access to the copied text. |
Disable pasting from client: |
| If set to "true", text copied at the browser side of the Guacamole session will not be accessible within the RDP session. By default, the user will be able to paste data from outside the browser within the RDP session. |
Enable wallpaper: |
| If set to "true", enables rendering of the desktop wallpaper. By default, wallpaper will be disabled, such that unnecessary bandwidth need not be spent redrawing the desktop. |
Enable theming: |
| If set to "true", enables use of theming of windows and controls. By default, theming within RDP sessions is disabled. |
Enable font smoothing (ClearType): |
| If set to "true", text will be rendered with smooth edges. Text over RDP is rendered with rough edges by default, as this reduces the number of colors used by text, and thus reduces the bandwidth required for the connection. |
Enable full-window drag: |
| If set to "true", the contents of windows will be displayed as windows are moved. By default, the RDP server will only draw the window border while windows are being dragged. |
Enable desktop composition (Aero): |
| If set to "true", graphical effects such as transparent windows and shadows will be allowed. By default, such effects, if available, are disabled. |
Enable menu animations: |
| If set to "true", menu open and close animations will be allowed. Menu animations are disabled by default. |
Disable bitmap caching: |
| If set to "true", the RDP bitmap cache will not be used. By default, caching of bitmaps is enabled. This is generally only useful when dealing with an RDP server that has known bugs in its implementation of bitmap caching, and should remain enabled in most circumstances. |
Disable off-screen caching: |
| If set to "true," caching of regions of the screen that are not currently visible will be disabled. By default, caching of off-screen regions is enabled. This is generally only useful when dealing with an RDP server that has known bugs in its implementation of off-screen caching, and should remain enabled in most circumstances. |
Disable glyph caching: |
| If set to "true", the RDP glyph cache will not be used. By default, caching of glyphs is enabled. This is generally only useful when dealing with an RDP server that has known bugs in its implementation of glyph caching, and should remain enabled in most circumstances. |
Program: |
| The RemoteApp to start on the remote desktop. If supported by your remote desktop server, this application, and only this application, will be visible to the user. For an application to be available, it must generally be explicitly listed as allowed ahead of time within Windows Server Manager. Windows requires a special notation for the aliases of remote applications. When specifying the alias of a remote application, it must be prefixed with two vertical bars (" |
Working directory: |
| The working directory of the remote application, if any. This parameter has no effect if RemoteApp is not in use. |
Parameters: |
| The command-line arguments to pass to the remote application, if any. This parameter has no effect if RemoteApp is not in use. |
Load balance info/cookie: |
| The load balancing information or cookie which should be provided to the connection broker. If no connection broker is being used, this should be left blank. |
RDP source ID: |
| The numeric ID of the RDP source. This is a non-negative integer value dictating which of potentially several logical RDP connections should be used. This parameter is only required if the RDP server is documented as requiring it. If using Hyper-V, this should be left blank. |
Preconnection BLOB (VM ID): |
| An arbitrary string which identifies the RDP source - one of potentially several logical RDP connections hosted by the same RDP server. This parameter is only required if the RDP server is documented as requiring it, such as Hyper-V. In all cases, the meaning of this parameter is opaque to the RDP protocol itself and is dictated by the RDP server. For Hyper-V, this will be the ID of the destination virtual machine. |
Recording path: |
| The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created. |
Recording name: |
| The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording". Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude graphics/streams: |
| If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude mouse: |
| If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude touch events: |
| If set to "true", user touch events will be excluded from the recording, producing a recording which lacks the exact details of touch interactions. This will not necessarily prevent touch events from being visible, as the remote desktop server may still choose to render touch interaction on its own. By default, touch events will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Include key events: |
| If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Automatically create recording path: |
| If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Enable SFTP: |
| Whether file transfer should be enabled. If set to "true", the user will be allowed to upload or download files from the specified server using SFTP. If omitted, SFTP will be disabled. |
Hostname: |
| The hostname or IP address of the server hosting SFTP. If omitted, the specified hostname or address of the RDP server will be used. |
Port: |
| The port the SSH server providing SFTP is listening on, usually 22. If omitted, the standard port of 22 will be used. |
Public host key (Base64): |
| The known hosts entry for the SSH server providing SFTP, in the same format as would be specified within an OpenSSH |
Username: |
| The username to authenticate as when connecting to the specified SSH server for SFTP. This parameter is required if SFTP is enabled. |
Password: |
| The password to use when authenticating with the specified SSH server for SFTP. |
Private key: |
| The entire contents of the private key to use for public key authentication. If this parameter is not specified, public key authentication will not be used. The private key must be in OpenSSH format, as would be generated by the OpenSSH |
Passphrase: |
| The passphrase to use to decrypt the private key for use in public key authentication. This parameter is not needed if the private key does not require a passphrase. |
File browser upload directory: |
| The directory to expose to connected users via Guacamole's file browser. If omitted, the root directory will be used by default. |
Default upload directory: |
| The directory to upload files to if they are simply dragged and dropped, and thus otherwise lack a specific upload location. If omitted, the default upload location of the SSH server providing SFTP will be used. |
SFTP keepalive interval: |
| The interval in seconds between which keepalive packets should be sent to the SSH server for the SFTP connection, where "0" indicates that no keepalive packets should be sent at all (the default behavior). The minimum legal value is "2". |
Multiple LDAP Servers with KCM
If your Active Directory or LDAP deployment spans multiple servers, Guacamole can be configured to use each of your LDAP servers using ldap-servers.yml
, a configuration file similar to guacamole.properties
and located within /etc/guacamole
. When a user authenticates with a Guacamole instance configured to use multiple LDAP servers, each configured LDAP server is tried, in order, until authentication succeeds. Authentication fails only if none of the defined LDAP servers accept the user's provided credentials.
When ldap-servers.yml
is used, the values within guacamole.properties
still have meaning, but instead serve as defaults for the LDAP servers defined in ldap-servers.yml
.
ldap-servers.yml
The ldap-servers.yml
file contains a single YAML list of LDAP servers, with each server definition consisting of a simple list of configuration properties and values. These configuration properties are identical to the LDAP properties available within guacamole.properties
except that the "ldap-" prefix is omitted.
For example, a simple ldap-servers.yml
that defines two LDAP servers that may be used to authenticate users would contain the following:
When a user attempts to log in, Guacamole will attempt to authenticate the user against the first defined LDAP server (server1.example.net
). If that fails, Guacamole will proceed with the next (server2.example.net
), and so on. Only if authentication fails against all defined LDAP servers will authentication against LDAP fail overall.
Since the only property that varies between the two servers in the above example is the hostname, and since guacamole.properties
serves as the source of default values when ldap-servers.yml
is used, the configuration details common to all servers would be better specified within guacamole.properties
:
The contents of ldap-servers.yml
can then be reduced to only the hostnames:
LDAP servers listed within ldap-servers.yml
may optionally be restricted to only certain users with the "match-usernames
" option. This option accepts both a single string and an array of strings, where each string is a Perl-compatible regular expression. Additionally, if the regular expression includes a capturing group, the contents of the first capturing group will be used as the username representing the user's Guacamole identity.
For example, to define two LDAP servers covering distinct domains, splitting usage of those LDAP servers by whether the user enters their username as "DOMAIN1\username" or "DOMAIN2\username", you would edit your ldap-servers.yml
to contain something like the following:
Each of the LDAP servers defined above will only be used if their corresponding regular expression matches the username specified by the user. Since each of the regular expressions in the above example define a capturing group around the username component of the "DOMAIN\username" format, that portion of the provided username will be used to determine the user's identity. If a user successfully authenticates as "DOMAIN1\myusername", then:
The captured portion ("myusername") will be used to identify the user's corresponding account in Guacamole's database.
The captured portion ("myusername") will be used when mapping the user to their fully-qualified LDAP DN.
If there are multiple username formats that need to be accepted by each LDAP server, multiple regular expressions may be specified. For example, to match both "MYDOMAIN\myusername" and the UPN-style "myusername@mydomain.example.net" formats, you would specify:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow user-provided KSM configuration: |
|
Username: |
| The username to use to authenticate, if any. |
Password: |
| The password to use when attempting authentication, if any. |
Domain: |
| The domain to use when attempting authentication, if any. |
Security mode: |
| The security mode to use for the RDP connection. This mode dictates how data will be encrypted and what type of authentication will be performed, if any. By default, security mode negotiation is performed. Legal values are:
|
Disable authentication: |
| If set to " If you are using NLA, authentication must be enabled by definition. |
Ignore server certificate: |
| If set to "true", the certificate returned by the server will be ignored, even if that certificate cannot be validated. This is useful if you universally trust the server and your connection to the server, and you know that the server's certificate cannot be validated (for example, if it is self-signed). |
Initial program: |
| The full path to the program to run immediately upon connecting. |
Client name: |
| When connecting to the RDP server, Guacamole will normally provide its own hostname as the name of the client. If this parameter is specified, Guacamole will use its value instead. On Windows RDP servers, this value is exposed within the session as the |
Keyboard layout: |
| The keyboard layout that the RDP server will be using. Legal values are:
This is the layout of the RDP server and has nothing to do with the keyboard layout in use on the client. The Guacamole client is independent of keyboard layout. The RDP protocol is not independent of keyboard layout, and Guacamole needs to know the keyboard layout of the server in order to send the proper keys when a user is typing. |
Time zone: |
| The timezone that the client should send to the server for configuring the local time display of that server. The format of the timezone is in the standard IANA key zone format, which is the format used in UNIX/Linux. This will be converted by RDP into the correct format for Windows. Support for forwarding the client timezone varies by RDP server implementation. For example, with Windows, support for forwarding timezones is only present in Windows Server with Remote Desktop Services (RDS, formerly known as Terminal Services) installed. Windows Server installations in admin mode, along with Windows workstation versions, do not allow the timezone to be forwarded. Other server implementations, such as XRDP, may not implement this feature at all. Consult the documentation for the RDP server to determine whether or not this feature is supported. |
Enable multi-touch: |
| "true" if multi-touch support should be enabled for the RDP connection. Enabling RDP support for multi-touch allows touch events to be passed through to the remote desktop, and requires that the RDP server support the RDPEI channel. This parameter does not control whether Guacamole itself supports touch events. Guacamole always supports touch events and will use any touch events to emulate a mouse by default. This parameter controls only whether touch events should be passed directly through to the RDP server instead of emulating a mouse. |
Administrator console: |
| If set to "true", you will be connected to the console (admin) session of the RDP server. |
Support audio in console: |
| If set to "true", audio will be explicitly enabled in the console (admin) session of the RDP server. Setting this option to "true" only makes sense if the |
Disable audio: |
| Audio output is always enabled by default. If you are concerned about bandwidth usage, or audio is causing problems, you can explicitly disable audio output by setting this parameter to "true". |
Enable audio input (microphone): |
| If set to "true", audio input support (microphone) will be enabled, leveraging the standard "AUDIO_INPUT" channel of RDP. By default, audio input support within RDP is disabled. |
Enable printing: |
| If set to "true", a redirected printer will be made available within the RDP session that users can use to print to a PDF. The PDF is received and automatically downloaded by the user's browser. By default, printing is disabled. |
Redirected printer name: |
| The name of the redirected printer device that is passed through to the RDP session. This is the name that the user will see in their applications and within the Devices and Printers control panel. If printer redirection is not enabled, this parameter has no effect. |
Enable drive: |
| If set to "true", a redirected drive will be made available within the RDP session that users can use to transfer files. The contents of the virtual drive are persisted on the Guacamole server in the directory specified by the " |
Drive name: |
| The name of the filesystem used when passed through to the RDP session. This is the name that users will see in their Computer/My Computer area along with client name, and is also the name of the share when accessing the special If drive redirection is not enabled, this parameter is ignored. |
Drive path: |
| If drive redirection is not enabled, this parameter is ignored. |
Automatically create drive: |
| If set to "true", the final directory within the specified drive path will automatically be created if it does not yet exist. By default, no part of the drive path will be automatically created, and any attempt to use a non-existent directory will result in an error. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the will fail with an error. If drive redirection is not enabled, this parameter is ignored. |
Static channel names: |
| A comma-separated list of static channel names to open and expose as pipes. If you wish to communicate between an application running on the remote desktop and JavaScript, this is the best way to do it. Guacamole will open an outbound pipe with the name of the static channel. If JavaScript needs to communicate back in the other direction, it should respond by opening another pipe with the same name. Guacamole allows any number of static channels to be opened, but protocol restrictions of RDP limit the size of each channel name to 7 characters. |
Advanced configuration of SSH Protocol connection type
Support for the SSH protocol within Keeper Connection Manager is provided by the kcm-libguac-client-ssh
package. This package will be installed by default if the @kcm
package group was used during installation, and is already installed within the keeper/guacd
Docker image. If this package has not yet been installed, SSH connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
If such an error appears within the guacd logs, simply installing kcm-libguac-client-ssh
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of SSH support to take effect.
Unlike VNC or RDP, SSH is a text protocol. Its implementation in Guacamole is actually a combination of a terminal emulator and SSH client, because the SSH protocol isn't inherently graphical. Guacamole's SSH support emulates a terminal on the server side, and draws the screen of this terminal remotely on the client.
Keeper's support for the SSH protocol is controlled through the use of several parameters. When a database like MySQL or PostgreSQL is used, these parameters are presented in a convenient web interface. If defining connections through another mechanism, such as through encrypted JSON or LDAP schema modifications, parameters are specified using their internal parameter names.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
SSH connections are established over TCP to a specific port and a specific hostname or IP address. The hostname/address must be specified for all SSH connections, but you only need to specify a port if you are not using the standard SSH port (22).
Guacamole supports keyboard-interactive, password, and public key authentication with SSH servers. To use public key authentication, it must have access to the private key and, if applicable, its passphrase. If the private key requires a passphrase, but no passphrase is provided, the user will be prompted for the passphrase upon connecting.
Guacamole's SSH support provides a display, but not in the same sense as a remote desktop protocol like VNC or RDP. The display is a terminal emulator, and thus provides options for configuring the font used and its size.
If selecting a different font for an SSH connection, the chosen font must be installed on the server running guacd. It is the server that will handle rendering of characters to the terminal display, not the client.
Custom color schemes may be provided for the terminal emulator used by SSH connections. Custom schemes mimic the format used by Xterm and consist of a semicolon-separated series of name-value pairs. Each name-value pair is separated by a colon and assigns a value to a color in the terminal emulator palette.
For example, to use blue text on white background by default, and change the red color to a purple shade, you would specify:
Legal color names are:
"foreground
" - the default foreground color.
"background
" - the default background color.
"colorN
" - the color at index N within the Xterm 256-color palette. For example, "color9" refers to the color at palette index 9, normally red.
Legal color values are:
"rgb:RR/GG/BB" - a color in RGB format, with each component in hexadecimal. For example, "rgb:ff/00/00
" specifies the color red. Each hexadecimal component may be one to four digits, but the effective values are always zero-extended or truncated to two digits; for example, "rgb:f/8/0
", "rgb:f0/80/00
", and "rgb:f0f/808/00f
" all refer to the same effective color.
"colorN
" - the color currently assigned to index N within the Xterm 256-color palette. For example, "color9
" specifies the color currently assigned to palette index 9. Note that the current color value is used rather than a reference to that color. If the referenced color is changed later in the color scheme configuration, that new color value will not be reflected in this assignment.
"NAME
" - the color with human-readable name "NAME
", where "NAME
" is one of the standard color names supported by X11. These names generally correspond to the names standardized by the W3C for CSS.
Guacamole provides bidirectional access to the clipboard by default for SSH connections. This behavior can be overridden on a per-connection basis, restricting access to the clipboard.
By default, SSH sessions will start an interactive shell. The shell which will be used is determined by the SSH server, normally by reading the user's default shell previously set with chsh
or within /etc/passwd
. If you wish to override this and instead run a specific command, you can do so by specifying that command in the configuration of the Guacamole SSH connection.
In most cases, the default behavior of the Guacamole terminal emulator works without modification. However, when connecting to certain systems (particularly operating systems other than Linux), the terminal behavior may need to be tweaked to allow it to operate properly. Guacamole's SSH support provides parameters for controlling the control code sent for backspace, as well as the terminal type claimed via the TERM
environment variable.
The full, raw text content of SSH sessions, including timing information, can be recorded automatically to a specified directory. This recording, also known as a "typescript", will be written to two files within the directory specified: one file contains the raw text data, and the other contains timing information. Where "NAME
" is the value provided for the typescript name, these files will be named "NAME
" and "NAME.timing
" respectively.
This format is compatible with the format used by the standard UNIX script
command, and can be replayed using scriptreplay
(if installed). For example, to replay a typescript called "NAME
", you would run:
SSH sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the Glyptodon Enterprise Session Recording Player application hosted at player.glyptodon.com (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Glyptodon Enterprise Session Recording Player can be found on GitHub, along with instructions for local deployment: https://github.com/glyptodon/glyptodon-enterprise-player
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the Session Recording documentation page.
Guacamole provides support for file transfer over SSH using SFTP, the file transfer protocol built into most SSH servers. If SFTP is enabled on a Guacamole SSH connection, users will be able to upload and download files through that connection.
While it is always possible to download/upload files using the Guacamole menu accessed using Ctrl+Alt+Shift, it can be more convenient to use the guacctl
utility. The guacctl
utility is a shell script which allows control codes specific to the Guacamole terminal emulator to be sent. If placed within the path on the SSH server(s) being accessed, it can be used by users to initiate file downloads directly within the SSH session.
Advanced configuration of VNC Protocol connection type
Support for the VNC protocol within Keeper Connection Manager is provided by the kcm-libguac-client-vnc
package. This package will be installed by default if the @kcm
package group was used during installation, and is already installed within the keeper/guacd
Docker image. If this package has not yet been installed, VNC connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
If such an error appears within the guacd logs, simply installing kcm-libguac-client-vnc
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of VNC support to take effect.
Keeper's support for the VNC protocol is controlled through the use of several parameters. When a database like MySQL or PostgreSQL is used, these parameters are presented in a convenient web interface. If defining connections through another mechanism, such as through encrypted JSON or LDAP schema modifications, parameters are specified using their internal parameter names.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
Some features provided by Guacamole's VNC support are implemented through additional protocols like SFTP and PulseAudio. This is done transparently. While additional network connections may be used between guacd and the remote desktop servers, everything between the user and Guacamole will still use only a single connection.
VNC connections are established over TCP to a specific port and a specific hostname or IP address. In general, each VNC server is associated with a display number, from which the appropriate port number is derived, though most VNC servers provide a means of overriding this default behavior. Both the hostname and port are required parameters for all VNC connections.
The VNC standard defines only password based authentication, with other authentication mechanisms being non-standard or proprietary. Keeper Connection Manager currently supports only the password method.
VNC servers do not allow the client to request particular display sizes, so you are at the mercy of your VNC server with respect to display width and height. However, to reduce bandwidth usage, you may request that the VNC server reduce its color depth. Guacamole will automatically detect 256-color images, but this can be guaranteed for absolutely all graphics sent over the connection by forcing the color depth to 8-bit. Color depth is otherwise dictated by the VNC server.
If you are noticing problems with your VNC display, such as the lack of a mouse cursor, the presence of multiple mouse cursors, or strange colors (such as blue colors appearing more like orange or red), these are typically the result of bugs or limitations within the VNC server, and additional parameters are available to work around such issues.
Guacamole provides bidirectional access to the clipboard by default for VNC connections, and will automatically translate clipboard data from its native UTF-8 format into the ISO 8859-1 encoding required by the VNC standard. This behavior can be overridden on a per-connection basis, restricting access to the clipboard and/or forcing Guacamole to assume that the VNC server uses a non-standard encoding.
The only clipboard encoding guaranteed to be supported by VNC servers is ISO 8859-1. You should only override the clipboard encoding if you are absolutely positive that the VNC server supports and expects a different encoding.
There exist VNC repeaters, such as UltraVNC Repeater, which act as intermediaries or proxies, providing a single logical VNC connection which is then routed to another VNC server elsewhere. Additional parameters are required to select which VNC host behind the repeater will receive the connection.
VNC sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the Glyptodon Enterprise Session Recording Player application hosted at player.glyptodon.com (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Glyptodon Enterprise Session Recording Player can be found on GitHub, along with instructions for local deployment: https://github.com/glyptodon/glyptodon-enterprise-player
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the Session Recording documentation page.
VNC does not normally support file transfer, but Guacamole can provide file transfer over SFTP even when the remote desktop is otherwise being accessed through VNC and not SSH.
VNC does not provide its own support for audio, but Guacamole's VNC support can obtain audio through a secondary network connection to a PulseAudio server running on the same machine as the VNC server.
Most Linux systems provide audio through a service called PulseAudio. This service is capable of communicating over the network, and if PulseAudio is configured to allow TCP connections, Guacamole can connect to your PulseAudio server and combine its audio with the graphics coming over VNC.
The following parameters are available for configuring the audio support for VNC:
For PulseAudio to accept network connections, its TCP module must be loaded. The TCP module is not typically loaded by default, and must be manually loaded through an additional line within the PulseAudio configuration file (usually /etc/pulse/default.pa
). The options specified for the module dictate exactly where these connections are allowed from, providing a degree of security. For example, to allow connections from only the 10.0.0.0/8
subnet:
It is also possible to allow connections from absolutely anywhere, but beware that you should only do so if the nature of your network prevents unauthorized access:
Once the PulseAudio configuration file has been modified appropriately, restart the PulseAudio service. PulseAudio should then begin listening on port 4713 (the default PulseAudio port) for incoming TCP connections. You can verify this using a utility like netstat
:
In all cases, the auth-anonymous=1
parameter is strictly required. Guacamole does not currently support the cookie-based authentication used by PulseAudio for non-anonymous connections. If this parameter is omitted, Guacamole will not be able to connect to PulseAudio.
Advanced configuration of Kubernetes connection type
Within Keeper Connection Manager, support for attaching to the consoles of Kubernetes containers is provided by the kcm-libguac-client-kubernetes
package. Support for Kubernetes is not installed by the @kcm
package group, but is installed within the keeper/guacd
Docker image. If this package has not yet been installed, Kubernetes connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
If such an error appears within the guacd logs, simply installing kcm-libguac-client-kubernetes
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of Kubernetes support to take effect.
Keeper's Kubernetes support takes the form of a protocol implementation which allows Guacamole to attach to the consoles of Kubernetes containers using Kubernetes' REST API. As with SSH and telnet, Guacamole's Kubernetes support emulates a terminal on the server side which renders to the Guacamole client's display.
Support for attaching to Kubernetes containers is controlled through the use of several parameters. When a database like MySQL or PostgreSQL is used, these parameters are presented in a convenient web interface. If defining connections through another mechanism, such as through encrypted JSON or LDAP schema modifications, parameters are specified using their internal parameter names.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
Connecting to a Kubernetes server in order to attach to a container involves establishing a WebSocket connection with that server, and requires the server's hostname or IP address. Depending on the Kubernetes server, SSL/TLS may also be required for the connection.
Attaching to a particular Kubernetes container naturally required the name of the pod containing the container in question. By default, Guacamole will attach to the first container in the pod. If there are multiple containers in the pod, you may wish to also specify the container name.
If enabled, Kubernetes uses SSL/TLS for both encryption and authentication. Standard SSL/TLS client authentication requires both a client certificate and client key, which Guacamole will use to identify itself to the Kubernetes server.
Guacamole's Kubernetes support provides a display, but not in the same sense as a remote desktop protocol like VNC or RDP. The display is a terminal emulator, and thus provides options for configuring the font used and its size.
If selecting a different font for a Kubernetes connection, the chosen font must be installed on the server running guacd. It is the server that will handle rendering of characters to the terminal display, not the client.
Custom color schemes may be provided for the terminal emulator used by Kubernetes connections. Custom schemes mimic the format used by Xterm and consist of a semicolon-separated series of name-value pairs. Each name-value pair is separated by a colon and assigns a value to a color in the terminal emulator palette.
For example, to use blue text on white background by default, and change the red color to a purple shade, you would specify:
Legal color names are:
"foreground
" - the default foreground color.
"background
" - the default background color.
"colorN
" - the color at index N within the Xterm 256-color palette. For example, "color9" refers to the color at palette index 9, normally red.
Legal color values are:
"rgb:RR/GG/BB" - a color in RGB format, with each component in hexadecimal. For example, "rgb:ff/00/00
" specifies the color red. Each hexadecimal component may be one to four digits, but the effective values are always zero-extended or truncated to two digits; for example, "rgb:f/8/0
", "rgb:f0/80/00
", and "rgb:f0f/808/00f
" all refer to the same effective color.
"colorN
" - the color currently assigned to index N within the Xterm 256-color palette. For example, "color9
" specifies the color currently assigned to palette index 9. Note that the current color value is used rather than a reference to that color. If the referenced color is changed later in the color scheme configuration, that new color value will not be reflected in this assignment.
"NAME
" - the color with human-readable name "NAME
", where "NAME
" is one of the standard color names supported by X11. These names generally correspond to the names standardized by the W3C for CSS.
In most cases, the default behavior of the Guacamole terminal emulator works without modification. However, when connecting to certain systems, the terminal behavior may need to be tweaked to allow it to operate properly. Guacamole's Kubernetes support provides parameters for controlling the control code sent for backspace.
The full, raw text content of Kubernetes sessions, including timing information, can be recorded automatically to a specified directory. This recording, also known as a "typescript", will be written to two files within the directory specified: one file contains the raw text data, and the other contains timing information. Where "NAME
" is the value provided for the typescript name, these files will be named "NAME
" and "NAME.timing
" respectively.
This format is compatible with the format used by the standard UNIX script
command, and can be replayed using scriptreplay
(if installed). For example, to replay a typescript called "NAME
", you would run:
Kubernetes sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the Glyptodon Enterprise Session Recording Player application hosted at player.glyptodon.com (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Glyptodon Enterprise Session Recording Player can be found on GitHub, along with instructions for local deployment: https://github.com/glyptodon/glyptodon-enterprise-player
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the Session Recording documentation page.
Advanced configuration of MySQL connection type
Support for the MySQL protocol within Keeper Connection Manager is provided by the kcm-libguac-client-mysql
package. This package will be installed by default if the @kcm-guacamole
package group was used during installation, and is already installed within the keeper/guacd
Docker image. If this package has not yet been installed, MySQL connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
If such an error appears within the guacd logs, simply installing kcm-libguac-client-mysql
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of MySQL support to take effect.
The MySQL implementation in Keeper Connection Manager utilizes the MySQL client library as well as an internal terminal library which renders the user interface. Guacamole's MySQL support emulates a terminal on the server side, and draws the screen of this terminal remotely on the client.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
MySQL connections are established over TCP to a specific port and a specific hostname or IP address. The hostname/address must be specified for all MySQL connections, but you only need to specify a port if you are not using the standard MySQL port (3306).
Keeper Connection manager supports MySQL authentication through username and password parameters. Both fields are required to establish a connection.
The default database can be specified when establishing the connection. You can also disable the ability to perform CSV import and export of data.
Guacamole's MySQL support provides a display, but not in the same sense as a remote desktop protocol like VNC or RDP. The display is a terminal emulator, and thus provides options for configuring the font used and its size.
If selecting a different font for a MySQL connection, the chosen font must be installed on the server running guacd. It is the server that will handle rendering of characters to the terminal display, not the client.
Custom color schemes may be provided for the terminal emulator used by MySQL connections. Custom schemes mimic the format used by Xterm and consist of a semicolon-separated series of name-value pairs. Each name-value pair is separated by a colon and assigns a value to a color in the terminal emulator palette.
For example, to use blue text on white background by default, and change the red color to a purple shade, you would specify:
Legal color names are:
"foreground
" - the default foreground color.
"background
" - the default background color.
"colorN
" - the color at index N within the Xterm 256-color palette. For example, "color9" refers to the color at palette index 9, normally red.
Legal color values are:
"rgb:RR/GG/BB" - a color in RGB format, with each component in hexadecimal. For example, "rgb:ff/00/00
" specifies the color red. Each hexadecimal component may be one to four digits, but the effective values are always zero-extended or truncated to two digits; for example, "rgb:f/8/0
", "rgb:f0/80/00
", and "rgb:f0f/808/00f
" all refer to the same effective color.
"colorN
" - the color currently assigned to index N within the Xterm 256-color palette. For example, "color9
" specifies the color currently assigned to palette index 9. Note that the current color value is used rather than a reference to that color. If the referenced color is changed later in the color scheme configuration, that new color value will not be reflected in this assignment.
Guacamole provides bidirectional access to the clipboard by default for MySQL connections. This behavior can be overridden on a per-connection basis, restricting access to the clipboard.
The full, raw text content of MySQL sessions, including timing information, can be recorded automatically to a specified directory. This recording, also known as a "typescript", will be written to two files within the directory specified: one file contains the raw text data, and the other contains timing information. Where "NAME
" is the value provided for the typescript name, these files will be named "NAME
" and "NAME.timing
" respectively.
This format is compatible with the format used by the standard UNIX script
command, and can be replayed using scriptreplay
(if installed). For example, to replay a typescript called "NAME
", you would run:
Data can be imported to a MySQL connection from a file on your machine, or exported and downloaded to you machine.
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:
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.
The file uploaded does not have to have the same name given in the query
Data from the connected MySQL 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.
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the screen for more information.
"nla-ext
" - Extended Network Level Authentication. This mode is identical to NLA except that an additional "" is required to be sent from the server to the client immediately after the NLA handshake is completed.
If you require a keyboard layout that is not currently supported, please notify us by through your account.
The directory on the Guacamole server in which transferred files should be stored. This directory must be accessible by the
Field header | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
"NAME
" - the color with human-readable name "NAME
", where "NAME
" is one of the . These names generally correspond to the names standardized by the W3C for CSS.
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
MySQL sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the hosted at (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Glyptodon Enterprise Session Recording Player can be found on GitHub, along with instructions for local deployment:
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the documentation page.
Field header (web interface) | Parameter name | Description |
---|
Allow user-provided KSM configuration:
ksm-user-config-enabled
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the Multiple Vaults Integration screen for more information.
Hostname:
hostname
REQUIRED: The hostname or IP address of the SSH server Guacamole should connect to.
Port:
port
The port the SSH server is listening on. By default, the standard SSH port of 22 will be used.
Public host key (Base64):
host-key
The known hosts entry for the SSH server, in the same format as would be specified within an OpenSSH known_hosts
file. If not provided, no verification of host identity will be performed.
Username:
username
The username to authenticate as when connecting to the specified SSH server. If not provided, the user will be prompted to provide a username upon connecting.
Password:
password
The password to use when authenticating with the specified SSH server. If not provided, and no private key is used, the user will be prompted to provide a password upon connecting.
Private key:
private-key
The entire contents of the private key to use for public key authentication. If this parameter is not specified, public key authentication will not be used. The private key must be in OpenSSH format, as would be generated by the OpenSSH ssh-keygen
utility.
Passphrase:
passphrase
The passphrase to use to decrypt the private key for use in public key authentication. This parameter is not needed if the private key does not require a passphrase.
Color scheme:
color-scheme
The color scheme to use for the terminal emulator used by SSH connections. Each color scheme dictates the default foreground and background color for the terminal. Programs which specify colors when printing text will override these defaults. Legal values are:
"black-white
" - Black text over a white background
"gray-black
" - Gray text over a black background (the default)
"green-black
" - Green text over a black background
"white-black
" - White text over a black background
A custom color scheme (as described below)
By default, Guacamole will render text as gray over a black background.
Font name:
font-name
The name of the font to use. If not specified, the default of "monospace" will be used instead. This must be the name of a font installed on the server running guacd, and should be a monospaced font. If a non-monospaced font is used, individual glyphs may render incorrectly.
Font size:
font-size
The size of the font to use, in points. By default, the size of rendered text will be 12 point.
Maximum scrollback size:
scrollback
The maximum number of rows to allow within the terminal scrollback buffer. By default, the scrollback buffer will be limited to a maximum of 1000 rows.
Read-only:
read-only
Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will be able to see the terminal (or the application running within the terminal) but will be unable to interact.
Disable copying from terminal:
disable-copy
If set to "true", text copied within the SSH session will not be accessible by the user at the browser side of the Guacamole session, and will be usable only within the remote desktop. By default, the user will be given access to the copied text.
Disable pasting from client:
disable-paste
If set to "true", text copied at the browser side of the Guacamole session will not be accessible within the SSH session. By default, the user will be able to paste data from outside the browser within the SSH session.
Execute command:
command
The command to execute over the SSH session, if any. If not specified, the SSH session will use the user's default shell.
Language/Locale ($LANG):
locale
The specific locale to request for the SSH session. This may be any value accepted by the LANG
environment variable of the SSH server. If not specified, the SSH server's default locale will be used.
As this parameter is sent to the SSH server using the LANG
environment variable, the parameter will only have an effect if the SSH server allows the LANG
environment variable to be set by SSH clients.
Time zone ($TZ):
timezone
The time zone to request for the SSH session. This may be any value accepted by the TZ
environment variable of the SSH server, typically the standard names defined by the IANA time zone database. If not specified, the SSH server's default time zone will be used.
As this parameter is sent to the SSH server using the TZ
environment variable, the parameter will only have an effect if the SSH server allows the TZ
environment variable to be set by SSH clients.
Server keepalive interval:
server-alive-interval
The interval in seconds between which keepalive packets should be sent to the SSH server, where "0" indicates that no keepalive packets should be sent at all (the default behavior). The minimum legal value is "2".
Backspace key sends:
backspace
The integer value of the terminal control code that should be sent when backspace is pressed. Under most circumstances this should not need to be adjusted; however, if, when pressing the backspace key, you see control characters (often either ^? or ^H) instead of seeing the text erased, you may need to adjust this parameter. By default, the control code 127 (Delete) is sent.
Terminal type:
terminal-type
The terminal type string that should be passed to the SSH server. This value will typically be exposed within the SSH session as the TERM environment variable and will affect the control characters sent by applications. By default, the terminal type string "linux" is used.
Typescript path:
typescript-path
The directory in which typescript files should be created. If a typescript needs to be recorded, then this parameter is required. Specifying this parameter enables typescript recording. If this parameter is omitted, no typescript will be recorded.
Typescript name:
typescript-name
The base filename to use for any created recordings. If omitted, the base filename "typescript" will be used.
Guacamole will never overwrite an existing typescript. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the base filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the typescript will not be recorded, and an error will be logged.
This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored.
Automatically create typescript path:
create-typescript-path
If set to "true", the final directory within the specified typescript path will automatically be created if it does not yet exist. By default, no part of the typescript path will be automatically created, and any attempt to use a non-existent directory will result in the typescript not being recorded and an error being logged.
Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the typescript will not be recorded, and an error will be logged.
This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored.
Recording path:
recording-path
The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created.
Recording name:
recording-name
The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording".
Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude graphics/streams:
recording-exclude-output
If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude mouse:
recording-exclude-mouse
If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Include key events:
recording-include-keys
If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the guaclog
utility to produce a human-readable interpretation of the keys pressed during the session. By default, for privacy's sake, key events will be NOT included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Automatically create recording path:
create-recording-path
If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged.
Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Enable SFTP:
enable-sftp
Whether file transfer should be enabled. If set to "true", the user will be allowed to upload or download files from the SSH server using SFTP.
File browser root directory:
sftp-root-directory
The directory to expose to connected users via Guacamole's file browser. If omitted, the root directory will be used by default.
Allow user-provided KSM configuration:
ksm-user-config-enabled
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the Multiple Vaults Integration screen for more information.
Hostname:
hostname
REQUIRED: The hostname or IP address of the VNC server that Guacamole should connect to.
Port:
port
REQUIRED: The TCP port that the VNC server is listening on.
This value is typically 5900 or 5900 + display number. For example, if your VNC server is serving display number 1 (sometimes written as ":1"), your port number here would be 5901.
Password:
password
The password to use when attempting authentication, if any.
Read-only:
read-only
Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will only see the desktop and whatever other users using that same desktop are doing.
Swap red/blue components:
swap-red-blue
If the colors of your display appear wrong (blues appear orange or red, etc.), it may be that your VNC server is sending image data incorrectly, and the red and blue components of each color are swapped. If this is the case, set this parameter to "true" to work around the problem.
Cursor:
cursor
If set to "remote", the mouse pointer will be rendered remotely, and the local position of the mouse pointer will be indicated by a small dot. A remote mouse cursor will feel slower than a local cursor, but may be necessary if the VNC server does not support sending the cursor image to the client.
Color depth:
color-depth
The color depth to request, in bits per pixel. Legal values are 8, 16, 24, or 32. Note that, regardless of what value is chosen here, Guacamole will always attempt to optimize image transmission, automatically using fewer bits per pixel if doing so will not visibly alter image quality.
Force lossless compression:
force-lossless
Whether this connection should use lossless compression only. If set to "true", all graphical updates will use lossless compression algorithms. By default, lossy compression will automatically be used when Guacamole detects that doing so would likely outperform lossless compression.
Encoding:
clipboard-encoding
The encoding to assume for the VNC clipboard. By default, the standard encoding ISO 8859-1 will be used. Only use this parameter if you are sure your VNC server expects a different, non-standard encoding.
Possible values are:
"ISO8859-1
" - The clipboard encoding mandated by the VNC standard.
"UTF-8
"
"UTF-16
"
"CP1252
" - Code page 1252, a Windows-specific encoding for Latin characters which is mostly a superset of ISO 8859-1.
Disable copying from remote desktop:
disable-copy
If set to "true", text copied within the VNC session will not be accessible by the user at the browser side of the Guacamole session, and will be usable only within the remote desktop. By default, the user will be given access to the copied text.
Disable pasting from client:
disable-paste
If set to "true", text copied at the browser side of the Guacamole session will not be accessible within the VNC session. By default, the user will be able to paste data from outside the browser within the VNC session.
Destination host:
dest-host
The destination host to request when connecting to a VNC proxy such as UltraVNC Repeater. This is only necessary if the VNC proxy in use requires the connecting user to specify which VNC server to connect to. If the VNC proxy automatically connects to a specific server, this parameter is not necessary.
Destination port:
dest-port
The destination port to request when connecting to a VNC proxy such as UltraVNC Repeater. This is only necessary if the VNC proxy in use requires the connecting user to specify which VNC server to connect to. If the VNC proxy automatically connects to a specific server, this parameter is not necessary.
Recording path:
recording-path
The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created.
Recording name:
recording-name
The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording".
Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude graphics/streams:
recording-exclude-output
If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude mouse:
recording-exclude-mouse
If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Include key events:
recording-include-keys
If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the guaclog
utility to produce a human-readable interpretation of the keys pressed during the session. By default, for privacy's sake, key events will be NOT included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Automatically create recording path:
create-recording-path
If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged.
Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Enable SFTP:
enable-sftp
Whether file transfer should be enabled. If set to "true", the user will be allowed to upload or download files from the specified server using SFTP. If omitted, SFTP will be disabled.
Hostname:
sftp-hostname
The hostname or IP address of the server hosting SFTP. If omitted, the specified hostname or address of the VNC server will be used.
Port:
sftp-port
The port the SSH server providing SFTP is listening on, usually 22. If omitted, the standard port of 22 will be used.
Public host key (Base64):
sftp-host-key
The known hosts entry for the SSH server providing SFTP, in the same format as would be specified within an OpenSSH known_hosts
file. If not provided, no verification of host identity will be performed.
Username:
sftp-username
The username to authenticate as when connecting to the specified SSH server for SFTP. This parameter is required if SFTP is enabled.
Password:
sftp-password
The password to use when authenticating with the specified SSH server for SFTP.
Private key:
sftp-private-key
The entire contents of the private key to use for public key authentication. If this parameter is not specified, public key authentication will not be used. The private key must be in OpenSSH format, as would be generated by the OpenSSH ssh-keygen
utility.
Passphrase:
sftp-passphrase
The passphrase to use to decrypt the private key for use in public key authentication. This parameter is not needed if the private key does not require a passphrase.
File browser upload directory:
sftp-root-directory
The directory to expose to connected users via Guacamole's file browser. If omitted, the root directory will be used by default.
Default upload directory:
sftp-directory
The directory to upload files to if they are simply dragged and dropped, and thus otherwise lack a specific upload location. If omitted, the default upload location of the SSH server providing SFTP will be used.
SFTP keepalive interval:
sftp-server-alive-interval
The interval in seconds between which keepalive packets should be sent to the SSH server for the SFTP connection, where "0" indicates that no keepalive packets should be sent at all (the default behavior). The minimum legal value is "2".
Enable audio:
enable-audio
If set to "true", audio support will be enabled, and a second connection for PulseAudio will be made in addition to the VNC connection. By default, audio support within VNC is disabled.
Audio server name:
audio-servername
The name of the PulseAudio server to connect to. This will be the hostname or address of the computer providing audio for your connection via PulseAudio, most likely the same as the hostname/address of the VNC server.
If this parameter is omitted, the default PulseAudio device will be used, which will be the PulseAudio server running on the same machine as guacd.
Allow user-provided KSM configuration:
ksm-user-config-enabled
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the Multiple Vaults Integration screen for more information.
Hostname:
hostname
REQUIRED: The hostname or IP address of the Kubernetes server Guacamole should connect to.
Port:
port
The port the Kubernetes server is listening on. By default, port 8080 will be used.
Use SSL/TLS:
use-ssl
If set to "true", SSL/TLS will be used to connect to the Kubernetes server. By default, SSL/TLS will not be used.
Ignore server certificate:
ignore-cert
If set to "true", the validity of the SSL/TLS certificate used by the Kubernetes server will be ignored if it cannot be validated. By default, SSL/TLS certificates are validated.
Certificate authority certificate:
ca-cert
The certificate of the certificate authority that signed the certificate of the Kubernetes server, in PEM format. If omitted, verification of the Kubernetes server certificate will use only system-wide certificate authorities.
Namespace:
namespace
The name of the Kubernetes namespace of the pod containing the container being attached to. If omitted, the namespace "default
" will be used.
Pod name:
pod
REQUIRED: The name of the Kubernetes pod containing with the container being attached to.
Container name:
container
The name of the container to attach to. If omitted, the first container in the pod will be used.
Client certificate:
client-cert
The certificate to use if performing SSL/TLS client authentication to authenticate with the Kubernetes server, in PEM format. If omitted, SSL client authentication will not be performed.
Client key:
client-key
The key to use if performing SSL/TLS client authentication to authenticate with the Kubernetes server, in PEM format. If omitted, SSL client authentication will not be performed.
Color scheme:
color-scheme
The color scheme to use for the terminal emulator used by Kubernetes connections. Each color scheme dictates the default foreground and background color for the terminal. Programs which specify colors when printing text will override these defaults. Legal values are:
"black-white
" - Black text over a white background
"gray-black
" - Gray text over a black background (the default)
"green-black
" - Green text over a black background
"white-black
" - White text over a black background
A custom color scheme (as described below)
By default, Guacamole will render text as gray over a black background.
Font name:
font-name
The name of the font to use. If not specified, the default of "monospace" will be used instead. This must be the name of a font installed on the server running guacd, and should be a monospaced font. If a non-monospaced font is used, individual glyphs may render incorrectly.
Font size:
font-size
The size of the font to use, in points. By default, the size of rendered text will be 12 point.
Maximum scrollback size:
scrollback
The maximum number of rows to allow within the terminal scrollback buffer. By default, the scrollback buffer will be limited to a maximum of 1000 rows.
Read-only:
read-only
Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will be able to see the terminal (or the application running within the terminal) but will be unable to interact.
Backspace key sends:
backspace
The integer value of the terminal control code that should be sent when backspace is pressed. Under most circumstances this should not need to be adjusted; however, if, when pressing the backspace key, you see control characters (often either ^? or ^H) instead of seeing the text erased, you may need to adjust this parameter. By default, the control code 127 (Delete) is sent.
Typescript path:
typescript-path
The directory in which typescript files should be created. If a typescript needs to be recorded, then this parameter is required. Specifying this parameter enables typescript recording. If this parameter is omitted, no typescript will be recorded.
Typescript name:
typescript-name
The base filename to use for any created recordings. If omitted, the base filename "typescript" will be used.
Guacamole will never overwrite an existing typescript. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the base filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the typescript will not be recorded, and an error will be logged.
This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored.
Automatically create typescript path:
create-typescript-path
If set to "true", the final directory within the specified typescript path will automatically be created if it does not yet exist. By default, no part of the typescript path will be automatically created, and any attempt to use a non-existent directory will result in the typescript not being recorded and an error being logged.
Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the typescript will not be recorded, and an error will be logged.
This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored.
Recording path:
recording-path
The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created.
Recording name:
recording-name
The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording".
Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude graphics/streams:
recording-exclude-output
If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude mouse:
recording-exclude-mouse
If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Include key events:
recording-include-keys
If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the guaclog
utility to produce a human-readable interpretation of the keys pressed during the session. By default, for privacy's sake, key events will be NOT included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Automatically create recording path:
create-recording-path
If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged.
Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Hostname |
| REQUIRED: The hostname or IP address of the MySQL server Guacamole should connect to. |
Port |
| The port the MySQL server is listening on. By default, the standard MySQL port of 3306 will be used. |
Unix Socket |
| The socket name used for MySQL connections when running using the unix socket method. This is used if the host field is empty. |
Username |
| REQUIRED: The username to authenticate as when connecting to the specified MySQL server. |
Password |
| REQUIRED: The password to use when authenticating with the specified MySQL server. |
Default Database |
| The database schema selected when connecting to the specified MySQL server. |
Disable CSV Export |
| Set this value to "true" to disable CSV export of data when using the SQL statement "select ... into local outfile" |
Disable CSV Import |
| Set this value to "true" to disable CSV import of data when using the SQL statement "load data local infile ... into table" |
Disable copying from terminal: |
| If set to "true", text copied within the MySQL session will not be accessible by the user at the browser side of the Guacamole session, and will be usable only within the remote desktop. By default, the user will be given access to the copied text. |
Disable pasting from client: |
| If set to "true", text copied at the browser side of the Guacamole session will not be accessible within the MySQL session. By default, the user will be able to paste data from outside the browser within the MySQL session. |
Typescript path |
| The directory in which typescript files should be created. If a typescript needs to be recorded, then this parameter is required. Specifying this parameter enables typescript recording. If this parameter is omitted, no typescript will be recorded. |
Typescript name |
| The base filename to use for any created recordings. If omitted, the base filename "typescript" will be used. Guacamole will never overwrite an existing typescript. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the base filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the typescript will not be recorded, and an error will be logged. This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored. |
Automatically create typescript path |
| If set to "true", the final directory within the specified typescript path will automatically be created if it does not yet exist. By default, no part of the typescript path will be automatically created, and any attempt to use a non-existent directory will result in the typescript not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the typescript will not be recorded, and an error will be logged. This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored. |
Recording path |
| The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created. |
Recording name |
| The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording". Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude graphics/streams |
| If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude mouse |
| If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Include key events |
| If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Automatically create recording path |
| If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Data can be imported to a PostgreSQL connection from a file on your machine, or exported and downloaded to you machine.
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.
The file uploaded does not have to have the same name given in the query
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.
Allow user-provided KSM configuration: |
|
Theme |
| The color scheme to use for the terminal emulator used by SSH connections. Each color scheme dictates the default foreground and background color for the terminal. Programs which specify colors when printing text will override these defaults. Legal values are:
By default, Guacamole will render text as gray over a black background. |
Font name |
| The name of the font to use. If not specified, the default of "monospace" will be used instead. This must be the name of a font installed on the server running guacd, and should be a monospaced font. If a non-monospaced font is used, individual glyphs may render incorrectly. |
Font size |
| The size of the font to use, in points. By default, the size of rendered text will be 12 point. |
Maximum scrollback size: |
| The maximum number of rows to allow within the terminal scrollback buffer. By default, the scrollback buffer will be limited to a maximum of 1000 rows. |
Read-only: |
| Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will be able to see the terminal (or the application running within the terminal) but will be unable to interact. |
Advanced configuration of PostgreSQL / Redshift connection type
Support for the PostgreSQL protocol within Keeper Connection Manager is provided by the kcm-libguac-client-postgres
package. This package will be installed by default if the @kcm-guacamole
package group was used during installation, and is already installed within the keeper/guacd
Docker image. If this package has not yet been installed, PostgreSQL connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
If such an error appears within the guacd logs, simply installing kcm-libguac-client-postgres
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of PostgreSQL support to take effect.
The PostgreSQL implementation in Keeper Connection Manager utilizes the PostgreSQL client library as well as an internal terminal library which renders the user interface. Guacamole's PostgreSQL support emulates a terminal on the server side, and draws the screen of this terminal remotely on the client.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
PostgreSQL connections are established over TCP to a specific port and a specific hostname or IP address. The hostname/address must be specified for all PostgreSQL connections, but you only need to specify a port if you are not using the standard port (5432).
Keeper Connection manager supports PostgreSQL authentication through username and password parameters. Both fields are required to establish a connection.
The default database can be specified when establishing the connection. You can also disable the ability to perform CSV import and export of data.
Guacamole's PostgreSQL support provides a display, but not in the same sense as a remote desktop protocol like VNC or RDP. The display is a terminal emulator, and thus provides options for configuring the font used and its size.
If selecting a different font for a PostgreSQL connection, the chosen font must be installed on the server running guacd. It is the server that will handle rendering of characters to the terminal display, not the client.
Custom color schemes may be provided for the terminal emulator used by PostgreSQL connections. Custom schemes mimic the format used by Xterm and consist of a semicolon-separated series of name-value pairs. Each name-value pair is separated by a colon and assigns a value to a color in the terminal emulator palette.
For example, to use blue text on white background by default, and change the red color to a purple shade, you would specify:
Legal color names are:
"foreground
" - the default foreground color.
"background
" - the default background color.
"colorN
" - the color at index N within the Xterm 256-color palette. For example, "color9" refers to the color at palette index 9, normally red.
Legal color values are:
"rgb:RR/GG/BB" - a color in RGB format, with each component in hexadecimal. For example, "rgb:ff/00/00
" specifies the color red. Each hexadecimal component may be one to four digits, but the effective values are always zero-extended or truncated to two digits; for example, "rgb:f/8/0
", "rgb:f0/80/00
", and "rgb:f0f/808/00f
" all refer to the same effective color.
"colorN
" - the color currently assigned to index N within the Xterm 256-color palette. For example, "color9
" specifies the color currently assigned to palette index 9. Note that the current color value is used rather than a reference to that color. If the referenced color is changed later in the color scheme configuration, that new color value will not be reflected in this assignment.
"NAME
" - the color with human-readable name "NAME
", where "NAME
" is one of the standard color names supported by X11. These names generally correspond to the names standardized by the W3C for CSS.
Guacamole provides bidirectional access to the clipboard by default for PostgreSQL connections. This behavior can be overridden on a per-connection basis, restricting access to the clipboard.
The full, raw text content of PostgreSQL sessions, including timing information, can be recorded automatically to a specified directory. This recording, also known as a "typescript", will be written to two files within the directory specified: one file contains the raw text data, and the other contains timing information. Where "NAME
" is the value provided for the typescript name, these files will be named "NAME
" and "NAME.timing
" respectively.
This format is compatible with the format used by the standard UNIX script
command, and can be replayed using scriptreplay
(if installed). For example, to replay a typescript called "NAME
", you would run:
PostgreSQL sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the Glyptodon Enterprise Session Recording Player application hosted at player.glyptodon.com (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Glyptodon Enterprise Session Recording Player can be found on GitHub, along with instructions for local deployment: https://github.com/glyptodon/glyptodon-enterprise-player
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the Session Recording documentation page.
Keeper Connection Manager MySQL connections utilize EMACS-like commands for more powerful text editing. In order to utilize all of these commands, shortcuts are bound to specific Commands.
Note that some shortcuts may be captured by your browser, browser extensions, operating system, or other applications
To copy a region of text, first you need to select the text. The easiest way to do this is to highlight the text using your mouse curser.
The copy command is Ctrl-c
or Meta-w
Hold the Ctrl
key and press the c
key or press and release the ESC
key then press and release the w
key.
The Paste command is sometimes referred to as 'Yank' and is activated with Ctrl-v
or Ctrl-Y
Hold the Ctrl
key and press the v
key or press and hold Ctrl
the click the y
key.
The cursor can be moved to the beginning or the end of the current line.
This command is done with Ctrl-A
or the Home
key
Click Home
or hold the Ctrl
key and hit the a
key
This command is done with Ctrl-E
or the End
key
Click End
or hold the Ctrl
key and hit the e
key
See the complete list of available commands and shortcuts below.
In this table "Meta-" refers to hitting the ESC key followed by the shown key. For example to use Meta-B (ed-prev-word) hit ESC then release, then hit B and release. Optionally a Meta key can be setup on your keyboard.
Keeper Connection Manager PostgreSQL connections utilize EMACS-like commands for more powerful text editing. In order to utilize all of these commands, shortcuts are bound to specific Commands.
Note that some shortcuts may be captured by your browser, browser extensions, operating system, or other applications
To copy a region of text, first you need to select the text. The easiest way to do this is to highlight the text using your mouse curser.
The copy command is Ctrl-c
or Meta-w
Hold the Ctrl
key and press the c
key or press and release the ESC
key then press and release the w
key.
The Paste command is sometimes referred to as 'Yank' and is activated with Ctrl-v
or Ctrl-Y
Hold the Ctrl
key and press the v
key or press and hold Ctrl
the click the y
key.
The cursor can be moved to the beginning or the end of the current line.
This command is done with Ctrl-A
or the Home
key
Click Home
or hold the Ctrl
key and hit the a
key
This command is done with Ctrl-E
or the End
key
Click End
or hold the Ctrl
key and hit the e
key
See the complete list of available commands and shortcuts below.
In this table "Meta-" refers to hitting the ESC key followed by the shown key. For example to use Meta-B (ed-prev-word) hit ESC then release, then hit B and release. Optionally a Meta key can be setup on your keyboard.
Keeper Connection Manager PostgreSQL connections utilize EMACS-like commands for more powerful text editing. In order to utilize all of these commands, shortcuts are bound to specific Commands.
Note that some shortcuts may be captured by your browser, browser extensions, operating system, or other applications
To copy a region of text, first you need to select the text. The easiest way to do this is to highlight the text using your mouse curser.
The copy command is Ctrl-c
or Meta-w
Hold the Ctrl
key and press the c
key or press and release the ESC
key then press and release the w
key.
The Paste command is sometimes referred to as 'Yank' and is activated with Ctrl-v
or Ctrl-Y
Hold the Ctrl
key and press the v
key or press and hold Ctrl
the click the y
key.
The cursor can be moved to the beginning or the end of the current line.
This command is done with Ctrl-A
or the Home
key
Click Home
or hold the Ctrl
key and hit the a
key
This command is done with Ctrl-E
or the End
key
Click End
or hold the Ctrl
key and hit the e
key
See the complete list of available commands and shortcuts below.
In this table "Meta-" refers to hitting the ESC key followed by the shown key. For example to use Meta-B (ed-prev-word) hit ESC then release, then hit B and release. Optionally a Meta key can be setup on your keyboard.
Advanced configuration of Microsoft SQL Server connection type
Support for the SQL Server protocol within Keeper Connection Manager is provided by the kcm-libguac-client-sql-server
package. This package will be installed by default if the @kcm-guacamole
package group was used during installation, and is already installed within the keeper/guacd
Docker image. If this package has not yet been installed, SQL Server connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
If such an error appears within the guacd logs, simply installing kcm-libguac-client-sql-server
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of SQL Server support to take effect.
The SQL Server implementation in Keeper Connection Manager utilizes the SQL Server client library as well as an internal terminal library which renders the user interface. Guacamole's SQL Server support emulates a terminal on the server side, and draws the screen of this terminal remotely on the client.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
SQL Server connections are established over TCP to a specific port and a specific hostname or IP address. The hostname/address must be specified for all connections, but you only need to specify a port if you are not using the standard port (1433).
Keeper Connection manager supports SQL Server authentication through username and password parameters. Both fields are required to establish a connection.
The default database can be specified when establishing the connection. You can also disable the ability to perform CSV import and export of data.
Guacamole's SQL Server support provides a display, but not in the same sense as a remote desktop protocol like VNC or RDP. The display is a terminal emulator, and thus provides options for configuring the font used and its size.
If selecting a different font for a SQL Server connection, the chosen font must be installed on the server running guacd. It is the server that will handle rendering of characters to the terminal display, not the client.
Custom color schemes may be provided for the terminal emulator used by SQL Server connections. Custom schemes mimic the format used by Xterm and consist of a semicolon-separated series of name-value pairs. Each name-value pair is separated by a colon and assigns a value to a color in the terminal emulator palette.
For example, to use blue text on white background by default, and change the red color to a purple shade, you would specify:
Legal color names are:
"foreground
" - the default foreground color.
"background
" - the default background color.
"colorN
" - the color at index N within the Xterm 256-color palette. For example, "color9" refers to the color at palette index 9, normally red.
Legal color values are:
"rgb:RR/GG/BB" - a color in RGB format, with each component in hexadecimal. For example, "rgb:ff/00/00
" specifies the color red. Each hexadecimal component may be one to four digits, but the effective values are always zero-extended or truncated to two digits; for example, "rgb:f/8/0
", "rgb:f0/80/00
", and "rgb:f0f/808/00f
" all refer to the same effective color.
"colorN
" - the color currently assigned to index N within the Xterm 256-color palette. For example, "color9
" specifies the color currently assigned to palette index 9. Note that the current color value is used rather than a reference to that color. If the referenced color is changed later in the color scheme configuration, that new color value will not be reflected in this assignment.
Guacamole provides bidirectional access to the clipboard by default for SQL Server connections. This behavior can be overridden on a per-connection basis, restricting access to the clipboard.
The full, raw text content of SQL Server sessions, including timing information, can be recorded automatically to a specified directory. This recording, also known as a "typescript", will be written to two files within the directory specified: one file contains the raw text data, and the other contains timing information. Where "NAME
" is the value provided for the typescript name, these files will be named "NAME
" and "NAME.timing
" respectively.
This format is compatible with the format used by the standard UNIX script
command, and can be replayed using scriptreplay
(if installed). For example, to replay a typescript called "NAME
", you would run:
Connecting from the Docker container to the KCM host instance
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:
Advanced configuration of Telnet connection type
If such an error appears within the guacd logs, simply installing kcm-libguac-client-telnet
is sufficient to resolve the issue:
The guacd service does not need to be restarted for installation of telnet support to take effect.
This document is intended to cover all supported parameters, grouped in the same way they are grouped within the web interface. The field headings which would appear in the web interface are provided for each parameter, along with each parameter's internal name and a thorough description of the behavior and legal values for that parameter.
Telnet connections are established over TCP to a specific port and a specific hostname or IP address. The hostname/address must be specified for all telnet connections, but you only need to specify a port if you are not using the standard telnet port (23).
Telnet does not actually provide any standard means of authentication. Authentication over telnet depends entirely on the login process running on the server and is interactive. To cope with this, Guacamole provides non-standard mechanisms for automatically passing the username and entering password. Whether these mechanisms work depends on specific login process used by your telnet server.
The de-facto method for passing the username automatically via telnet is to submit it via the USER
environment variable, sent using telnet's "NEW-ENVIRON
" option. This is the mechanism used by most telnet clients, typically by specifying -l
on the command line.
Passwords cannot typically be sent automatically - at least not as reliably as the username. There is no PASSWORD
environment variable, nor any similar mechanism for passing the password to the telnet login process, and most telnet clients provide no built-in support for automatically entering the password. The best that can be done is to heuristically detect the password prompt and type the password on behalf of the user if/when the prompt appears. The prescribed method for doing this with a traditional command-line telnet is to use a utility like expect
. Guacamole provides similar functionality by searching for the password prompt with a regular expression. This same regular expression mechanism is also implemented as an option for handling the username prompt (if "NEW-ENVIRON
" is unavailable), as well as for detecting login success/failure.
Guacamole's telnet support provides a display, but not in the same sense as a remote desktop protocol like VNC or RDP. The display is a terminal emulator, and thus provides options for configuring the font used and its size.
If selecting a different font for a telnet connection, the chosen font must be installed on the server running guacd. It is the server that will handle rendering of characters to the terminal display, not the client.
Custom color schemes may be provided for the terminal emulator used by telnet connections. Custom schemes mimic the format used by Xterm and consist of a semicolon-separated series of name-value pairs. Each name-value pair is separated by a colon and assigns a value to a color in the terminal emulator palette.
For example, to use blue text on white background by default, and change the red color to a purple shade, you would specify:
Legal color names are:
"foreground
" - the default foreground color.
"background
" - the default background color.
"colorN
" - the color at index N within the Xterm 256-color palette. For example, "color9" refers to the color at palette index 9, normally red.
Legal color values are:
"rgb:RR/GG/BB" - a color in RGB format, with each component in hexadecimal. For example, "rgb:ff/00/00
" specifies the color red. Each hexadecimal component may be one to four digits, but the effective values are always zero-extended or truncated to two digits; for example, "rgb:f/8/0
", "rgb:f0/80/00
", and "rgb:f0f/808/00f
" all refer to the same effective color.
"colorN
" - the color currently assigned to index N within the Xterm 256-color palette. For example, "color9
" specifies the color currently assigned to palette index 9. Note that the current color value is used rather than a reference to that color. If the referenced color is changed later in the color scheme configuration, that new color value will not be reflected in this assignment.
Guacamole provides bidirectional access to the clipboard by default for telnet connections. This behavior can be overridden on a per-connection basis, restricting access to the clipboard.
In most cases, the default behavior of the Guacamole terminal emulator works without modification. However, when connecting to certain systems (particularly operating systems other than Linux), the terminal behavior may need to be tweaked to allow it to operate properly. Guacamole's telnet support provides parameters for controlling the control code sent for backspace, as well as the terminal type claimed via the TERM
environment variable.
The full, raw text content of telnet sessions, including timing information, can be recorded automatically to a specified directory. This recording, also known as a "typescript", will be written to two files within the directory specified: one file contains the raw text data, and the other contains timing information. Where "NAME
" is the value provided for the typescript name, these files will be named "NAME
" and "NAME.timing
" respectively.
This format is compatible with the format used by the standard UNIX script
command, and can be replayed using scriptreplay
(if installed). For example, to replay a typescript called "NAME
", you would run:
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the screen for more information.
A (as described below)
Field header | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header (web interface) | Parameter name | Description |
---|---|---|
Field header | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
"NAME
" - the color with human-readable name "NAME
", where "NAME
" is one of the . These names generally correspond to the names standardized by the W3C for CSS.
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
SQL Server sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the hosted at (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Glyptodon Enterprise Session Recording Player can be found on GitHub, along with instructions for local deployment:
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the documentation page.
Field header (web interface) | Parameter name | Description |
---|
Support for the telnet protocol within Keeper Connection Manager is provided by the kcm-libguac-client-telnet
package. Support for telnet is not installed by the @kcm
package group, but is installed within the. If this package has not yet been installed, telnet connections will not be functional, with guacd logging a warning noting the absence of needed protocol support:
Telnet is a text protocol and provides similar functionality to. By nature, it is not encrypted, and does not provide support for file transfer. As far as graphics are concerned, Guacamole's telnet support works in the same manner as : it emulates a terminal on the server side which renders to the Guacamole client's display.
Keeper's support for the telnet protocol is controlled through the use of several parameters. When a database like or is used, these parameters are presented in a convenient web interface. If defining connections through another mechanism, such as through or , parameters are specified using their internal parameter names.
Field header | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
"NAME
" - the color with human-readable name "NAME
", where "NAME
" is one of the . These names generally correspond to the names standardized by the W3C for CSS.
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Field header (web interface) | Parameter name | Description |
---|
Telnet sessions can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory. Recordings can be subsequently played back using the hosted at (or using a local deployment of this application).
The player is a static web application, using only JavaScript to play back provided recordings. This functionality is implemented strictly locally; the recordings are not uploaded to a remote service for processing. If you would prefer to use your own deployment of this application, or would like to investigate the source, the full source of the Keeper Connection Manager Session Recording Player can be found on GitHub, along with instructions for local deployment:
The latest version of Keeper Connection Manager supports on-screen playback of recorded sessions. See the documentation page.
Field header (web interface) | Parameter name | Description |
---|
Allow user-provided KSM configuration:
ksm-user-config-enabled
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the Multiple Vaults Integration screen for more information.
Hostname
hostname
REQUIRED: The hostname or IP address of the PostgreSQL server Guacamole should connect to.
Port
port
The port the PostgreSQL server is listening on. By default, the standard port of 5432 will be used.
Username
username
REQUIRED: The username to authenticate as when connecting to the specified PostgreSQL server.
Password
password
REQUIRED: The password to use when authenticating with the specified PostgreSQL server.
Default Database
database
The database schema selected when connecting to the specified PostgreSQL server.
Disable CSV Export
disable-csv-export
Set this value to "true" to disable CSV export of data when using the SQL export statement "COPY..."
Disable CSV Import
disable-csv-import
Set this value to "true" to disable CSV import of data when using the SQL import statement "COPY..."
Theme
color-scheme
The color scheme to use for the terminal emulator used by SSH connections. Each color scheme dictates the default foreground and background color for the terminal. Programs which specify colors when printing text will override these defaults. Legal values are:
"black-white
" - Black text over a white background
"gray-black
" - Gray text over a black background (the default)
"green-black
" - Green text over a black background
"white-black
" - White text over a black background
A custom color scheme (as described below)
By default, Guacamole will render text as gray over a black background.
Font name
font-name
The name of the font to use. If not specified, the default of "monospace" will be used instead. This must be the name of a font installed on the server running guacd, and should be a monospaced font. If a non-monospaced font is used, individual glyphs may render incorrectly.
Font size
font-size
The size of the font to use, in points. By default, the size of rendered text will be 12 point.
Maximum scrollback size:
scrollback
The maximum number of rows to allow within the terminal scrollback buffer. By default, the scrollback buffer will be limited to a maximum of 1000 rows.
Read-only:
read-only
Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will be able to see the terminal (or the application running within the terminal) but will be unable to interact.
Disable copying from terminal:
disable-copy
If set to "true", text copied within the PostgreSQL session will not be accessible by the user at the browser side of the Guacamole session, and will be usable only within the remote desktop. By default, the user will be given access to the copied text.
Disable pasting from client:
disable-paste
If set to "true", text copied at the browser side of the Guacamole session will not be accessible within the PostgreSQL session. By default, the user will be able to paste data from outside the browser within the PostgreSQL session.
Typescript path
typescript-path
The directory in which typescript files should be created. If a typescript needs to be recorded, then this parameter is required. Specifying this parameter enables typescript recording. If this parameter is omitted, no typescript will be recorded.
Typescript name
typescript-name
The base filename to use for any created recordings. If omitted, the base filename "typescript" will be used.
Guacamole will never overwrite an existing typescript. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the base filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the typescript will not be recorded, and an error will be logged.
This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored.
Automatically create typescript path
create-typescript-path
If set to "true", the final directory within the specified typescript path will automatically be created if it does not yet exist. By default, no part of the typescript path will be automatically created, and any attempt to use a non-existent directory will result in the typescript not being recorded and an error being logged.
Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the typescript will not be recorded, and an error will be logged.
This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored.
Recording path
recording-path
The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created.
Recording name
recording-name
The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording".
Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude graphics/streams
recording-exclude-output
If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Exclude mouse
recording-exclude-mouse
If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Include key events
recording-include-keys
If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the guaclog
utility to produce a human-readable interpretation of the keys pressed during the session. By default, for privacy's sake, key events will be NOT included in the recording.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Automatically create recording path
create-recording-path
If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged.
Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged.
This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored.
Shortcut
Editor Command
Ctrl-@, NUL
set cursor where the mouse is located
Ctrl-A
move cursor to beginning of line
Ctrl-B
move cursor back one character
Ctrl-C
clear the terminal
Ctrl-D
close the current connection
Ctrl-E
move cursor to end of line
Ctrl-F
move cursor one character forward
Ctrl-H, Backspace
delete previous character
Ctrl-J, LF
newline
Ctrl-K
cut line
Ctrl-L, FF
clear screen
Ctrl-M, CR
newline
Ctrl-N
next history
Ctrl-O
tty flush output
Ctrl-P
previous history
Ctrl-Q
tty start output
Ctrl-R
redisplay
Ctrl-S
tty stop output
Ctrl-T
transpose characters
Ctrl-U
cut line
Ctrl-V
quoted insert
Ctrl-W
cut highlighted region
Ctrl-X
sequence lead in
Ctrl-Y
yank (paste)
Ctrl-Z, TSTP
tty sigtstp
Ctrl-[, ESC
move cursor forward
Ctrl-\, QUIT
tty sigquit
Ctrl-]
tty dsusp
Ctrl-?, DEL
delete previous character
Ctrl-Meta-H
delete previous word
Ctrl-Meta-L
clear screen
Ctrl-Meta-_
copy the previous word
Meta-0 to Meta-9
argument digit
Meta-B
previous word
Meta-C
use capitol case
Meta-D
delete next word
Meta-F
move to next word
Meta-L
lower case
Meta-N
search next history
Meta-O
sequence lead in
Meta-P
search previous history
Meta-U
upper case
Meta-W
copy highlighted region
Meta-X
command
Meta-[
sequence lead in
Meta-p
search previous history
Ctrl-Meta-?
delete previous word
Shortcut | Editor Command |
Ctrl-@, NUL | set cursor where the mouse is located |
Ctrl-A | move cursor to beginning of line |
Ctrl-B | move cursor back one character |
Ctrl-C | clear the terminal |
Ctrl-D | close the current connection |
Ctrl-E | move cursor to end of line |
Ctrl-F | move cursor one character forward |
Ctrl-H, Backspace | delete previous character |
Ctrl-J, LF | newline |
Ctrl-K | cut line |
Ctrl-L, FF | clear screen |
Ctrl-M, CR | newline |
Ctrl-N | next history |
Ctrl-O | tty flush output |
Ctrl-P | previous history |
Ctrl-Q | tty start output |
Ctrl-R | redisplay |
Ctrl-S | tty stop output |
Ctrl-T | transpose characters |
Ctrl-U | cut line |
Ctrl-V | quoted insert |
Ctrl-W | cut highlighted region |
Ctrl-X | sequence lead in |
Ctrl-Y | yank (paste) |
Ctrl-Z, TSTP | tty sigtstp |
Ctrl-[, ESC | move cursor forward |
Ctrl-\, QUIT | tty sigquit |
Ctrl-] | tty dsusp |
Ctrl-?, DEL | delete previous character |
Ctrl-Meta-H | delete previous word |
Ctrl-Meta-L | clear screen |
Ctrl-Meta-_ | copy the previous word |
Meta-0 to Meta-9 | argument digit |
Meta-B | previous word |
Meta-C | use capitol case |
Meta-D | delete next word |
Meta-F | move to next word |
Meta-L | lower case |
Meta-N | search next history |
Meta-O | sequence lead in |
Meta-P | search previous history |
Meta-U | upper case |
Meta-W | copy highlighted region |
Meta-X | command |
Meta-[ | sequence lead in |
Meta-p | search previous history |
Ctrl-Meta-? | delete previous word |
Shortcut | Editor Command |
Ctrl-@, NUL | set cursor where the mouse is located |
Ctrl-A | move cursor to beginning of line |
Ctrl-B | move cursor back one character |
Ctrl-C | clear the terminal |
Ctrl-D | close the current connection |
Ctrl-E | move cursor to end of line |
Ctrl-F | move cursor one character forward |
Ctrl-H, Backspace | delete previous character |
Ctrl-J, LF | newline |
Ctrl-K | cut line |
Ctrl-L, FF | clear screen |
Ctrl-M, CR | newline |
Ctrl-N | next history |
Ctrl-O | tty flush output |
Ctrl-P | previous history |
Ctrl-Q | tty start output |
Ctrl-R | redisplay |
Ctrl-S | tty stop output |
Ctrl-T | transpose characters |
Ctrl-U | cut line |
Ctrl-V | quoted insert |
Ctrl-W | cut highlighted region |
Ctrl-X | sequence lead in |
Ctrl-Y | yank (paste) |
Ctrl-Z, TSTP | tty sigtstp |
Ctrl-[, ESC | move cursor forward |
Ctrl-\, QUIT | tty sigquit |
Ctrl-] | tty dsusp |
Ctrl-?, DEL | delete previous character |
Ctrl-Meta-H | delete previous word |
Ctrl-Meta-L | clear screen |
Ctrl-Meta-_ | copy the previous word |
Meta-0 to Meta-9 | argument digit |
Meta-B | previous word |
Meta-C | use capitol case |
Meta-D | delete next word |
Meta-F | move to next word |
Meta-L | lower case |
Meta-N | search next history |
Meta-O | sequence lead in |
Meta-P | search previous history |
Meta-U | upper case |
Meta-W | copy highlighted region |
Meta-X | command |
Meta-[ | sequence lead in |
Meta-p | search previous history |
Ctrl-Meta-? | delete previous word |
Hostname |
| REQUIRED: The hostname or IP address of the SQL server Guacamole should connect to. |
Port |
| The port the SQL Server is listening on. By default, the standard port of 1433 will be used. |
Username |
| REQUIRED: The username to authenticate as when connecting to the specified SQL server. |
Password |
| REQUIRED: The password to use when authenticating with the specified SQL server. |
Default Database |
| The database schema selected when connecting to the specified SQL server. |
Disable CSV Export |
| Set this value to "true" to disable CSV export of data when using the SQL statement "SELECT INTO LOCAL OUTFILE" |
Disable CSV Import |
| Set this value to "true" to disable CSV import of data when using the SQL statement "BULK INSERT..." |
Disable copying from terminal: |
| If set to "true", text copied within the SQL Server session will not be accessible by the user at the browser side of the Guacamole session, and will be usable only within the remote desktop. By default, the user will be given access to the copied text. |
Disable pasting from client: |
| If set to "true", text copied at the browser side of the Guacamole session will not be accessible within the session. By default, the user will be able to paste data from outside the browser within the SQL Server session. |
Typescript path |
| The directory in which typescript files should be created. If a typescript needs to be recorded, then this parameter is required. Specifying this parameter enables typescript recording. If this parameter is omitted, no typescript will be recorded. |
Typescript name |
| The base filename to use for any created recordings. If omitted, the base filename "typescript" will be used. Guacamole will never overwrite an existing typescript. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the base filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the typescript will not be recorded, and an error will be logged. This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored. |
Automatically create typescript path |
| If set to "true", the final directory within the specified typescript path will automatically be created if it does not yet exist. By default, no part of the typescript path will be automatically created, and any attempt to use a non-existent directory will result in the typescript not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the typescript will not be recorded, and an error will be logged. This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored. |
Recording path |
| The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created. |
Recording name |
| The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording". Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude graphics/streams |
| If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude mouse |
| If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Include key events |
| If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Automatically create recording path |
| If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Hostname: |
| REQUIRED: The hostname or IP address of the telnet server Guacamole should connect to. |
Port: |
| The port the telnet server is listening on. By default, the standard telnet port of 23 will be used. |
Username: |
| The username to use to authenticate, if any. If not specified, or not supported by the telnet server, the login process on the telnet server will prompt you for your credentials. For this to work, your telnet server must either support the " |
Password: |
| The password to use when attempting authentication, if any. If specified, your password will be typed on your behalf when the password prompt is detected. |
Username regular expression: |
| The regular expression to use to detect the username prompt when the username cannot be provided using " |
Password regular expression: |
| The regular expression to use to detect the password prompt. If not specified, a reasonable default built into Guacamole will be used. Any regular expression provided must be written in the standard POSIX ERE dialect (the dialect used by |
Login success regular expression: |
| The regular expression to use when detecting that the login attempt has succeeded. If specified, the terminal display will not be shown to the user until text matching this regular expression has been received from the telnet server. Any regular expression provided must be written in the standard POSIX ERE dialect (the dialect used by |
Login failure regular expression: |
| The regular expression to use when detecting that the login attempt has failed. If specified, the connection will be closed with an explicit login failure error if text matching this regular expression has been received from the telnet server. Any regular expression provided must be written in the standard POSIX ERE dialect (the dialect used by |
Color scheme: |
| The color scheme to use for the terminal emulator used by telnet connections. Each color scheme dictates the default foreground and background color for the terminal. Programs which specify colors when printing text will override these defaults. Legal values are:
By default, Guacamole will render text as gray over a black background. |
Font name: |
| The name of the font to use. If not specified, the default of "monospace" will be used instead. This must be the name of a font installed on the server running guacd, and should be a monospaced font. If a non-monospaced font is used, individual glyphs may render incorrectly. |
Font size: |
| The size of the font to use, in points. By default, the size of rendered text will be 12 point. |
Maximum scrollback size: |
| The maximum number of rows to allow within the terminal scrollback buffer. By default, the scrollback buffer will be limited to a maximum of 1000 rows. |
Read-only: |
| Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will be able to see the terminal (or the application running within the terminal) but will be unable to interact. |
Disable copying from terminal: |
| If set to "true", text copied within the telnet session will not be accessible by the user at the browser side of the Guacamole session, and will be usable only within the remote desktop. By default, the user will be given access to the copied text. |
Disable pasting from client: |
| If set to "true", text copied at the browser side of the Guacamole session will not be accessible within the telnet session. By default, the user will be able to paste data from outside the browser within the telnet session. |
Backspace key sends: |
| The integer value of the terminal control code that should be sent when backspace is pressed. Under most circumstances this should not need to be adjusted; however, if, when pressing the backspace key, you see control characters (often either ^? or ^H) instead of seeing the text erased, you may need to adjust this parameter. By default, the control code 127 (Delete) is sent. |
Terminal type: |
| The terminal type string that should be passed to the telnet server. This value will typically be exposed within the telnet session as the TERM environment variable and will affect the control characters sent by applications. By default, the terminal type string "linux" is used. |
Typescript path: |
| The directory in which typescript files should be created. If a typescript needs to be recorded, then this parameter is required. Specifying this parameter enables typescript recording. If this parameter is omitted, no typescript will be recorded. |
Typescript name: |
| The base filename to use for any created recordings. If omitted, the base filename "typescript" will be used. Guacamole will never overwrite an existing typescript. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the base filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the typescript will not be recorded, and an error will be logged. This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored. |
Automatically create typescript path: |
| If set to "true", the final directory within the specified typescript path will automatically be created if it does not yet exist. By default, no part of the typescript path will be automatically created, and any attempt to use a non-existent directory will result in the typescript not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the typescript will not be recorded, and an error will be logged. This parameter only has an effect if typescript recording is enabled, which is controlled by specifying a typescript path. If the typescript path is not specified, recording of typescripts will not be enabled, and this parameter will be ignored. |
Recording path: |
| The directory in which screen recording files should be created. If a graphical recording needs to be created, then this parameter is required. Specifying this parameter enables graphical screen recording. If this parameter is omitted, no graphical recording will be created. |
Recording name: |
| The filename to use for any created recordings. If omitted, the filename of each recording will simply be "recording". Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like ".1", ".2", ".3", etc. will be appended to the filename to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude graphics/streams: |
| If set to "true", graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events. By default, graphical output will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Exclude mouse: |
| If set to "true", user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor. By default, mouse events will be included in the recording. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Include key events: |
| If set to "true", user key events will be included in the recording. The recording can subsequently be passed through the This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Automatically create recording path: |
| If set to "true", the final directory within the specified recording path will automatically be created if it does not yet exist. By default, no part of the recording path will be automatically created, and any attempt to use a non-existent directory will result in the session not being recorded and an error being logged. Only the final directory in the path will be automatically created. If other directories earlier in the path do not exist, the session will not be recorded, and an error will be logged. This parameter only has an effect if graphical recording is enabled, which is controlled by specifying a recording path. If the recording path is not specified, graphical session recording will not be enabled, and this parameter will be ignored. |
Data can be imported to a SQL Server connection from a file on your machine, or exported and downloaded to you machine.
Import data from a file on your machine into the SQL Server 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.
The file uploaded does not have to have the same name given in the query
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.
Allow user-provided KSM configuration: |
|
Theme |
| The color scheme to use for the terminal emulator used by SSH connections. Each color scheme dictates the default foreground and background color for the terminal. Programs which specify colors when printing text will override these defaults. Legal values are:
By default, Guacamole will render text as gray over a black background. |
Font name |
| The name of the font to use. If not specified, the default of "monospace" will be used instead. This must be the name of a font installed on the server running guacd, and should be a monospaced font. If a non-monospaced font is used, individual glyphs may render incorrectly. |
Font size |
| The size of the font to use, in points. By default, the size of rendered text will be 12 point. |
Maximum scrollback size: |
| The maximum number of rows to allow within the terminal scrollback buffer. By default, the scrollback buffer will be limited to a maximum of 1000 rows. |
Read-only: |
| Whether this connection should be read-only. If set to "true", no input will be accepted on the connection at all. Users will be able to see the terminal (or the application running within the terminal) but will be unable to interact. |
Allow user-provided KSM configuration: |
|
Connecting to an environment without ingress connections
Oftentimes, it is 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.
Please make sure you have already configured and installed your KCM server instance prior to establishing the reverse ssh tunnel. Installation instructions are located here: https://docs.keeper.io/keeper-connection-manager/installation/auto-docker-install
Connecting to an environment without ingress connections
If you prefer to run autossh as a windows service, you can follow these steps.
KCM Server: The instance running Keeper Connection Manager.
Remote Endpoint: A target Windows instance in a protected network without data ingress which cannot yet be accessed directly by the KCM Server.
On the remote endpoint, install Cygwin from https://www.cygwin.com/install.html. The direct download link is https://www.cygwin.com/setup-x86_64.exe.
After it's installed, we will select both the openssh and the autossh packages to download and install.
Click Next > Install from Internet > All Users > Next > Next > Next > Choose any mirror > Next (as shown below).
At the "Select Packages" screen, change the view from Pending to Full and then enter "ssh" in the search box. Select the down arrow on autossh, choose latest version. Select the down arrow on openssh, choose the latest version (shown below).
The instructions below outline how to establish a connection from a KCM Server in the cloud, to a 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 Keys on the Remote Endpoint
On the Windows Remote Endpoint, using Cygwin Terminal create an SSH key pair which will be used to establish an outbound connection from the Endpoint to the KCM Server. Enter the following into the Cygwin Terminal:
It will ask where you want to save the key, you can just press enter to take the default and continue.
This will create two files, a private key and a public key. Leave the private key in place. We will copy the public key from the target endpoint onto the KCM server.
Next, we will copy the public key file (.pub) from the windows endpoint to the KCM Server in ~/.ssh/authorized_keys.
You can transfer the .pub file by any method that you choose.
You can transfer the .pub file by any method that you choose. If you have outbound traffic allowed on the windows target endpoint, you can use the following command in the Cygwin Terminal:
(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.
(4) Establish the persistent SSH tunnel
To create the persistent tunnel, enter the following two commands into the windows command prompt or PowerShell (not in the Cygwin Terminal):
Make sure that you have a firewall in place to block inbound connections on all ports except what is needed (HTTP/HTTPS/SSH). And/or change the 0.0.0.0 in the following command to the IP of your KCM server.
Choose any open port to use, in this example we use port 9000.
(5) Configure the Windows Service
Open Services and look for the new service called "AutoSSH" and open it, but don't start it just yet.
We will set an automatic delayed start and logon by the Administrator account. These will help allow the service to start properly.
On the Log On tab, click browser and enter the administrator object name and click "Check Names". Make sure to put the password for the administrator account into both fields.
Now we are ready to start the AutoSSH Service (shown below).
Start the AutoSSH service and confirm that it is running.
(6) Update GatewayPorts setting on KCM Server
This step only needs to be completed once, so if you have already completed it while setting up a different reverse ssh tunnel method, you can move on to step 8
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
The reverse tunnel is now established between the Remote Server and the KCM Server.
(7) Update docker-compose to reference the host
This step applies only to the docker installations.
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.
Create a new RDP connection with the hostname of host.docker.internal
and the port of 9000 (or your chosen port).
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.
If you would like to establish more connections using reverse SSH tunneling, repeat Step 5 of this guide on a different available port (e.g. 9001, 9002, etc...). Then create a connection with the specified port number when creating Connections inside Keeper Connection Manager.
Several references and guides posted online contain helpful information about this configuration.
Features and functionality of the Keeper Connection Manager interface
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.
Selecting connections and user settings.
Features and functionality of the connection session and the sidebar menu.
Manage the clipboard, view multiple connections at once, upload or download files, and change input settings within a connection session
How to create Keeper Connection Manager connections for each supported protocol type
Configure and use Keeper Connection Manager drag-and-drop file transfer
Share access to Keeper Connection Manager connections with anyone with an internet browser
How to configure screen and keystroke recording for all session types.
Connecting to an environment without ingress connections
KCM Server: The instance running Keeper Connection Manager.
Remote Endpoint: A target Windows instance in a protected network without data ingress which cannot yet be accessed directly by the KCM Server.
Good news, Windows now comes with OpenSSH! However, it may not be installed by default. We recommend Installing both the OpenSSH Client and the OpenSSH Server.
OpenSSH can be found in "Optional Features" in Windows 10+ and Windows Server 2019+. You can install it from Settings > Apps > Optional Features > Add Feature > Open SSH Client / Server.
The instructions below outline how to establish a connection from a KCM Server in the cloud, to a 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 Keys on the Remote Endpoint
On the Windows Remote Endpoint, create an SSH key pair which will be used to establish an outbound connection from the Endpoint to the KCM Server. Enter the following into an elevated command prompt:
This will create two files, a private key and a public key. Leave the private key in place.
Next, we will copy the public key file (.pub) from the windows endpoint to the KCM Server.
You can copy the .pub file using any method you choose
If you have outbound traffic allowed, you can use the following command in PowerShell as Administrator:
(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 prompt.
(4) Establish the ssh tunnel
Make sure that you have a firewall in place to block inbound connections on all ports except what is needed (HTTP/HTTPS/SSH). And/or change the 0.0.0.0 in the following command to the IP of your KCM server.
To create a persistent session, we will utilize a batch file with an ssh command, and the windows task scheduler. First, open notepad and copy in the following command:
Edit the command with the values that correspond to your path, desired port, and URL, and save the file as a .bat file.
Open Windows Task Scheduler, create a new task with a trigger set to "on startup" and an action to run the .bat file that you created.
(5) Update GatewayPorts setting on KCM Server
This step only needs to be completed once, so if you have already completed it while setting up a different reverse ssh tunnel method, you can move on to step 7
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
The reverse tunnel is now established between the Remote Server and the KCM Server.
(6) Update docker-compose to reference the host
This step applies only to the docker installations.
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.
(7) 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.
Create a new RDP connection with the hostname of host.docker.internal
and the port of 9000 (or your chosen port).
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.
If you would like to establish more connections using reverse SSH tunneling, repeat Step 4 of this guide on a different port (e.g. 9001, 9002, etc...). Then create a connection with the specified port number when creating Connections inside Keeper Connection Manager.
Several references and guides posted online contain helpful information about this configuration.
Connecting to an environment without ingress connections
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.
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.
Make sure that you have a firewall in place to block inbound connections on all ports except what is needed (HTTP/HTTPS/SSH). And/or change the 0.0.0.0 in the following command to the IP of your KCM server.
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
This step applies only to the docker installations.
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.
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.
Several references and guides posted online contain helpful information about this configuration.
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the screen for more information.
A (as described below)
If set to "true", each Keeper Connection Manager user profile can be assigned to a Keeper Secrets Manager configuration for any connection. See the screen for more information.
Microsoft's instructions for installing OpenSSH are here:
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.
Keeper Connection Manager user guide - home screen
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.
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.
If a user only has access to a single remote connection, they will immediately connect upon login.
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.
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.
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.
Logs out of Keeper Connection Manager completely, closing all current connections and ending the Keeper Connection Manager session.
Keeper Connection Manager User Guide - Login Screen
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.
Users use their username to login to Keeper Connection Manager. This username is set when creating or importing users.
The KCM username is sometimes an email address, but it can be a non-email username as well.
The user's password. Set when creating or importing the user. Passwords can also be reset by users if allowed.
TIP: The Keeper Browser Extension can be used to automatically fill in the Keeper Connection Manager username and password!
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
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.
By default KCM will lock a user out of logging in for 5 minutes after 5 failed attempts
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):
Managing and creating connections to your infrastructure
Connections specify the protocol and customizable parameters that define the authentication and customized behavior. Connections can be created from the Settings menu. Only users with "Create new connections" permission can create connections.
Administrators can define which connections are available for users and groups.
Connections can be created and utilized in several ways. Connections can be privileged (credentials hidden from the user) and the connections can support user-specified credentials. Additionally, the connections can pull credentials from one or more Keeper Vaults via the Keeper Secrets Manager integration.
When setting up a privileged connection, the authentication credentials to the target can be saved in the connection parameters, or in the designated Keeper Vault. When the credentials are stored directly to the connection or in the Keeper Vault, they are never exposed to the end-user. This allows you to create privileged sessions in which the user does not have access to the underlying credentials.
When setting up the connection, you can skip the authentication details parameters and Keeper Connection Manager will prompt the end-user for their authentication credentials on every login.
For example, with an RDP connection, simply remove the credentials from the connection parameters and the user will be prompted to authenticate.
KCM can connect to a Keeper Vault and search for the necessary credentials needed based on Host, User and Domain. See the Vault Integration section to learn more about this capability.
The New Connection form is separated into multiple sections each with multiple inputs. Connections have many different options and capabilities, depending on the protocol.
To begin, click Settings > Connections > New Connection which will open the new connection form.
The name of the connection, this is how it will appear in the connections list.
The location of the new connection in the connections list. You can select "ROOT" to put the new connection at the top level of the connections list, or select a collection to place the new connection under an existing collection.
Select the type of connection to create. The current available connection types are:
RDP
SSH
Kubernetes
Telnet
VNC
MySQL
PostgreSQL
Microsoft SQL Server
Other options in the connection form are affected by the protocol selection
For more information about connection types, see the supported protocols section.
Create multiple connections via API or by uploading a CSV, JSON, or YAML file. Visit the following page for more information:
The maximum allowed number of concurrent sessions for this connections. If the maximum number is sessions are already in use, other users will not be able to connect to this connection.
Set this value to 0 to allow unlimited concurrent sessions.
The maximum allowed number of concurrent sessions for this connection for each user. If the maximum number is sessions are already in use by a user, the user will not be able to open a new session for this connection.
Set this value to 0 to allow unlimited concurrent sessions.
Keeper Connection Manager can use load balancing among connections in a group to give multiple concurrent users the best experience.
Enter a number to use as a multiplier of connection assignment. For example, if one connection in a group has a weight of 1, and another has a weight of 2, the second connection will be assigned twice as many concurrent users as the first.
If checked, this connection will only be used if all other connections in the group fail
If you are establishing a connect through a guacd service which is operating on a separate server (other than localhost), you would specify the proxy parameters here. In most default installations, this section is not needed and should be left empty. For more information see the guacd documentation.
Hostname and port of the proxy
Choose if the connection traffic should be encrypted. You can choose unencrypted or TLS/SSL encryption.
Details to facilitate the new RDP connection. Set network and authentication details.
Enter the hostname and port of the RDP connection
Enter the following connection fields for you RDP connection:
Username
Password
Domain
Select the security mode to use, the supported modes are:
Any
NLA (Network Level Authentication)
RDP Encryption
TLS Encryption
Hyper-V / VMConnect
If you would like users to be prompted for manual authentication, you may need to select "NLA" security mode and leave the authentication parameters empty.
Choose to turn off authentication for this RDP connection
Choose to ignore the server certificate. In most cases, this is required to establish a connection.
Fill in the following details about the remote desktop gateway:
Hostname and Port
Username
Password
Domain
Start a program on connection. Enter the location of the program to run
Set a name for the computer this connection is connecting to
Choose the type of keyboard to use with this RDP connection
Use the dropdown menus to select the timezone to use with this connection
Choose to allow multi-touch input for this RDP connection
Choose to allow access to the Administrator Console for users connecting to this RDP connection
Choose settings that affect how the new connection will look.
Choose the dimensions and resolution of the screen in pixels (pixels per inch for resolution).
Choose the color depth of the screen over the RDP connection.
Use lossless compression. Check this option for better visual quality, but it may impact performance.
Choose what the connection should do if the window is resized. Keeper Connection Manager supports "Display Update" Visual channel for RDP 8.1 or higher. For older versions of RDP, use the reconnect method.
If checked, the connection will not allow for any interaction from the user. The user will be able to view what is happening on the connected device, but make no interactions with it.
If selected, users will not be able to copy from the connection
If selected, users will not be able to paste values into the connection
Choose options for connected devices
Choose if audio is supported within the console
Choose if audio from the connection should be disabled
Choose if the user's microphone can be used within the connection
Choose if users can print from the connection
If allowing printing, choose the name of the printer to use
If you would like to transfer files to this target with Drag and Drop, select this option. Along with this, make sure to fill out a "Drive Name", "Drive Path", and select "Automatically Create Drive".
If file transfer is enabled, the name of the drive to use. For example "My Drive".
Choose if files can be downloaded to the connected drive
The path of the drive to use if enabled. A typical default Drive Path would be something like /var/lib/guacamole/drives/${GUAC_USERNAME}
If selected, Keeper Connection Manager will automatically create a drive to use with the connection
A comma-separated list of static channel names to open and expose as pipes. If you wish to communicate between an application running on the remote desktop and JavaScript, this is the best way to do it. KCM will open an outbound pipe with the name of the static channel. If JavaScript needs to communicate back in the other direction, it should respond by opening another pipe with the same name. KCM allows any number of static channels to be opened, but protocol restrictions of RDP limit the size of each channel name to 7 characters.
These options can be used to optimize the performance of the Windows Remote Desktop Connection.
Choose to enable or disable the following optional Windows features:
Enable Wallpaper
Enable Theming
Enable Font Smoothing (ClearType)
Enable Full-window Drag
Enable Desktop Composition (Aero)
Enable Menu Animations
Disable Bitmap Caching
Disable Off-screen Caching
Disable Glyph Caching
Recent versions of Windows provide a feature called RemoteApp which allows individual applications to be used over RDP, without providing access to the full desktop environment. If your RDP server has this feature enabled and configured, you can configure KCM connections to use those individual applications.
Specifies the RemoteApp to start on the remote desktop. If supported by your remote desktop server, this application, and only this application, will be visible to the user.
Windows requires a special notation for the names of remote applications. The names of remote applications must be prefixed with two vertical bars. For example, if you have created a remote application on your server for notepad.exe
and have assigned it the name “notepad”, you would set this parameter to: “||notepad
”.
The working directory, if any, for the remote application. This parameter has no effect if RemoteApp is not in use.
The command-line arguments, if any, for the remote application. This parameter has no effect if RemoteApp is not in use.
Keeper Connection Manager can use load balancing among connections in a group to give multiple concurrent users the best experience.
Enter a number to use as a multiplier of connection assignment. For example, if one connection in a group has a weight of 1, and another has a weight of 2, the second connection will be assigned twice as many concurrent users as the first.
If checked, this connection will only be used if all other connections in the group fail
Options for recording of the screen. See the Session Recording section for more information.
Enter the path to save the session recording. We recommend using the below value:
${HISTORY_PATH}/${HISTORY_UUID}
Enter the name of the recording file
Choose to exclude graphics or streams from the recording
Choose to exclude the mouse from the screen recording
Choose to exclude the touch events the user made from the recording
If selected, include key events that would not otherwise be visible in the recording
If selected, Keeper Connection Manager will automatically create a path for the recording file
Options for file transfers to the connection using SFTP. For more information see the File Transfer section.
Choose to enable SFTP file transfers
If enabled, enter the following information to connect to and authenticate connection to your SFTP server:
Hostname Port
Public Host Key (Base64)
Username and Password
Private Key
Passphrase for the private key if applicable
The root directory of the SFTP server to display within this connection
If users upload a file from the connection, the directory that the file will go to by default
Enter the keepalive interval as a number
If SFTP is enabled, check this option to exclude users from downloading files from the server to this connection
If SFTP is enabled, check this option to exclude users from uploading files to the server from this connection
Options to facilitate waking the connected device upon connection if supported.
Enable Wake-on-Lan and send a signal from Keeper Connection Manager
Identify the device to send the signal to by Mac Address
Where to send the WoL signal
How long to wait for the device to wake
Details to facilitate the new SSH connection. Set network and authentication details.
Enter the hostname and port for the SSH connection
Enter the Public Key for this SSH connection in Base64 format
The username and password (if required) for this SSH connection.
If you would like the user to be prompted for their password, leave the "password" field empty.
The private key used for connecting to this SSH connection
The passphrase (if any) for the private key
Choose settings that affect how the new connection will look.
Select a color theme for the terminal.
There are built in themes, and a custom theme option.
Enter the name of a font for the terminal to use
Select the pixel size of the font
Select how far back a user can scroll through past commands. Leave blank for unlimited.
If checked, the connection will not allow for any interaction from the user. The user will be able to view what is happening on the connected device, but make no interactions with it.
If selected, users will not be able to copy from the connection
If selected, users will not be able to paste values into the connection
Settings for basic environment setup
Enter a command to execute on connection start
Set the language/local for the connection, this sets the $LANG environment variable
Set the time zone for the connection. This sets the $TZ environment variable
Set an interval for a keepalive signal
The Terminal Behavior section contains options about the terminal for applicable connections.
Choose what action is sent when you click the backspace key. The options are:
Delete
Backspace
Choose the type of terminal to use. The options are:
ansi
linux
vt100
vt220
vterm
vterm-256color
Options for recording of the screen. See the Session Recording section for more information.
Enter the path to save the session recording. We recommend setting this to ${HISTORY_PATH}/${HISTORY_UUID}
Enter the name of the recording file
Choose to exclude graphics or streams from the recording
Choose to exclude the mouse from the screen recording
If selected, include key events that would not otherwise be visible in the recording
If selected, Keeper Connection Manager will automatically create a path for the recording file
Options for file transfers to the connection using SFTP. For more information see the File Transfer section.
Choose to enable SFTP file transfers
The root directory of the SFTP server to display within this connection
If SFTP is enabled, check this option to exclude users from downloading files from the server to this connection
If SFTP is enabled, check this option to exclude users from uploading files to the server from this connection
Options to facilitate waking the connected device upon connection if supported.
Enable Wake-on-Lan and send a signal from Keeper Connection Manager
Identify the device to send the signal to by Mac Address
Where to send the WoL signal
How long to wait for the device to wake
Details to facilitate the new VNC connection. Set network and authentication details.
Hostname and port information for the VNC connection
Choose encryption method for connection traffic. The options are:
No Encryption
TLS/SSL Encryption
Login credentials for the VNC connection. If you would like to prompt users for the password, leave this field empty.
Choose settings that affect how the new connection will look.
If checked, the connection will not allow for any interaction from the user. The user will be able to view what is happening on the connected device, but make no interactions with it.
Choose if the red and blue channels should be swapped for this connection.
Choose to use the cursor of the local machine, or of the remote machine.
Choose the color depth of the screen over the VNC connection.
Use lossless compression. Check this option for better visual quality, but it may impact performance.
Choose which encoding to use when copying and pasting. The options are:
CP1252
ISO 8859-1
UTF-16
UTF-8
If selected, users will not be able to copy from the connection
If selected, users will not be able to paste values into the connection
There exist VNC repeaters, such as UltraVNC Repeater, which act as intermediaries or proxies, providing a single logical VNC connection which is then routed to another VNC server elsewhere. Additional parameters are required to select which VNC host behind the repeater will receive the connection.
Set the host and port to use
Options for recording of the screen. See the Session Recording section for more information.
Enter the path to save the session recording. We recommend setting this to ${HISTORY_PATH}/${HISTORY_UUID}
Enter the name of the recording file
Choose to exclude graphics or streams from the recording
Choose to exclude the mouse from the screen recording
If selected, include key events that would not otherwise be visible in the recording
If selected, Keeper Connection Manager will automatically create a path for the recording file
Options for file transfers to the connection using SFTP. For more information see the File Transfer section.
Choose to enable SFTP file transfers
If enabled, enter the following information to connect to and authenticate connection to your SFTP server:
Hostname Port
Public Host Key (Base64)
Username and Password
Private Key
Passphrase for the private key if applicable
The root directory of the SFTP server to display within this connection
If users upload a file from the connection, the directory that the file will go to by default
Enter the keepalive interval as a number
If SFTP is enabled, check this option to exclude users from downloading files from the server to this connection
If SFTP is enabled, check this option to exclude users from uploading files to the server from this connection
Choose to enable audio for the connection
Name of the audio server to use
Options to facilitate waking the connected device upon connection if supported.
Enable Wake-on-Lan and send a signal from Keeper Connection Manager
Identify the device to send the signal to by Mac Address
Where to send the WoL signal
How long to wait for the device to wake
Details to facilitate the new Telnet connection. Set network and authentication details.
Hostname and port information for the Telnet connection.
Authentication credentials for the Telnet connection. To prompt users for the password, leave this field empty.
The regular expression to use when waiting for the username prompt. This parameter is optional. If not specified, a reasonable default built into KCM will be used. The regular expression must be written in the POSIX ERE dialect (the dialect typically used by egrep).
The regular expression to use when waiting for the password prompt. This parameter is optional. If not specified, a reasonable default built into KCM will be used. The regular expression must be written in the POSIX ERE dialect (the dialect typically used by egrep).
The regular expression to use when detecting that the login attempt has succeeded. This parameter is optional. If specified, the terminal display will not be shown to the user until text matching this regular expression has been received from the telnet server. The regular expression must be written in the POSIX ERE dialect (the dialect typically used by egrep
).
The regular expression to use when detecting that the login attempt has failed. This parameter is optional. If specified, the connection will be closed with an explicit login failure error if text matching this regular expression has been received from the telnet server. The regular expression must be written in the POSIX ERE dialect (the dialect typically used by egrep
).
Choose settings that affect how the new connection will look.
Select a color theme for the terminal.
There are built in themes, and a custom theme option.
Enter the name of a font for the terminal to use
Select the pixel size of the font
Select how far back a user can scroll through past commands. Leave blank for unlimited.
If checked, the connection will not allow for any interaction from the user. The user will be able to view what is happening on the connected device, but make no interactions with it.
If selected, users will not be able to copy from the connection
If selected, users will not be able to paste values into the connection
The Terminal Behavior section contains options about the terminal for applicable connections.
Choose what action is sent when you click the backspace key. The options are:
Delete
Backspace
Choose the type of terminal to use. The options are:
ansi
linux
vt100
vt220
vterm
vterm-256color
Options for text recording. See the Session Recording section for more details about session recording.
Enter a file path location to save text session recordings to.
Enter a name for the text session recording file
Have Keeper Connection Manager automatically create the path location for the text session recording
Options for recording of the screen. See the Session Recording section for more information.
Enter the path to save the session recording. We recommend setting this to ${HISTORY_PATH}/${HISTORY_UUID}
Enter the name of the recording file
Choose to exclude graphics or streams from the recording
Choose to exclude the mouse from the screen recording
If selected, include key events that would not otherwise be visible in the recording
If selected, Keeper Connection Manager will automatically create a path for the recording file
Options to facilitate waking the connected device upon connection if supported.
Enable Wake-on-Lan and send a signal from Keeper Connection Manager
Identify the device to send the signal to by Mac Address
Where to send the WoL signal
How long to wait for the device to wake
Details to facilitate the new connection. Set network and authentication details.
The hostname and port of the Kubernetes connection
Choose to use SSL/TLS encryption
Choose to ignore the server certificate
Paste the Certificate Authority Certificate into this text box
Fill in the following information about the Kubernetes container:
Namespace
Pod Name
Container Name
The certificate to use if performing SSL/TLS client authentication to authenticate with the Kubernetes server, in PEM format. This parameter is optional. If omitted, SSL client authentication will not be performed.
The key to use if performing SSL/TLS client authentication to authenticate with the Kubernetes server, in PEM format. This parameter is optional. If omitted, SSL client authentication will not be performed.
Choose settings that affect how the new connection will look.
Select a color theme for the terminal.
There are built in themes, and a custom theme option.
Enter the name of a font for the terminal to use
Select the pixel size of the font
Select how far back a user can scroll through past commands. Leave blank for unlimited.
If checked, the connection will not allow for any interaction from the user. The user will be able to view what is happening on the connected device, but make no interactions with it.
The Terminal Behavior section contains options about the terminal for applicable connections.
Choose what action is sent when you click the backspace key. The options are:
Delete
Backspace
Options for text recording. See the Session Recording section for more details about session recording.
Enter a file path location to save text session recordings to. We recommend setting this to ${HISTORY_PATH}/${HISTORY_UUID}
Enter a name for the session recording file.
Choose to exclude graphics and streams that may appear on the terminal from the recording.
Choose to include keys that are clicked in the session recording. Events like ctrl+c
will be recorded.
Have Keeper Connection Manager automatically create the path location for the session recording
Details to facilitate the new MySQL connection. Set network and authentication details.
Enter the hostname and port for the MySQL connection
Unix Socket
Enter the socket name if a host is not present
The username and password for this MySQL connection. To prompt users for the password, leave this field empty.
Default Database
Specify the default database schema when establishing a connection.
Disable CSV Export
Disable the ability for users to export data through "select .. into local infile"
Disable CSV Import
Disable the ability for users to import data through "load data local infile..."
Choose settings that affect how the new connection will look.
Select a color theme for the terminal.
There are built in themes, and a custom theme option.
Enter the name of a font for the terminal to use.
Select the pixel size of the font.
Select how far back a user can scroll through past commands. Leave blank for unlimited.
If checked, the connection will not allow for any interaction from the user. The user will be able to view what is happening on the connected device, but make no interactions with it.
If selected, users will not be able to copy from the connection
If selected, users will not be able to paste values into the connection
Settings for basic environment setup
Set the language/local for the connection, this sets the $LANG environment variable
Set the time zone for the connection. This sets the $TZ environment variable
Set an interval for a keepalive signal
Options for recording of the screen. See the Session Recording section for more information.
Enter the path to save the session recording. We recommend setting this to ${HISTORY_PATH}/${HISTORY_UUID}
Enter the name of the recording file.
Choose to exclude graphics or streams from the recording.
Choose to exclude the mouse from the screen recording.
If selected, include key events that would not otherwise be visible in the recording.
If selected, Keeper Connection Manager will automatically create a path for the recording file.
Options for file transfers to the connection using SFTP. For more information see the File Transfer section.
Choose to enable SFTP file transfers.
The root directory of the SFTP server to display within this connection.
If SFTP is enabled, check this option to exclude users from downloading files from the server to this connection.
If SFTP is enabled, check this option to exclude users from uploading files to the server from this connection.
Options to facilitate waking the connected device upon connection if supported.
Enable Wake-on-Lan and send a signal from Keeper Connection Manager.
Identify the device to send the signal to by Mac Address.
Where to send the WoL signal.
How long to wait for the device to wake.
Terminal based protocols (Kubernetes, SSH, MySQL and Telnet) allow for custom color themes. To use a custom theme first select "custom" from the Theme dropdown, this will open the custom theme builder.
To use the custom theme builder, click each color to select a new color to use in its place. The foreground and background colors are labeled, other colors represent the standard terminal colors.
For example: to replace all red highlighted text in the terminal with orange text, click the red color and choose orange in the color picker.
If you are editing an existing connection, the usage history of the connection is shown in this section
The usage history table displays the username, date, duration of connection and remote IP address of users connecting to this connection.
If you would like to establish a connection to a target server with restricted Ingres connections, check out the documentation on Creating Connections via reverse SSH tunnel.
Transferring files between local and remote connection
Keeper Connection Manager support file transfers in both directions, with unique features available for the different connection types.
Files can be transferred between the local system and the remote connection through simple drag-and-drop.
Files can be transferred to the remote system through drag-and-drop. File transfer from remote system to local browser uses the guacctl
tool.
Files can be transferred via sftp to the remote system through drag-and-drop. The sftp endpoint is configured in the Connection Edit screen.
The new MySQL connection type supports transfer of CSV data into and out of the remote database through the browser interface using special "select" and "load" commands that have been built as extensions to the MySQL syntax.
The connection parameters used for File Transfer on Windows connections is displayed below. RDP connection types support two different methods of file transfer. The "Enable Drive" method uses the RDP protocol and maps file transfers to a mapped drive on the remote system.
Depending on the installation method, the "Drive Path" can be configured a few different ways.
On Docker Installation methods, there is a default volume mount to /var/lib/guacamole/
The Drive Path must include a base path of /var/lib/guacamole/drives
which has the necessary permissions to write files. If the same Drive Path is specified on multiple connections, the files will be shared among those connections. If the Drive Path contains a token after /drives/ such as ${GUAC_USERNAME}
, each user will see their own shared drive.
In this example, the following parameters are set:
Enable Drive: Check this to activate the file transfer capability
Drive Path: Set this path according to the environment. The folder must be writable by the guacd user.
Automatically Create Drive: If the permissions allow, the subfolders will be created on demand.
The mapped drive will show up on the remote system as seen below:
Windows connections can optionally use SFTP for file transfer. This can be activated in the SFTP section of the connection. This would require an SFTP client/server to be running on windows.
To transfer a file from the local system to the remote connection, simply drag-and-drop the file into the window. A progress indicator will show up on the lower right.
After the file transfer is complete, it will appear in the Drive folder.
To transfer a file from the remote system to the local computer, simply drag and drop a file on the remote system into the mapped Drive and then drag into the "Download" folder of the mapped drive. The file will instantly download to the local system.
SSH Connection types provide SFTP file transfer, which conveniently allows you to drag and drop a file into the SSH connection screen. Files are transferred to the designated folder as specified in the SSH connection settings.
Simply drag and drop a file into the SSH connection to transfer a file to the remote system. By default, the files will transfer to the home folder unless a different root directory path is specified.
To transfer files from the SSH remote connection to the local filesystem, you can download a tool called guacctl
into the remote system and use it for performing outbound transfers.
Download guacctl
and set as executable:
Initiate the file download:
Importing Data is accomplished through the web browser interface by using the standard "LOAD DATA LOCAL INFILE" SQL command. Keeper Connection Manager intercepts the response data and redirects it through the native file download facility of the web browser.
For example:
This SQL query will trigger a browser file upload and then import the provided data.
Details about the syntax can be found at the MySQL website.
Exporting CSV data from SQL query using a new SELECT... INTO LOCAL OUTFILE
command.
For example:
The file upload limit is controlled through the client_max_body_size
setting in the NGINX configuration file.
On Docker installations of Keeper Connection Manager, the default value of this setting is "0" which allows for an unlimited upload file size.
On Advanced Linux Installation method, the default file transfer limit might be set to 1MB and most likely, you will want to raise this limit. If you followed the typical installation instructions with NGINX, you should modify the configuration file, e.g. /etc/nginx/conf.d/guacamole.conf
Ensure the following parameter (client_max_body_size) is set with the preferred maximum file size limit. For example the below is set for 200MB size limit:
client_max_body_size 200m;
After updating this value, make sure to restart NGINX
systemctl restart nginx
If you have an environment where you would like the file location path associated with an existing network drive, follow the steps below:
Mount your network drive to the Keeper Connection Manager host filesystem
Volume mount the network drive path in the Docker Compose for the guacd container
Ensure that the guacd user can write the files in the docker container
The most important thing to keep in mind when doing this is that it's the "guacd" service that needs to be able to write files in the drive path. The guacd service operates as a reduced-privilege "guacd" user within the "guacd" container, and so you will need to set file permissions accordingly. This can be done either by modifying the files on the filesystem to have appropriate ownerships using the numerical UID/GID used by the container, or by using the GUACD_UID and GUACD_GID environment variables to configure the container to use the UID/GID already used by the files on the guacd container filesystem.
User Guide - Launching Connections
A connection can be launched by either clicking "Launch" or clicking on item from the list.
When you launch a connection, you will be instantly connected to the remote display from your web browser. You can interact with this display as if your mouse and keyboard are connected directly to the remote machine.
The remote display will take up the entire browser window, with no buttons or menus to disturb the view. With the intent of providing a seamless experience, options specific to remote desktop are hidden within the Keeper Connection Manager menu, which can be opened as needed.
The Keeper Connection Manager sidebar menu provides many features that you can use during your remote session.
To show or hide the menu, use the keystrokes below:
On Windows or Linux: Use Ctrl+Alt+Shift
On Mac: Use Ctrl+Option+Shift
If you are using a mobile or touchscreen device that lacks a keyboard, you can also show the menu by swiping right from the left edge of the screen.
The Keeper Connection Manager menu provides many features including:
Reading to and from the clipboard on the remote device
Switching between connections and joining multiple connections
Navigating back to the Home Screen
Disconnecting from the current connection
Sharing the current connection (if external sharing is configured)
Changing keyboard input method
Zooming in and out of the remote display
Selecting alternative mouse emulation methods
At the top of the Keeper Connection Manager menu is a text area labeled “Clipboard” along with some basic instructions:
Text copied/cut within Keeper Connection Manager will appear here. Changes to the text below will affect the remote clipboard.
The text area functions as an interface between the remote clipboard and the local clipboard. Text from the local clipboard can be pasted into the text area, causing that text to be sent to the clipboard of the remote desktop. Similarly, if you copy or cut text within the remote desktop, you will see that text within the text area, and can manually copy it into the local clipboard if desired.
If you have access to more than one connection, clicking the current connection name at the top of the Keeper Connection Manager menu will open a drop-down menu containing a list of your other available connections. Clicking on the name of another connection in this drop-down menu will immediately switch to that connection.
The previous connection will remain running as a thumbnail within a panel attached to the lower-right corner of the screen. This panel updates in real-time and remains visible as long as you have multiple active connections, even if you navigate away to another part of the Keeper Connection Manager application:
Clicking on any connection within the panel will navigate back to that connection, while clicking the “X” icon in the upper-right corner of the connection thumbnail will immediately close the connection.
Multiple connections may also be opened simultaneously within the same view by clicking the checkboxes next to the names of those connections in the connection menu. All connections opened in this way are automatically arranged in equally-sized tiles to fill the available area.
With multiple connections displayed as tiles, keyboard interaction and the Keeper Connection Manager menu will only affect the currently focused connection, as indicated by the blue title and border. Clicking or tapping within another connection will change the focus and allow keyboard interaction with that connection.
By holding down Ctrl (to select an individual connection) or Shift (to select a rectangle of connections), multiple connection may be focused at the same time. While multiple connections are focused, each key pressed will be broadcast across each focused connection:
This is particularly useful for running the same series of commands on multiple computers. Further, since Keeper Connection Manager automatically translates between the user’s local keyboard layout and the keyboard layout of the remote server, this will work as expected even if the keyboard layouts of focused connections do not match.
When you are done using the current connection, or you wish to navigate elsewhere temporarily, options to do so are within the user menu inside the Keeper Connection Manager menu:
The user menu within the Keeper Connection Manager menu provides an additional “Disconnect” option that allows you to explicitly close the current connection only. Clicking “Logout” will also implicitly disconnect all active connections, including the current connection.
Navigating back to the home screen or to the settings screen will not disconnect you: your connection will continue running in the background while you change settings or initiate another connection, and you can resume any active connection by clicking on it within the home screen.
You can transfer files back and forth between your local computer and the remote desktop if it is supported by the underlying protocol and enabled on the connection. Currently, Keeper Connection Manager supports file transfer for VNC, RDP, and SSH, using either the native file transfer support of the protocol or SFTP.
Files can be transferred to the remote computer by dragging and dropping the files into your browser window, or through using the file browser located in the Keeper Connection Manager menu.
While transferring files, a dialog on the lower right will display the status.
If file transfer is enabled on the connection, you will see one or more filesystem devices listed within the Keeper Connection Manager menu. Clicking on one of the filesystems opens a file browser which lists the files and directories within that filesystem.
Double-clicking on any directory will change the current location of the file browser to that directory, updating the list of files shown as well as the “breadcrumbs” at the top of the file browser. Clicking on any of the directory names listed in the breadcrumbs will bring you back to that directory, and clicking on the drive icon on the far left will bring you all the way back to the root level.
Downloads are initiated by double-clicking on any file shown, while uploads are initiated by clicking the “Upload Files” button. Clicking “Upload Files” will open a file browsing dialog where you can choose one or more files from your local computer, ultimately uploading the selected files to the directory currently displayed within the file browser.
The state of all file uploads can be observed within the notification dialog that appears once an upload begins, and can be cleared once completed by clicking the “Clear” button. Downloads are tracked through your browser’s own download notification system.
When you are done browsing the filesystem and transferring files, click “Back” to return to the Keeper Connection Manager menu.
RDP provides its own native support for file transfer called “drive redirection” or “RDPDR”. Keeper Connection Manager provides support for this mechanism by emulating a virtual drive. Typically, this virtual drive will appear as a network drive within the RDP session. Files uploaded and downloaded will be preserved within this drive, even after disconnecting.
Files can be downloaded from this drive using the file browser in the Keeper Connection Manager menu or using the special “Download” folder within the virtual drive. All files dropped into this folder will automatically begin uploading to the client, and thus downloading through the browser.
In addition to using the traditional drag-and-drop and the file browser, Keeper Connection Manager SSH support can be used with the guacctl utility. The guacctl utility is a simple shell script included with Guacamole (and supported by Keeper Connection Manager) which allows you to use and configure file transfer directly from the command line within the SSH session:
For convenience, you may also create a symbolic link or alias to guacctl called guacget. When run as guacget, the utility behaves as if the --download
option were supplied and initiates a download for each file specified on the command line.
Certain key combinations are impossible to press within a web application like Keeper Connection Manager because they are reserved by the operating system (Ctrl+Alt+Del or Alt+Tab, for example) or by the web browser. If you press one of these reserved combinations, the effect will be observed locally, not remotely, and the remote desktop will receive only some of the keys.
Keeper Connection Manager provides its own, built-in on-screen keyboard which allows keys to be sent to the remote desktop without affecting the local system. If the device you’re using does not have certain keys which the remote desktop depends on, such as the arrow keys or Ctrl, you can use the on-screen keyboard for this, too. You can show the on-screen keyboard by selecting the “On-screen keyboard” option from the menu.
Clicking (or tapping) the buttons of the on-screen keyboard has the same effect as pressing the same buttons on a real keyboard, except that the operating system and browser will not intercept these keypresses; they will only be sent to the remote desktop.
Keeper Connection Manager will default to shrinking or expanding the remote display to fit the browser window exactly, but this is not necessarily ideal. If the remote display is much larger than your local display, the screen may be impossible to see or interact with. This is especially true for mobile phones, whose screens need to be small enough to fit in the average hand.
You can scale the display on touch devices by using the familiar pinch gesture. Place two fingers on the screen and bring them closer together to zoom out or further apart to zoom in.
If your device lacks a touch screen, you can also control the zoom level through the menu. The controls for zooming in and out are located at the bottom of the menu. The current zoom level is displayed between two “-” and “+” buttons which control the zoom level in 10% increments.
Keeper Connection Manager is designed to work equally well across all HTML5 browsers, including those of mobile devices. It will automatically handle input from a touch screen or a traditional mouse (or both, if you happen to have such a gifted computer), and provides alternative input methods for devices which lack a physical keyboard.
In the case that your device has a touchscreen and lacks a mouse, Keeper Connection Manager will emulate a mouse for the sake of interacting with remote desktops that expect mouse input. By default, Keeper Connection Manager uses “absolute” mouse emulation. This means that the mouse pointer is positioned at the location of each tap on the screen.
In both absolute and relative modes, you can click-and-drag by tapping the screen and then quickly placing your finger back down. This gesture only causes the mouse button to press down, but does not release it again until you lift your finger back up.
Absolute mode (touchscreen)
Absolute mouse emulation is the default as it tends to be what people expect when using a touch device to interact with applications designed for mouse input.
Each tap on the screen is translated into a left-click at that position. Right-clicking is accomplished through pressing and holding your finger on the screen. If parts of the remote display are off-screen, you can drag your finger around the screen to pan the off-screen parts back into view.
Although absolute mouse emulation works generally well, a finger makes for a very inaccurate pointing device. To address this, Keeper Connection Manager also provides “relative” mouse emulation. Relative mouse emulation provides a way to deal with the need for accurate pointer control, when a true pointer device is not present.
Relative mode (touchpad)
Keeper Connection Manager's relative mouse emulation behaves similarly to the touchpad present on most modern laptops. You drag your finger across the display to move the mouse pointer, and tap the display to left-click. The pointer moves relative to the motion of your finger. Right-clicking is accomplished with a two-finger tap, and middle-clicking with a three-finger tap. The mouse scroll wheel can be operated by dragging two fingers up or down.
Because the relative mouse emulation reserves so many gestures for the different mouse buttons and actions, common touch gestures like panning and pinch-to-zoom will not work while relative mouse emulation is enabled. Instead, the screen will automatically pan to keep the mouse pointer in view, and you can zoom through the buttons in the menu.
Many mobile devices lack a physical keyboard entirely, and instead provide their own on-screen keyboards. As these are not true keyboards per se and do not produce key presses, Keeper Connection Manager's text input mode is required for typing on these platforms.
“Text input” allows input of keystrokes based on the input of text. Choosing “Text input” tells Keeper Connection Manager to infer keystrokes by tracking text entered, rather than relying on actual key presses. Keeper Connection Manager will instead determine the combination of keypresses necessary to produce the same pattern of input, including deletions.
If you wish to type via an IME (input method editor), such as those required for Chinese, Japanese, or Korean, text input mode is required for this as well. Such IMEs function through the explicit insertion of text and do not send traditional key presses. Using text input mode within Keeper Connection Manager thus allows you to use a locally-installed IME, without requiring the IME to be installed on the remote desktop.
User preferences can be changed within the settings screen under the "Preferences" tab. These preferences are stored locally within the browser, so if you use multiple computers to access Keeper Connection Manager, you can have different settings for each location. The settings screen allows users to change the language of the Keeper Connection Manager interface, to change the default input method used by Keeper Connection Manager connections, and to change the default mouse emulation mode for if a touch device is used. If you have sufficient permissions, you may also change your password, or administer the system.
The Keeper Connection Manager interface is currently available in English, Dutch, French, German, Italian, and Russian. By default, Keeper Connection Manager will attempt to determine the appropriate display language by checking the language preferences of the browser in use. If this fails, or the browser is using a language not yet available within Keeper Connection Manager, English will be used as a fallback.
If you wish to override the current display language, you can do so by selecting a different language within the “Display language” field. The change will take effect immediately.
System administrators can restrict the ability of individual users to change their own passwords, so this section may not always be available. If your account does have permission, the preferences screen will contain a “Change Password” section.
To change your password, you must provide your current password, enter the desired new password, and click “Update Password”. You will remain logged in, and the change will affect any future login attempt.
Keeper Connection Manager provides multiple keyboard input methods and multiple mouse emulation modes. Many of these settings are specifically useful for touch devices, while others are aimed mainly at traditional desktop use. By default, Keeper Connection Manager will use the keyboard and mouse modes most commonly preferred by users, but you can change these defaults if they do not fit your tastes or your current device.
The choices available mirror those within the Keeper Connection Manager menu discussed earlier in this chapter, and changing these settings will affect the default values selected within the Keeper Connection Manager menu of future connections.
In order for a connection to be shared, an admin must first create a sharing profile. See the admin documentation for more details.
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 connects 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.
Create multiple connections via API or by uploading a CSV, JSON, or YAML file
Keeper Connection Manager enables administrators to create connections and assign permissions to those connections by uploading a CSV, JSON, or YAML file.
Administrators can also update existing connections by checking the "Replace/Update existing connections" checkbox within the import UI:
Existing connections are identified by their name and parent connection group.
Additionally, Keeper Connection Manager enables administrators to also create connections and assign permissions to those connections via API.
The following file types are supported for connection import: CSV, JSON, and YAML.
In each of the file types, a connection is defined with the following data:
Connection Name
Connection Protocol
For a list of supported connection protocols visit this page
Connection Parameters (optional)
Connection Group Location (optional)
List of Users to grant access (optional)
List of User Groups to grant access (optional)
Connection Attributes (optional)
The connection import CSV file has one connection record per row where each column will specify a connection field.
The following sections will cover all the valid connection fields (columns) that are supported in the connection import CSV file:
At minimum, the connection name and protocol must be specified.
KCM supports the following connections protocols, and the corresponding "Internal name" must be used:
The connection's parameters are dependent on your connection's protocol.
For more information on the available parameters for your connection protocol, refer to the table above and navigate to your protocol or visit this page
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".
If a user or group identifier within the semicolon-separated list of users/groups needs to contain a semicolon, the semicolon can be escaped with a backslash. For example: "first\;last"
Lists of user or user group identifiers must be semicolon-separated and defined in the users and groups connection fields
Additional connection characteristics for your connection
Note: The first row in the above example specified the header
In most cases, there should be no conflict between fields, but if needed, an " (attribute)" or " (parameter)" suffix may be added to disambiguate.
The connection import JSON file has a list of connection objects. Each connection object supports the following keys:
At minimum the connection name and protocol must be specified in each connection object.
A connection import YAML file is a list of connection objects with exactly the same structure as the JSON format.
Keeper Connection Manager also enables administrators to batch import connections directly through the API by using the same endpoints that the Batch Import UI uses from the user interface.
To create or replace multiple connections, the HTTP PATCH method should be used on the connection directory resource, located at /api/session/data/{DATA_SOURCE}/connections
. The data source specifies where the connections should be created, and will generally be the name of the database that was selected at install time i.e. mysql
, postgres
, or sqlserver
. In the examples provided below, the mysql
data source will be used.
See the KCM protocol documentation for more information on the possible parameters for any given connection protocol type.
Note that directory PATCH methods guarantee atomicity - the entire request must succeed; if any included patch fails, all changes in the batch will be rolled back.
Before using any other API endpoints, you'll need an auth token (HEX value). This can be extracted by examining the requests of a logged in user on the web app, or by directly making a request to the tokens endpoint. For example:
The response will include the auth token, as well as the data source that authorized the login:
You can use your favorite API tool. If using Postman, when sending a GET or PATCH, set your authorization to "Inherit auth from parent", and set a header with the key Guacamole-Token with the value set to your token. Keep in mind the default expiration of tokens is 60 minutes.
Each connection to be created must be represented by a separate PATCH in the request body, using the "add" operation. For example, to create a couple of new connections:
Users, user groups, connection groups, and sharing profiles can also be modified using the same PATCH semantics as connections. The API endpoints for each of these, respectively, are:
/api/session/data/{DATA_SOURCE}/users
/api/session/data/{DATA_SOURCE}/userGroups
/api/session/data/{DATA_SOURCE}/connectionGroups
/api/session/data/{DATA_SOURCE}/sharingProfiles
For a list of supported key-value pairs, visit this section of this document
The response will include the operation and ID for every connection, in the same order the patches were submitted:
To replace an existing connection, the "replace" operation can be used. Note that the "replace" operation will completely replace any connection fields, but any existing user or user group permissions will be retained. For example, to replace the connections created above, submit a "replace" patch for each:
To fully replace an existing connection, resetting all permissions granted for that connection, the connection should be deleted and recreated. This can be done using a pair of patches with the "remove" and "add" operations. For example, to fully replace the connections created earlier, submit a pair of patches for each:
To grant access to connections for a user or user group, submit a patch to grant access for each connection, by connection ID. For example, to grant access to the user "KCM_User_1", submit the following patches:
To grant permissions to a user group, use: /api/session/data/{DATA_SOURCE}/userGroups/{GROUP_ID}/permissions
e.g.:
/api/session/data/mysql/userGroups/KCM%20Administrators/permissions
Once you're done using the API, the auth token should be explicitly disabled:
If an error is encountered while submitting a list of patches, an overall error will be returned, including any patch-specific errors. For example, when attempting to create connections that already exist with the same name at the same connection group:
Created shared remote connections in Keeper Connection Manager
Keeper Connection Manager allows users to share access to their connection session with a URL. This allows for easy sharing of a connection session among teams, or sharing of connections to people without Keeper Connection Manager accounts.
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.
When editing an existing profile, you also have the options to delete or clone the profile.
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.
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”:
Configure and view connection session recordings
Keeper Connection Manager supports automatic screen recording of each connection session. Recordings can be graphical video recordings of the connection, or (for certain connection protocols) typescript recordings which record only the text sent to the the client machine.
Read below about how to setup, configure, and view each session recording type.
Sessions of all supported protocols can be recorded graphically. These recordings take the form of Guacamole protocol dumps and are recorded automatically to a specified directory.
The simplest way to record user connection sessions and view them in the browser.
To configure connections for in-browser recording playback, enter the following special values in the "Screen Recording" section of the connection settings.
You can leave the Recording Name / Typescript Name fields blank. They will be automatically generated based on the date and time of recording.
Recording Path / Typescript Path
These values tell the system to store recordings in a location and format that the in-browser viewer can play back.
If desired, graphical session recordings can be named with custom values, or saved to any desired location. This will require recording playback using the Glyptodon Session Recording Player.
The directory in which screen recording files should be created.
This parameter is required for graphical session recording to function.
The filename to use for any created recordings. This parameter is optional. If omitted, the value “recording” will be used instead.
This parameter only has an effect if graphical recording is enabled. If the "Recording Path" is not specified, graphical session recording will be disabled, and this parameter will be ignored.
For example:
RDP Recording ${GUAC_USERNAME} - ${GUAC_DATE} : ${GUAC_TIME}
Will create recording files with the user's username, the session date and time in the name.
Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like “.1”, “.2”, “.3”, etc. will be appended to to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will simply not be recorded.
Keeper Connection Manager session recordings can be viewed from within the user interface in the History tab of the settings screen. To view a recording, click the play icon on the far right. Any session of a connection that was setup with the settings above will have the icon. When the icon is clicked, the recorded session will load in the browser, and you can start playback by clicking anywhere on the screen.
If a session recording contains key events, those events can now be viewed within KCM’s session recording player. Administrators can view an approximation of what would have been typed based on those events and perform a text-based search to find particularly interesting parts of a recording.
By Default, recordings do not contain key events. This must be enabled by an administrator when configuring the connection.
KCM session recordings display a histogram that shows the relative levels of activity within different parts of the recordings. The histogram shows the following levels of activities:
Visible events such as when the screen changes
keyboard events - user interactions with the keyboard
If checked, graphical output and other data normally streamed from server to client will be excluded from the recording, producing a recording which contains only user input events.
This parameter is optional. If omitted, graphical output will be included in the recording.
If checked, user mouse events will be excluded from the recording, producing a recording which lacks a visible mouse cursor.
This parameter is optional. If omitted, mouse events will be included in the recording.
If checked, user key events will be included in the recording.
This parameter is optional. If omitted, key events will be not included in the recording.
If checked the directory specified by "Recording Path" will automatically be created if it does not yet exist. Only the final directory in the path will be created - if other directories earlier in the path do not exist, automatic creation will fail, and an error will be logged.
This parameter is optional. By default, the directory specified by the recording path parameter will not automatically be created, and attempts to create recordings within a non-existent directory will be logged as errors.
To view session recordings, click "Browse..." and select the recording in your file system. The recording will play in the browser.
The Keeper Connection Manager graphical session recording player does not send recordings over the internet. Recording files are translated to video locally on the browser.
The full, raw text content of terminal sessions, including timing information, can be recorded automatically to a specified directory. This recording, also known as a “typescript”, will be written to two files within the directory specified by the entered Typescript Path: NAME
, which contains the raw text data, and NAME
.timing
, which contains timing information, where NAME
is the value provided for Typescript Name.
This format is compatible with the format used by the standard UNIX script command, and can be replayed using compatible tools.
The directory in which typescript files should be created.
This parameter is required. Specifying this parameter enables typescript recording. If this parameter is omitted, no typescript will be recorded.
The base filename to use when determining the names for the data and timing files of the typescript.
This parameter is optional. If omitted, the value “typescript” will be used instead.
Each typescript consists of two files which are created within the directory specified by the Typescript Name: NAME
, which contains the raw text data, and NAME
.timing
, which contains timing information, where NAME
is the value provided for the Typescript Name parameter.
For example:
SSH Typescript ${GUAC_USERNAME} - ${GUAC_DATE} : ${GUAC_TIME}
Will create recording files with the user's username, the session date and time in the name.
Guacamole will never overwrite an existing recording. If necessary, a numeric suffix like “.1”, “.2”, “.3”, etc. will be appended to NAME
to avoid overwriting an existing recording. If even appending a numeric suffix does not help, the session will simply not be recorded.
If checked, the directory specified by "Typescript Path" will automatically be created if it does not yet exist. Only the final directory in the path will be created - if other directories earlier in the path do not exist, automatic creation will fail, and an error will be logged.
This parameter is optional. By default, the directory specified by "Typescript Path" will not automatically be created, and attempts to record typescripts in a non-existent directory will be logged as errors.
Recordings can be replayed using script. For example, to replay a typescript called “NAME
”, you would run:
Recordings can be replayed using scriptreplay. For example, to replay a typescript called “NAME
”, you would run:
Docker Compose Property | Environment Variable | Type | Descriptions |
---|---|---|---|
Protocol | Internal name |
---|---|
Key | Description |
---|---|
It is recommended to utilize to add the date, time, and other unique information to the recording name.
Keeper Connection Manager graphical session recordings that were saved to a custom location can be viewed using the Keeper Connection Manager Session Recording Player at
Typescript session recording can be configured for each connection in the
It is recommended to utilize to add the date, time, and other unique information to the recording name.
ban-max-invalid-attempts
BAN_MAX_INVALID_ATTEMPTS
number
The number of invalid attempts before a user is locked out
ban-address-duration
BAN_ADDRESS_DURATION
number
The amount of time in seconds a user is locked out for after hitting the invalid attempts limit
ban-max-addresses
BAN_MAX_ADDRESSES
number
The number of addresses that KCM will track to check for invalid attempts. Defaults to 10485760
vnc
rdp
ssh
telnet
kubernetes
mysql
postgresql
sql-server
name
Name of the connection
protocol
Connection's protocol. For a list of supported connection protocols visit this page
parameters
Connection's parameters to establish protocol connection. For required parameters visit this page. (Optional)
parentIdentifier or group
The connection group ID that the connection should be imported into may be directly specified with a parentIdentifier
key, or the path to the parent group may be specified using a group
key (Optional)
users
An array of user(s) to grant access to (Optional)
groups
An array of user group(s) to grant access to (Optional)
attributes
Connection's attributes
Integrate Keeper Connection Manager with external data sources using Encrypted JSON Authentication
Keeper Connection Manager can be configured to integrate with any custom software or 3rd party application using encrypted JSON files that simultaneously authenticate a user and grant them access to remote connections.
The Dynamic Connections feature requires installation of the Encrypted JSON Authentication module for Keeper Connection Manager. To activate this feature, update the JSON_*
parameters in the Docker Compose file in the keeper/guacamole image.
JSON_SECRET_KEY
JSON_TRUSTED_NETWORKS
Activating these parameters loads an authentication extension for Keeper Connection Manager which authenticates users using JSON that have been signed using HMAC/SHA-256 and encrypted with AES-128 CBC. As this JSON contains all information describing the user being authenticated (including any connections they have access to), this extension can provide a simple means of integrating Keeper Connection Manager with external applications.
The JSON_SECRET_KEY must be 128 bits, specified as a 32-digit hexadecimal value, such as:
4c0b569e4c96df157eee1b65dd0e4d41
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:
If encrypted JSON will only ever be received from a known set of machines or private subnets, you may wish to further restrict acceptance of received JSON to only those trusted machines using the JSON_TRUSTED_NETWORKS
property. This field is a comma-separated list of trusted IP addresses and/or CIDR subnets. For example:
The general format of the JSON (prior to being encrypted, signed, and sent to Keeper Connection Manager), is as follows:
...where TIMESTAMP
is a standard UNIX epoch timestamp with millisecond resolution (the number of milliseconds since midnight of January 1, 1970 UTC) and PROTOCOL
is the internal name of any of Guacamole's supported protocols, such as vnc
, rdp
, or ssh
.
The JSON will cease to be accepted as valid after the server time passes the timestamp. If no timestamp is specified, the data will not expire. This can be desirable, but should only be done after careful consideration. In most cases, it is critical that a timestamp is specified, limiting the use of the encrypted JSON to some reasonable time interval and preventing replay attacks.
The top-level JSON object which must be submitted to Keeper Connection Manager has the following properties:
Each connection defined within each submitted JSON object has the following properties:
To authenticate a user with the above JSON format, the JSON must be both signed and encrypted using the same 128-bit secret key specified with the JSON_SECRET_KEY
value in the Docker compose file.
Generate JSON in the format described above
Sign the JSON using the secret key (the same 128-bit key stored with the JSON_SECRET_KEY
property) with HMAC/SHA-256. Prepend the binary result of the signing process to the plaintext JSON that was signed.
Encrypt the result of (2) above using AES in CBC mode, with the initial vector (IV) set to all zero bytes.
Encode the encrypted result using base64.
POST the encrypted result to the /api/tokens
REST endpoint as the value of an HTTP parameter named data
(or include it in the URL of any Keeper Connection Manager page as a query parameter named data
).
For example, if Keeper is running on kcm.example.com and BASE64_RESULT
is the result of the above process, the equivalent run of the "curl" utility would be:
Be sure to URL-encode the base64-encoded result prior to POSTing it to /api/tokens
or including it in the URL. Base64 can contain both "+" and "=" characters, which have special meaning within URLs.
If the data is invalid in any way, if the signature does not match, if decryption or signature verification fails, or if the submitted data has expired, the REST service will return an invalid credentials error and fail without user-visible explanation. Details describing the error that occurred will be in the KCM logs.
Dynamic pass-through tokens
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 passing through the credentials provided during login. This is typically useful when both Keeper Connection Manager and the remote desktops authenticate against the same, central authority, such as Active Directory or LDAP.
Providing remote desktops with the user's IP address or hostname, as may be required for licensing, auditing, or logging.
Automatically organizing session recordings using the current date and time.
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}
".
These tokens are replaced dynamically each time a connection is used. If two different users access the same connection at the same time, both users will be connected independently of each other using different sets of connection parameters.
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.
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.
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
".
Discover and connect to EC2 instances
Keeper Connection Manager integrates with Amazon AWS to perform automatic discovery and connection to EC2 instances. This makes it fast and easy to connect to any EC2 instance in your cloud environment without having to manually configure anything. Like other connections, the EC2 instance connections are privileged, which means that the end-user does not have access to the underlying credentials.
Once activated, the EC2 instances will appear on the home screen of Keeper Connection Manager as seen below.
Instant discovery of EC2 instances in your AWS environment
Restrict permissions to a defined User Group
PEM files can be managed either on the filesystem or Keeper Vault
In order to integrate Keeper Connection Manager with Amazon AWS, you'll need to create a user and assign a role policy that has permission to read instance information. A sample policy with minimal permissions is below:
Assign the permission to a user and then create access keys.
Before configuring the environment, ensure that you have a Group called "AWS EC2 Administrators" that are assigned to the users who will have access to discovered instances. The group name can also be customized through the AWS_DISCOVERY_ADMIN_GROUP environmental variable.
To update your Keeper Connection Manager environment to support this feature, you'll need to edit the Docker Compose file located at /etc/kcm-setup/docker-compose.yml
Before making changes on the local instance, it is a good idea to stop the containers.
Now, edit the docker compose file /etc/kcm-setup/docker-compose.yml
and add the necessary required environmental variables and volume property. For example, see below.
If you are using the Secrets Manager Vault connection with KCM, pem files or private keys can be pulled in dynamically from the Keeper Vault. If using this method, a volume mount for pem files does not need to be created. See the EC2 Cloud Connector documentation for more details.
Environmental Variables
AWS_DISCOVERY_ACCESS_KEY_ID
The access key ID for the AWS account that should be used to authenticate with AWS (Required).
AWS_DISCOVERY_SECRET_KEY
The secret key associated with the access key (Required).
AWS_DISCOVERY_REGIONS
Comma-separated list of regions to query for EC2 instances, such as us-west-1,us-east-1
(Required).
AWS_DISCOVERY_INSTANCE_BASE_PATH
The name of the organizational connection group that should be used to house the EC2 instances for convenience. By default, this will be “Amazon EC2“ (Optional).
AWS_DISCOVERY_ADMIN_GROUP
The name of the User Group in Keeper Connection Manager to require for any user to see the discovered EC2 instances. By default, this will be a group called “AWS EC2 Administrators". This can also be assigned to a Group that has been provisioned from Azure AD or other directory integrations.
AWS_DISCOVERY_RECORD_CONNECTIONS_BY_DEFAULT
If set to "true", screen recording will be enabled by default on all connections. Connection session recording can also be set at an individual machine level using the "kcm:record
" EC2 instance tag, which can be set to "true" or "false" to explicitly enable or disable connection recording.
AWS_DISCOVERY_KSM_CONFIG
This Keeper Secrets Manager configuration provides integration with the Keeper vault to store PEM files. See the EC2 Cloud Connector documentation for more details.
In the Docker Compose example, you can see a volume mapping in the local file location /var/lib/guac_keys/
. This is the folder in the KCM host where you must place all of the SSH key files required to establish a connection to the target instances. Windows instances must also copy the .pem file which is used to decrypt the Administrator password. KCM will select the proper file for establishing a connection based on the EC2 instance metadata.
See the Key File Permissions section below to review the file permissions and ensure that the key files are readable by the container.
If you are using the Secrets Manager Vault connection with KCM, pem files or private keys can be pulled in dynamically from the Keeper Vault. See the EC2 Cloud Connector documentation for more details.
To update all of the underlying software when using the Docker Automated Install method, run the below command:
This should automatically start the containers after the update.
To update your Keeper Connection Manager environment to support this feature, you'll need to edit the "guacamole" section of your custom Docker Compose file.
(1) Stop the Containers
Before making changes on the local instance, it is a good idea to stop the containers, as you normally would do with docker-compose.
Now, edit your docker compose file and add the necessary required environmental variables and volume property to the guacamole
section. For example, see below.
Environmental Variables
AWS_DISCOVERY_ACCESS_KEY_ID
The access key ID for the AWS account that should be used to authenticate with AWS (Required).
AWS_DISCOVERY_SECRET_KEY
The secret key associated with the access key (Required).
AWS_DISCOVERY_REGIONS
Comma-separated list of regions to query for EC2 instances, such as us-west-1,us-east-1
(Required).
AWS_DISCOVERY_INSTANCE_BASE_PATH
The name of the organizational connection group that should be used to house the EC2 instances for convenience. By default, this will be “Amazon EC2“ (Optional).
AWS_DISCOVERY_ADMIN_GROUP
The name of the User Group in Keeper Connection Manager to require for any user to see the discovered EC2 instances. By default, this will be a group called “AWS EC2 Administrators". This can also be assigned to a Group that has been provisioned from Azure AD or other directory integrations.
AWS_DISCOVERY_RECORD_CONNECTIONS_BY_DEFAULT
If set to "true", screen recording will be enabled by default on all connections. Connection session recording can also be set at an individual machine level using the "kcm:record
" EC2 instance tag, which can be set to "true" or "false" to explicitly enable or disable connection recording.
In the Docker Compose example, you can see a volume mapping in the local file location /var/lib/guac_keys/
. This is the folder in the KCM host where you must place all of the SSH key files required to establish a connection to the target instances. Windows instances must also copy the .pem file which is used to decrypt the Administrator password. KCM will select the proper file for establishing a connection based on the EC2 instance metadata.
See the Key File Permissions section below to review the file permissions and ensure that the key files are readable by the container.
To update all of the underlying software when using the Custom Docker Install method, upgrade your containers (assuming docker-compose.yml is in the current directory):
This should automatically start the containers after the update.
If you have installed Keeper Connection Manager using the Advanced Linux Install method, follow the steps below to activate the AWS EC2 discovery feature.
(1) Install the KCM Cloud Connector package
If you are using the Advanced Linux Install method, you can use yum install to install the KCM Cloud Connector package:
(2) Edit the Guacamole Properties File
Edit /etc/guacamole/guacamole.properties
to include the mandatory and optional properties for the AWS Cloud Connector feature.
Available Properties
aws-discovery-access-key-id
The access key ID for the AWS account that should be used to authenticate with AWS (Required).
aws-discovery-secret-key
The secret key associated with the access key (Required).
aws-discovery-regions
Comma-separated list of regions to query for EC2 instances, such as us-west-1,us-east-1
(Required).
aws-discovery-instance-base-path
The name of the organizational connection group that should be used to house the EC2 instances for convenience. By default, this will be “Amazon EC2“ (Optional).
aws-discovery-admin-group
The name of the User Group in Keeper Connection Manager to require for any user to see the discovered EC2 instances. By default, this will be a group called “AWS EC2 Administrators". This can also be assigned to a Group that has been provisioned from Azure AD or other directory integrations (Optional).
aws-discovery-record-connections-by-default
If this property is set to "true", screen recording will be enabled by default on all connections (Optional).
Connection session recording can also be set at an individual machine level using the "kcm:record
" EC2 instance tag, which can be set to "true" or "false" to explicitly enable or disable connection recording.
Add any required PEM files for private keys used to access Linux instances or decrypt Windows passwords to /etc/guacamole/cloud-connector-secrets/aws/
(4) Restart the Guacamole service
The new package will not take effect until the web application is restarted.
Connections can be configured using AWS EC2 tags assigned to each instance, in order to override and customize defaults and metadata.
kcm:username
The username that should be used when connecting to that instance.
This tag defines the login username for the instance, such as "centos" or "ec2-user". KCM attempts to select the correct username based on the AMI of the instance, but this can be used to correct a wrong assumption.
kcm:organize
The full path of the connection groups that should be used to organize the instance among other connections.
This tag Allows EC2 instances to be further organized beyond the connection group containing all instances. By default, all discovered instances will be placed within one top-level group of connections called "Amazon EC2", but will not be further organized. For example, if you set kcm:organize
to something like "Databases", that instance will be located within a "Databases" connection group beneath "Amazon EC2". If you set kcm:organize
to "Databases/MySQL", that instance will be within a "MySQL" connection group beneath "Databases", which itself would be beneath the main "Amazon EC2" group.
These connection groups do not need to already exist, and they actually exist only in memory (dynamically maintained by the EC2 support).
kcm:record
Flag to indicate if the instance connection sessions should be recorded.
This tag will override the default screen recording configuration of the KCM environment property aws-discovery-record-connections-by-default
. If this tag exists with the value "true", the connection will be recorded, if "false", the connection will not be recorded. If the tag does not exist, or is set to any other value, the configured default recording behavior will be used.
The key files must be named exactly as referenced in the EC2 console, e.g. MyServer
The key files must be named with a .pem file extension, for example MyServer.pem
The service in the "guacamole" docker container is run by the "guacamole" user. File permissions must be configured properly in the volume mount to ensure that the "guacamole" user has read access to the shared key files.
Example: On the host under /var/lib/guac_keys/
the files may be owned by ec2-user or whatever you have set up.
In the container the files may show owned by "1000" or some other user ID.
There are two ways of solving the file permissions between the host and the guacamole container.
(1) You may use the environmental variables GUACAMOLE_UID and GUACAMOLE_GID in the guacamole docker definition to map the permission.
This change has the following result:
Updates the ownerships of existing files from the old UID of the guacamole
user to the specified value.
Updates the UID of the guacamole
user in the container to match that value.
(2) You can set wider group or world read permissions on the files from the host, but this is a decision based on your environment and security settings.
Ensure that you upgrade the containers for the change to take effect.
(kcm-setup.run upgrade
or docker-compose up -d
)
If the .pem key is encrypted with a passphrase, you will be prompted for this when establishing the connection to the target.
Easily add your logo to your KCM instance
Download the zip file above and extract everything to a folder.
Replace /resources/images/logo.png
with your logo.png
file.
Open /translations/en.json
and replace "Custom Title" with your text for the title of the webpage.
(Optional) Replace the favicon icons in /resources/images/
, bothsmall.png
and large.png
with yours. (you can use the same one for both if needed)
From inside the folder, select all of the files and folders and create a new zip file.
Make sure that you are viewing file extensions, and change your zip file name and extension to kcm-branding.jar
Transfer the kcm-branding.jar
file to your KCM server into/etc/kcm-setup/
In your docker-compose.yml
guacamole section, within environment, add USE_DEFAULT_BRANDING: "N"
and in volumes add the following line:
Run these commands:
Complete! Now you will see your logo on your Keeper Connections Manager.
To refresh the favicons press Ctrl/Cmd + F5 for a hard reload.
Customization of the Keeper Connection Manager user interface
Keeper Connection Manager supports customization of the front-end user interface CSS and injection of custom Javascript. In this guide, we will demonstrate how to modify the web application to display customized branding and execute custom Javascript code.
Keeper Connection Manager provides the ability to develop "Extensions" which can add custom enhancements to the overall platform. This page covers a basic example which can be easily modified for branding and UI changes.
Extensions to Keeper Connection Manager can:
Provide alternative authentication methods and sources of connection/user data.
Provide event listeners that will be notified as Guacamole performs tasks such as authentication and tunnel connection.
Theme or brand the user interface through additional CSS files and static resources.
Extend KCM's JavaScript code by providing JavaScript that will be loaded automatically.
Add additional display languages, or alter the translation strings of existing languages.
KCM extensions are standard Java .jar
files (this is essentially a .zip
file) which contain all classes and resources required by the extension, as well as the KCM extension manifest. There is no set structure to an extension except that the manifest must be in the root of the archive. Java classes and packages, if any, will be read from the .jar
relative to the root, as well.
Modifying your existing KCM installation with custom branding is easy, please follow the below steps as an example.
(2) Zip up the contents of the branding folder into a file called kcm-branding.jar
. The name of the file is arbitrary, as long as it is a unique name. KCM will load any extension that is placed into the target folder.
(3) Copy the file into the /etc/kcm-setup folder or any path on the server.
(4) In your docker-compose.yml
file (e.g. /etc/kcm-setup/docker-compose.yml
) there are 2 changes needed:
In the "guacamole" section add a reference to the Jar file which volume mounts the file directly from the host into the guacamole instance. The name of the file does not matter, as KCM will pull all jar files and process them.
Add the environment variable USE_DEFAULT_BRANDING with a value of "N".
Here's an example section:
(5) Restart the container
That's it. After the service starts up, the branding on your KCM page will be all new, and there will be a popup alert when you load the page.
For iterating on more changes, simply edit the resources, zip up the file, copy the zip file to the target folder and restart your KCM container.
The CSS files referenced in guac-manifest.json are appended to the application CSS when loaded, therefore they will override the CSS properties.
The Javascript files referenced in guac-manifest.json are appended to the application Javascript when loaded.
The existing HTML structure of KCM's interface can be modified through special "patch" HTML files declared by the html property in guac-manifest.json
. These files are HTML fragments and are identical to any other HTML file except that they contain KCM-specific meta tags that instruct KCM to modify its own HTML in a particular way. Each meta tag takes the following form:
where SELECTOR
is a CSS selector that matches the elements within the KCM interface that serve as a basis for the modification, and NAME
is any one of the following defined modifications:
before
Inserts the specified HTML immediately before any element matching the CSS selector.
after
Inserts the specified HTML immediately after any element matching the CSS selector.
replace
Replaces any element matching the CSS selector with the specified HTML.
before-children
Inserts the specified HTML immediately before the first child (if any) of any element matching the CSS selector. If a matching element has no children, the HTML simply becomes the entire contents of the matching element.
after-children
Inserts the specified HTML immediately after the last child (if any) of any element matching the CSS selector. If a matching element has no children, the HTML simply becomes the entire contents of the matching element.
replace-children
Replaces the entire contents of any element matching the CSS selector with the specified HTML.
For example, to add a welcome message and link to some corporate privacy policy (a fairly common need), you would add an HTML file like the following:
After the extension is installed and KCM is restarted, the "welcome" div and its contents will automatically be inserted directly below the login dialog (the only element that would match .login-ui .login-dialog
) as if they were part of KCM's HTML in the first place.
If the page loads blank after applying the extension, check the logs. For example:
If you see a null pointer exception, it's probably because one of the resources referenced in guac-manifest.json
cannot be found in the .jar
archive. Ensure that all files and folders are zipped up properly.
Integrate Keeper Connection Manager with the Keeper Vault for protecting and retrieving session credentials
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.
This documentation assumes that you already have a Keeper Enterprise subscription with Keeper Secrets Manager activated.
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
Property name | Type | Description |
---|---|---|
Property name | Type | Description |
---|---|---|
Parameter token | Description |
---|---|
Parameter token | Description |
---|---|
Parameter token | Description |
---|---|
(1) On the instance running Keeper Connection Manager or your workstation, retrieve the or download as a zip file. Example:
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.
If you do not already have a Keeper subscription, please sign up for a 14-day free trial from this site:
If you already have a Keeper subscription but haven't activated Keeper Secrets Manager, .
username
string
The unique username of the user authenticated by the JSON. If the user is anonymous, this should be the empty string (""
).
expires
number
The absolute time after which the JSON should no longer be accepted, even if the signature is valid, as a standard UNIX epoch timestamp with millisecond resolution (the number of milliseconds since midnight of January 1, 1970 UTC).
connections
object
The set of connections which should be exposed to the user by their corresponding, unique names. If no connections will be exposed to the user, this can simply be an empty object ({}
).
protocol
string
The internal name of a supported protocol, such as vnc
, rdp
, ssh,
etc.
parameters
object
An object representing the connection parameter name/value pairs to apply to the connection, as documented in the Guacamole manual.
${GUAC_USERNAME}
The username provided by the current user when they successfully authenticated for their current Guacamole session.
${GUAC_PASSWORD}
The password provided by the current user when they successfully authenticated for their current Keeper session.
${GUAC_CLIENT_ADDRESS}
The IPv4 or IPv6 address of the current Guacamole user. This will be the address of the client side of the HTTP connection to the Guacamole server at the time the current user logged in.
${GUAC_CLIENT_HOSTNAME}
The hostname of the current logged-in user. This will be the hostname of the client side of the HTTP connection to the Guacamole server at the time the current user logged in. If no such hostname can be determined, the IPv4 or IPv6 address will be used instead, and this token will be equivalent to ${GUAC_CLIENT_ADDRESS}
.
${GUAC_DATE}
The current date in the local time zone of the Guacamole server. This will be written in "YYYYMMDD" format, where "YYYY" is the year, "MM" is the month number, and "DD" is the day of the month, all zero-padded. When a user accesses a connection, this token will be dynamically replaced with the date that the connection began.
${GUAC_TIME}
The current time in the local time zone of the Guacamole server. This will be written in "HHMMSS" format, where "HH" is hours in 24-hour time, "MM" is minutes, and "SS" is seconds, all zero-padded. When a user accesses a connection, this token will be dynamically replaced with the time that the connection began.
Using the Keeper Vault to create privileged sessions with Keeper Connection Manager
To connect KCM to your vault, we utilize Keeper Secrets Manager (KSM). KSM must first be enabled in the role policy enforcement settings of the role you are a member of (from the Admin Console). Then, you will see the tab "Secrets Manager" in your vault on the left side.
This integration requires that your KCM server is able to communicate to the Keeper Secrets Manager (KSM) endpoint over TLS port 443 where your Keeper tenant is hosted.
US: keepersecurity.com EU: keepersecurity.eu AU: keepersecurity.com.au CA: keepersecurity.ca JP: keepersecurity.jp US_GOV: govcloud.keepersecurity.us
Credentials for establishing connections are stored in Keeper shared folders. A Keeper Secrets Manager application is created and associated with the shared folder. A base64 device configuration is then created and added to your Keeper Connection Manager server.
(1) In the vault, create a shared folder and store credential records into this shared folder. For right now, the shared folder needs to be created and it can be populated later with credentials.
(2) From the Secrets Manager tab, create a Secrets Manager application and choose the shared folder which contains the credentials. A one-time access token is provided. You can use this one-time token, or go to Devices > Edit > Add Device > Method: Configuration File > Base64 and copy the base64 configuration string.
(3) You can run the reconfigure command to enter the Base64 configuration:
Alternatively you can input it manually by editing the file /etc/kcm-setup/docker-compose.yml
and adding the Base64 configuration into the "environment" section. For example:
(4) Save the file and run the upgrade command to bring in the changes.
(5) From the Keeper Connection Manager interface, create a new connection. Now, we can use dynamic tokens to pull in the credentials by matching the hostname/IP in KCM with the hostname/IP in your record in the shared folder that is tied to this KSM application.
There are many options including ${KEEPER_SERVER_USERNAME}
and ${KEEPER_SERVER_PASSWORD}
.
Setup complete! Other matching capabilities and available variables are documented on the dynamic tokens page.
If you wish to use the Keeper Commander CLI for establishing the integration between Keeper Connection Manager and Keeper Secrets Manager, follow the steps below.
(1) Set up your Keeper Vault
In your Keeper Vault, create a Shared Folder that is populated with credentials that will be used for making connections. In the example below you can see a shared folder called "Connection Manager Secrets" that includes a Windows 2022 Server password, SSH Key, MySQL Database, etc.
(2) Install Keeper Commander CLI
Our CLI tool will allow you to quickly set up the configuration.
There's a few ways to install Commander. We provide binary installers, pip3 packages or Python source code. The top level installation page is here:
(3) Login to Commander
After installation of Commander, login to the CLI:
In the example screenshot below, I'm logging in with a Keeper admin account using a FIDO2 key and Master Password. Depending on your security settings, you may have to pass device verification, MFA and password entry.
(4) Get the Shared Folder UID
The command lsf
will list the Shared Folders and display the UID.
In this example, the Shared Folder UID we're using is zyMiCn8596yvMln4YwdEdA
(5) Create an Application
A Secrets Manager application is created in the vault, which is assigned to the Shared Folder. An application is made up of one or more devices. Here we will create a Secrets Manager application and then retrieve the Application UID.
The resulting Secrets Manager App UID in this example is YGHY7nWrvkzEzF0I2AuFfg
(6) Assign the Shared Folder to the Application
In this step, we will assign our Shared Folder to the application.
If successful, you will get the response "Successfully added secrets to app".
(7) Generate a Client Configuration
In this step, we will create a client device configuration. This client device configuration will be directly provided to the Connection Manager.
The "Initialized Config" section in green must now be added to the Keeper Connection Manager configuration file. The location of the configuration will depend on which method of installation, as described in the next section.
Copy the token for the next section where it will be initialized
If you installed Keeper Connection Manager using the Auto Docker Install method, you will need to modify the auto-generated Docker Compose file to include the integration token.
(1) On the local instance, it is a good idea to stop the containers. You can do this using kcm-setup or using docker-compose directly.
or...
Using the simple docker method creates a docker-compose.yml
file that is preconfigured for you. One change to this file will be needed to add KSM support.
(2) Edit the /etc/kcm-setup/docker-compose.yml
file. You can use your favorite editor on the linux system such as nano or vim.
Look for the "guacamole" docker image and the "environment" section which defines environment variables. A sample file is listed below. Paste the token from step 6 above.
(3) Save the File and Apply Changes
Once the file changes have been saved, simply run:
Test Login and Initialize Token
Now that the KSM integration is completed, please ensure that you're able to login normally to Keeper Connection Manager and open connections. If errors occur, please check the log files.
If you are unable to login or launch connections, see the troubleshooting section to learn how to check the log files.
If you installed Keeper Connection Manager using the Custom Docker Install method, you will need to modify your Docker Compose file to include the integration token. The instructions for activating the integration are below:
(1) On the local instance, stop the containers.
(2) Edit your docker-compose.yml
file. Look for the "guacamole" docker image and the "environment" section which defines environmental variables. A sample file is listed below. Paste the token from step 6 above.
(3) Save the File and Update Containers
Once the file changes have been saved, simply update the containers:
Test Login and Initialize Token
Now that the KSM integration is completed, please ensure that you're able to login normally to Keeper Connection Manager and open connections. If errors occur, please check the log files.
If you are unable to login or launch connections, see the troubleshooting section to learn how to check the log files.
Using the integration between Connection Manager and Vault with dynamic field lookups
When using the vault integration, specific tokens are replaced by the corresponding value from a Keeper record.
There are dynamic and static tokens. Dynamic tokens will search the Keeper vault for a matching record to extract the necessary secret fields. Static tokens can also be created that explicitly reference a particular Keeper record and field.
Keeper Records can be assigned to connections by the "Hostname" field in the connection and the "Hostname or IP Address" field in the vault record.
If these two values match, Connection Manager will fetch and replace tokens in other connection fields with values from the record, such as Username, Password, Domain, etc...
Keeper Records can be assigned to connections by the "Username" field in the connection and the "Login" field in the vault record.
If these two values match, Connection Manager will fetch and replace tokens in other connection fields with secrets from the record.
As one example, this is useful for mapping a single SSH key to multiple servers. This way, you don't need to store one record per host in the vault. A single Keeper vault record can be used to authenticate any number of connections. Below is a Connection that is set up to match on Username.
The corresponding vault record is seen below. No hostname is specified in the vault record, so the match will occur based on the login field.
For user-based matching, ensure that the Keeper record does not have a Hostname/Port. It should simply contain the username and password (or private key).
Keeper Records can be retrieved for connections by matching on the "Domain" field in the connection and a custom field called "Domain" in the vault record.
If these two values match, Connection Manager will fetch and replace tokens in other connection fields with values from the record, such as Username, Password, etc...
If you would prefer to store the Domain as part of the username field (e.g. LUREY\Administrator), this can be activated by turning on the KSM_STRIP_WINDOWS_DOMAINS
flag to "True" in the Docker container environmental variables for the keeper/guacamole image.
As another example, if you are using SSH to a Linux machine with Active Directory credentials in the format of username@domain
, you can store this value in the Login field.
The built-in tokens each correspond to a record field. The table below lists each token and its corresponding record field. These tokens are applicable to all connection types.
The tokens below are applicable only to connection types that have gateway support (RDP).
KCM will identify the Domain, Username and Password fields from the Keeper Vault record, as long as there is a field with the corresponding name. For example:
The Active Directory "Domain" and "Username" field can be parsed if the Login value in the Keeper Vault is supplied in the format of DOMAIN\Username
or Username@Domain
.
To activate automatic parsing, the environmental variable KSM_STRIP_WINDOWS_DOMAINS
must be added to the Docker Config file. This allows matching to work if the username is combined with the domain.
Another property called KSM_MATCH_DOMAINS_FOR_USERS
will force matching to occur only if both the username and domain match exactly.
For example:
In the record, the Login field can then contain
Using the integration between Connection Manager and Vault with static field lookups
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.
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.
Once the file changes have been saved, update the containers:
Edit your docker-compose.yml
file. Look for the "guacamole" docker image and the "environment" section which defines environmental variables.
Once the file changes have been saved, update the containers:
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:
The records must be in the shared folder that your Secrets Manager Application has access to.
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 .
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 .
Parameter Token
Description
${KEEPER_SERVER_USERNAME}
Retrieves: “Login” field of single matched record
Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter
${KEEPER_SERVER_KEY}
Retrieves: “Private Key” field (or single .pem file attachment) of single matched record
Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter
${KEEPER_SERVER_PASSPHRASE}
Retrieves: “Passphrase” field (or “password” if no passphrase) of single matched record
Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter
${KEEPER_SERVER_PASSWORD}
Retrieves: “Password” field of single matched record
Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter
${KEEPER_SERVER_DOMAIN}
Retrieves: “Domain” custom field of single matched record
Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter
${KEEPER_USER_KEY}
Retrieves: “Private Key” field (or single .pem file attachment) of single matched record
Matches: Record with login matching the “username” connection parameter
${KEEPER_USER_PASSPHRASE}
Retrieves: “Passphrase” field (or “password” if no passphrase) of single matched record
Matches: Record with login matching the “username” connection parameter
${KEEPER_USER_PASSWORD}
Retrieves: “Password” field of single matched record
Matches: Record with login matching the “username” connection parameter
${KEEPER_USER_DOMAIN}
Retrieves: “Domain” custom field of single matched record
Matches: Record with login matching the “username” connection parameter
${KEEPER_DOMAIN_USERNAME}
Retrieves: “Login” field of single matched record
Matches: Record with custom "Domain" field matching the value of the “domain” connection parameter
${KEEPER_DOMAIN_PASSWORD}
Retrieves: “Password” field of single matched record
Matches: Record with login matching the “domain” connection parameter
Parameter Token
Description
${KEEPER_GATEWAY_USERNAME}
Retrieves: “Login” field of single matched record
Matches: Record with hostname / IP address matching the value of the “gateway-hostname” connection parameter.
${KEEPER_GATEWAY_KEY}
Retrieves: “Private Key” field (or single .pem file attachment) of single matched record
Matches: Record with hostname / IP address matching the value of the “gateway-hostname” connection parameter.
${KEEPER_GATEWAY_PASSPHRASE}
Retrieves: “Passphrase” field (or “password” if no passphrase) of single matched record
Matches: Record with hostname / IP address matching the value of the “gateway-hostname” connection parameter.
${KEEPER_GATEWAY_PASSWORD}
Retrieves: “Password” field of single matched record
Matches: Record with hostname / IP address matching the value of the “gateway-hostname” connection parameter.
${KEEPER_GATEWAY_USER_KEY}
Retrieves: “Private Key” field (or single .pem file attachment) of single matched record
Matches: Record with login matching the “gateway-username” connection parameter.
${KEEPER_GATEWAY_USER_PASSPHRASE}
Retrieves: “Passphrase” field (or “password” if no passphrase) of single matched record
Matches: Record with login matching the “gateway-username” connection parameter
${KEEPER_GATEWAY_USER_PASSWORD}
Retrieves: “Password” field of single matched record
Matches: Record with login matching the “gateway-username” connection parameter
Advanced configuration and custom integration options
Supported extensions, such as those provided by the Keeper Connection Manager packages, are installed through installing their corresponding packages. If you are using the keeper/guacamole Docker image, 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.
Advanced features of the Keeper Vault integration
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.
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:
AFTER:
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:
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:
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:
In docker installations, the parameter ADDITIONAL_GUACAMOLE_PROPERTIES_KSM
can be used to move parameters from the guacamole.properties file into guacamole.properties.ksm.
Integrate with multiple Keeper Vaults or multiple Shared Folders using Keeper Secrets Manager
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:
Connection Groups can be assigned to different secrets manager configurations. Any connection defined within a Connection Group will retrieve secrets from the group assignment.
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.
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.
Note: A Secrets Manager configuration must be established in the baseline configuration as a default to use connection group Secrets Manager configurations. See the documentation for information on setting up a Secrets Manager 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.
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:
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.
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.
Advanced configuration properties within guacamole.properties
The guacamole.properties
file, located within /etc/guacamole
, is Guacamole’s main configuration file. Keeper Connection Manager provides a thoroughly-commented version of this configuration file, including example properties organized into logical sections with accompanying documentation.
The hostname and port of the machine hosting the guacd service, as well as whether that guacd service has been configured for SSL/TLS. By default, Guacamole will connect to guacd at port 4822 on localhost, and will not use SSL/TLS to do so.
The amount of time, in minutes, a Guacamole session may remain valid despite being inactive. By default, Guacamole sessions remain valid for 60 minutes.
It is unusual to need to change this setting:
File transfers within a remote desktop session are not affected by this limit.
Requests unrelated to file transfer should normally be well beneath the default limit (2 MB).
If you find yourself considering changing this property value, first investigate whether there may be any external factors causing the problem you're seeing, such as a reverse proxy, firewall, or browser extension. It is more common that the settings of the reverse proxy providing SSL termination need to be adjusted, and that no change needs to be made to Guacamole's request size limits whatsoever.
The maximum number of bytes to accept within the entity body of any particular HTTP request to Guacamole's internal REST API, including authentication requests. By default, HTTP requests made against the Guacamole web application are limited to 2 MB, excluding requests related to file transfer for a remote desktop session.
If you have developed your own branding extension that overrides Guacamole's translation strings only for a subset of Guacamole's supported languages, you can force Guacamole to reduce the set of supported languages to only those languages you have modified. This is only necessary if you have developed your own branding. Branding extensions provided by Keeper Connection Manager as part of a Keeper Connection Manager subscription will update all supported languages.
In addition to the standard properties accepted by the web application, extensions may read additional properties which are specific to their own configuration needs. The guacamole.properties
file included with Keeper Connection Manager contains comments which cleanly group configuration into distinct sections for each supported extension, along with example properties and documentation.
OpenID Connect Configuration Properties
TOTP Configuration Properties
UDS Enterprise Configuration Properties
Retrieve Cloud Connector Secrets from KSM
You can store SSH Keys and Windows passwords in your Keeper vault for connecting to EC2 instances alongside the KCM Cloud Connector.
See the AWS EC2 Discovery documentation for more details on connecting KCM with AWS EC2 instances.
The feature must first be enabled using either the Docker environment variable or the guacamole properties.
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.
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.
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.
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.
Optionally, if you include a Hostname/IP and Port field in your record, KCM will automatically associate the pem file with EC2 connections having a matching Hostname/IP.
Lastly, ensure that the new record is in a shared folder that is accessible to KCM via the Secrets Manager vault connection.
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".
The Instance ID field can also be titled anything which begins with "AWS" or "EC2"
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.
Optionally, if you include a Hostname and Port field in your record, KCM will automatically associate the private key with EC2 connections with a matching IP address
The record is now complete, and will be picked up automatically by KCM if the feature is enabled.
Advanced configuration properties for SAML 2.0 SSO
Keeper Connection Manager loads authentication extensions in order of priority, and evaluates authentication attempts in this same order. This has implications for how the login process behaves when an SSO extension is present:
If the SSO extension has priority:
Users that are not yet authenticated will be immediately redirected to the configured identity provider. They will not see a Keeper Connection Manager login screen.
If a non-SSO extension has priority:
Users that are not yet authenticated will be presented with a Keeper Connection Manager login screen. Additionally, links to the configured identity provider(s) will be available for users that wish to log in using SSO.
The default priority of extensions is dictated by their filenames, with extensions that sort earlier alphabetically having higher priority than others. This can be overridden by setting the extension-priority
property within guacamole.properties
.
Automatically redirecting all unauthenticated users
To ensure users are redirected to the SAML identity provider immediately (without a Keeper Connection Manager login screen), ensure the SAML extension has priority over all others:
Presenting unauthenticated users with a login screen
To ensure users are given a normal Keeper Connection Manager login screen and have the option to log in with traditional credentials or with SAML, ensure the SAML extension does not have priority:
Advanced configuration properties for Duo 2FA
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.
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
:
Advanced configuration properties for MySQL
Minimum password length and complexity
Minimum/maximum password age
Password reuse prevention
General connection concurrency limits
Per-user concurrency limits
Absolute concurrency limits
The TCP connection details for the MySQL / MariaDB database.
The name of the database to use, as well as the credentials to use when connecting to the database. These properties are required if one of the database authentication extensions will be used.
Restrictions that should be applied to all database users with respect to password complexity, length, change frequency, and reuse.
These properties do not affect users defined outside the database.
Concurrent usage restrictions that should be enforced by default across all connections. With the exception the absolute concurrency limit, each of these restrictions may be overridden by the administrator on a per-connection basis by editing the connection.
Whether authentication via other extensions is allowed for users that do not exist within the MySQL / MariaDB database. If set to "true", authentication attempts will be denied unless the authenticated user has been defined within the database.
Extension | Package name | Docker image environment variables |
---|---|---|
Property name | Default value | Description |
---|---|---|
Property name | Default value | Description |
---|---|---|
Property name | Default value | Description |
---|---|---|
Property name | Description |
---|---|
Property Name | Default Value | Description |
---|---|---|
The properties listed here are only applicable if SAML 2.0 authentication is being used. Support for SAML 2.0 authentication is installed using package or enabled with the Docker installation. If using the Docker image, support for SAML 2.0 authentication is configured using environment variables.
Property name | Description |
---|
The properties listed here are only applicable if Duo two-factor authentication is being used. Support for Duo two-factor authentication is or enabled with the Docker installation. If using, support for Duo two-factor authentication is configured using environment variables.
Property name | Description |
---|
Property name | Description |
---|
The properties listed here are only applicable if MySQL authentication is being used. Support for MySQL authentication is. If using, support for MySQL authentication is instead configured using environment variables.
Property name | Default value | Description |
---|
Property name | Description |
---|
Property name | Default value | Description |
---|
Property name | Description |
---|
Property name | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
kcm-guacamole-auth-ldap
LDAP_*
kcm-guacamole-auth-duo
DUO_*
kcm-guacamole-auth-json
JSON_*
MySQL / MariaDB database support
kcm-guacamole-auth-jdbc-mysql
MYSQL_*
PostgreSQL database support
kcm-guacamole-auth-jdbc-postgresql
POSTGRES_*
SQL Server database support
kcm-guacamole-auth-jdbc-sqlserver
SQLSERVER_*
kcm-guacamole-auth-totp
TOTP_*
kcm-guacamole-auth-saml
SAML_*
kcm-guacamole-auth-openid
OPENID_*
guacd-hostname
localhost
The hostname of the machine hosting the guacd service.
guacd-port
4822
The port used by the guacd service.
guacd-ssl
false
Whether the guacd service has been configured for SSL/TLS.
api-session-timeout
60
The amount of time, in minutes, a Guacamole session may remain valid despite being inactive.
This setting affects Guacamole sessions only, not remote desktop sessions. To enforce limits on the duration of remote desktop sessions, you must change the relevant setting within your remote desktop server, such as the session time limit GPOs provided by the Windows RDP server. Guacamole considers a connected remote desktop session to be user activity, and does not attempt to define what constitutes an idle but connected remote desktop session.
api-max-request-size
2097152
The maximum number of bytes to accept within the entity body of any particular HTTP request to the REST API, including authentication requests. This limit does not apply to files transferred within a remote desktop session. Specifying 0 disables request size limitations.
If setting this property intending to remove or lessen limitations on request sizes, be sure to check the settings of any reverse proxy providing SSL termination. Your reverse proxy may impose its own default limitations that will need to be overridden. For example, Nginx imposes a default limit of 1 MB per request.
allowed-languages
A comma-separated list of language keys for Guacamole's display language. If specified, only the listed languages will be made available to the user, and only the listed languages will be selected from automatically based on the user's browser's preferred language. By default, all defined languages will be available.
For example, to restrict Guacamole to only English and German, specify:
As English is the fallback language, used whenever a translation key is missing from the chosen language, English should only be omitted from this list if you are absolutely positive that no strings are missing from your custom translations.
aws-discovery-ksm-config
false
Enable the use of Cloud Connect credentials from KSM connected vaults
| The URI of the XML metadata file that from the SAML Identity Provider that contains all of the information the SAML extension needs in order to know how to authenticate with the IdP. This URI can either be a remote server (e.g. |
| The base URL of the SAML IdP. This is the URL that the SAML authentication extension will use to redirect when requesting SAML authentication. If the |
| The entity ID of the Keeper Connection Manager SAML client, which is generally the URL of the Keeper Connection Manager server, but is not required to be so. This property is required if either the |
| The URL that the IdP will use once authentication has succeeded to return to the Keeper Connection Manager web application and provide the authentication details to the SAML extension. The SAML extension currently only supports callback as a POST operation to this callback URL. This property is required. |
| Require strict security checks during SAML logins. This will insure that valid certificates are present for all interactions with SAML servers and fail SAML authentication if security restrictions are violated. This property is optional, and will default to true, requiring strict security checks. This property should only be set to false in non-production environments during testing of SAML authentication. |
| Enable additional logging within the supporting SAML library that can assist in tracking down issues during SAML logins. This property is optional, and will default to false (no debugging). |
| Enable compression of the HTTP requests sent to the SAML IdP. This property is optional and will default to true (compression enabled). |
| Request that the SAML response returned by the IdP be compressed. This property is optional and will default to "true" (compression will be requested). |
| The name of the attribute provided by the SAML IdP that contains group membership of the user. These groups will be parsed and used to map group membership of the user logging in, which can be used for permissions management within the Keeper Connection Manager Client, particularly when layered with other authentication modules. This property is optional, and defaults to “groups”. |
| Path to a private key for use with connecting to an ID Provider which is configured to expect signed requests |
| Path to a certificate used to authenticate to an ID Provider which is configured to expect signed requests |
| The hostname of the Duo API endpoint to be used to verify user identities, generated by Duo when you registered Guacamole within Duo's "Admin" panel. This value can be found within the application details in the "API hostname" field. |
| The integration key provided for Guacamole by Duo when you registered Guacamole within Duo's "Admin" panel. This value can be found within the application details in the "Integration key" field. |
| The secret key provided for Guacamole by Duo when you registered Guacamole within Duo's "Admin" panel. This value can be found within the application details in the "Secret key" field. |
| The arbitrary, random key to use when communicating with the Duo service. |
| localhost | The hostname of the database server. |
| 3306 | The port of the MySQL or MariaDB service running on the database server. |
| The name of the database that Guacamole should issue queries against. |
| The username of the user that Guacamole should use to connect to the database. |
| The password Guacamole should provide when authenticating with the database. |
| 0 | The minimum length of each password, in characters. If specified, users will not be able to change their passwords to values that are not at least this length. By default, no minimum length is enforced. Empty passwords are never allowed. |
| false | If set to "true", require that all passwords contain at least one uppercase character and one lowercase character. By default, passwords are not required to contain mixed case. |
| false | If set to "true", require that all passwords contain at least one symbol, where a "symbol" is any non-alphanumeric character. By default, passwords are not required to contain symbols. |
| false | If set to "true", require that all passwords contain at least one digit, where a "digit" is any numeric character. By default, passwords are not required to contain digits. |
| false | If set to "true", prohibit passwords from containing the user's own username, regardless of case. By default, use of the user's own username within their password is not prevented. |
| The minimum number of days that must elapse between password changes (preventing users from changing passwords too frequency and defeating password reuse protections). By default, frequency of password changes is not restricted. |
| The maximum number of days that may elapse before users are required to change their passwords. By default, users passwords do not automatically expire. |
| The number of past passwords that should be remembered for each user. If specified, users will be prevented from reusing any of these passwords. By default, reuse of past passwords is not prevented. |
| 0 | The maximum number of concurrent connections to allow to any particular connection, where "0" represents unlimited. By default, no overall concurrency limits are enforced on connections. |
| 0 | The maximum number of concurrent connections to allow to any particular balancing connection group, where "0" represents unlimited. By default, no overall concurrency limits are enforced on connection groups. |
| 0 | The maximum number of concurrent connections to allow to any individual user to establish to a connection, where "0" represents unlimited. By default, no per-user concurrency limits are enforced on connections. |
| 1 | The maximum number of concurrent connections to allow to any individual user to establish to a balancing connection group, where "0" represents unlimited. By default, no each user is limited to a single connection for each balancing connection group, to avoid allowing any one user to exhaust the available connections within that group.. |
| 0 | The absolute maximum number of concurrent connections to allow to the Guacamole server as a whole, regardless of which users are establishing those connections and which connections or groups are being accessed, where "0" represents unlimited. By default, no absolute concurrent restrictions are enforced. |
| false | If set to "true", require that all successful authentication attempts be associated with a user defined within MySQL. If a user authentications successfully via another mechanism (such as LDAP), that attempt will still be denied if no corresponding MySQL user exists. By default, successful authentication attempts will be considered successful regardless of whether an account for that user exists within MySQL. |
kcm-guacamole-auth-jdbc-mysql
packageAdvanced configuration properties for Encrypted JSON Auth
The properties listed here are only applicable if encrypted JSON authentication is being used. Support for encrypted JSON authentication is installed using the kcm-guacamole-auth-json
package. If using the keeper/guacamole Docker image, support for encrypted JSON authentication is instead configured using environment variables.
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:
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.
Advanced configuration properties for LDAP Authentication
The properties listed here are only applicable if LDAP authentication is being used. Support for LDAP authentication is installed using the kcm-guacamole-auth-ldap
package. If using the keeper/guacamole Docker image, support for LDAP authentication is instead configured using environment variables.
The TCP connection details of the LDAP server, as well as whether encryption should be used.
The base DN of all Guacamole users within the LDAP directory, and the attribute which contains each user's username. If the username attribute is not part of the DN, a search DN will need to be provided, as well.
The DN and password of the user to bind as when searching for the DN of each user attempting to log in. If omitted, the DN of each user will be derived directly using the user base DN and username attribute.
The base DN of all Guacamole user groups within the LDAP directory, and the attribute which contains each group's name. If storing connection information within LDAP, the provided base DN must also contain any groups that may be referenced within "guacConfigGroup" objects using the "seeAlso" attribute.
The base DN for all Guacamole connections defined directly within the LDAP directory using "guacConfigGroup" objects. The LDAP schema files for "guacConfigGroup" objects can be found within /usr/share/guacamole-auth-ldap/schema
in both LDIF and .schema format. Note that storing connections directly within the LDAP directory is optional. If connections will not be stored within the directory, this base DN should not be provided.
The maximum number of LDAP search results which can be returned by a single query. LDAP searches which exceed this limit will fail.
Arbitrary LDAP user attributes may be used to dynamically affect the behavior of connections based on the user accessing them. When a user authenticates with LDAP and subsequently accesses a particular Guacamole connection, the values of these attributes will be made available as parameter tokens and applied to the parameters of the connection. If the attribute has no value for the current user, then the corresponding token is not applied. If the attribute has multiple values, then the first value of the attribute is used.
These attributes must be configured for use as parameter tokens ahead of time by being explicitly listed within /etc/guacamole/guacamole.properties
. By default, no LDAP user attributes are made available as parameter tokens.
When converting an LDAP attribute name into a parameter token name, the name of the attribute is transformed into uppercase with each word separated by underscores, a naming convention referred to as "uppercase with underscores" or "screaming snake case". For example:
The search filter which should be used to retrieve lists of users or groups from the LDAP directory. By default, a filter which matches all objects is used, and the only restriction is given through the relevant base DN. If you need to narrow the lists of users or groups further, the default filter can be overridden.
If overriding a search filter, be sure that the filter is a valid LDAP filter. In particular, an LDAP filter must be enclosed in a matching pair of parenthesis. If unsure whether your filter is valid, or if seeing unexpected results, it can be helpful to verify your filter against your LDAP server using a command-line utility like "ldapsearch
".
Whether (and how) Guacamole should follow LDAP aliases or referrals when encountered during an LDAP query. By default, Guacamole will not dereference aliases and will not follow referrals.
Advanced configuration properties for PostgreSQL
Minimum password length and complexity
Minimum/maximum password age
Password reuse prevention
General connection concurrency limits
Per-user concurrency limits
Absolute concurrency limits
The TCP connection details for the PostgreSQL database.
The name of the database to use, as well as the credentials to use when connecting to the database. These properties are required if one of the database authentication extensions will be used.
Restrictions that should be applied to all database users with respect to password complexity, length, change frequency, and reuse.
These properties do not affect users defined outside the database.
Concurrent usage restrictions that should be enforced by default across all connections. With the exception the absolute concurrency limit, each of these restrictions may be overridden by the administrator on a per-connection basis by editing the connection.
Whether authentication via other extensions is allowed for users that do not exist within the PostgreSQL database. If set to "true", authentication attempts will be denied unless the authenticated user has been defined within the database.
Advanced configuration properties for SQL Server
Minimum password length and complexity
Minimum/maximum password age
Password reuse prevention
General connection concurrency limits
Per-user concurrency limits
Absolute concurrency limits
The TCP connection details for the SQL Server database.
The name of the database to use, as well as the credentials to use when connecting to the database. These properties are required if one of the database authentication extensions will be used.
Restrictions that should be applied to all database users with respect to password complexity, length, change frequency, and reuse.
These properties do not affect users defined outside the database.
Concurrent usage restrictions that should be enforced by default across all connections. With the exception the absolute concurrency limit, each of these restrictions may be overridden by the administrator on a per-connection basis by editing the connection.
Whether authentication via other extensions is allowed for users that do not exist within the SQL Server database. If set to "true", authentication attempts will be denied unless the authenticated user has been defined within the database.
Property name | Description |
---|---|
Property name | Description |
---|---|
LDAP Attribute | Parameter Token |
---|---|
The properties listed here are only applicable if PostgreSQL authentication is being used. Support for PostgreSQL authentication is. If using , support for PostgreSQL authentication is instead configured using environment variables.
Property name | Default value | Description |
---|
Property name | Description |
---|
Property name | Default value | Description |
---|
Property name | Description |
---|
Property name | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
The properties listed here are only applicable if SQL Server authentication is being used. Support for SQL Server authentication is . If using , support for SQL Server authentication is instead configured using environment variables.
Property name | Default value | Description |
---|
Property name | Description |
---|
Property name | Default value | Description |
---|
Property name | Description |
---|
Property name | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
Property name | Default value | Description |
---|
json-secret-key
The 128-bit secret key that will be used to encrypt and sign JSON sent to Guacamole for authentication, formatted as 32 hexadecimal digits. Received JSON will not be accepted unless it has been encrypted and signed using this key.
json-trusted-networks
A comma-separated list of IP addresses and/or CIDR subnets which should be allowed to authenticate using encrypted JSON. By default, encrypted JSON is accepted without restriction from any address or subnet.
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Default value
Description
ldap-hostname
hostname
localhost
The hostname/address of the LDAP server.
ldap-port
port
389, or 636 for LDAPS
The TCP port that the LDAP server is listening on.
ldap-encryption-method
encryption-method
none
The encryption method to use when communicating with the LDAP server. Valid encryption methods are:
none
(for unencrypted LDAP)
ssl
(for LDAP over SSL/TLS, also known as LDAPS)
starttls
(for STARTTLS)
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Default value
Description
ldap-user-base-dn
user-base-dn
N/A
The base DN beneath which all relevant LDAP users may be found. If not using a search DN, this DN must be the common portion of the DN shared by all users to which the username attribute can be added.
ldap-username-attribute
username-attribute
uid
The attribute which contains the user's username. For OpenLDAP, the default value of "uid" is usually correct. For Active Directory, the correct value is typically "sAMAccountName", and a search DN will be needed due to indirect mapping of the username.
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Description
ldap-search-bind-dn
search-bind-dn
The DN of the user that Guacamole should bind as when attempting to resolve the DN of an authenticating user (indirect username mapping). If omitted, the DN of each user will be derived directly from the base DN and username attribute. Note that the permissions associated with this account do not affect whether a user can see objects within the LDAP directory. Users, connections, etc. will only be visible to LDAP users if those users are granted permission to see those objects within LDAP.
ldap-search-bind-password
search-bind-password
The password that should be provided when Guacamole binds with the given search DN in order to resolve the DN of an authenticating user.
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Default value
Description
ldap-group-base-dn
group-base-dn
N/A
The base DN beneath which all relevant LDAP groups may be found. This tree will be searched using the user's own credentials to determine their group memberships upon login.
If storing connection information within LDAP, this must also be the base DN of the LDAP directory subtree that should be searched for "guacConfigGroup" memberships specified using the "seeAlso" attribute.
ldap-group-name-attribute
group-name-attribute
cn
The attribute which contains the group's name. For most LDAP servers, including Active Directory, the default value of "cn" is usually correct.
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Description
ldap-config-base-dn
config-base-dn
The base DN of the LDAP subtree that should be searched for connections stored directly within the directory ("guacConfigGroup" objects). If connections are not being stored within the LDAP directory (no schema changes have been applied), this property should not be specified.
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Default value
Description
ldap-max-search-results
max-search-results
1000
The maximum number of LDAP search results to retrieve via a single query. By default, LDAP searches are limited to returning a maximum of 1000 entries.
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Description
ldap-user-attributes
user-attributes
The attribute or attributes to retrieve from the LDAP directory for users that authenticate using LDAP, separated by commas. If specified, the attributes listed here are retrieved from each authenticated user and dynamically applied to the parameters of that user's connections as parameter tokens with the prefix "LDAP_
".
lowercase-with-dashes
${LDAP_LOWERCASE_WITH_DASHES}
CamelCase
${LDAP_CAMEL_CASE}
headlessCamelCase
${LDAP_HEADLESS_CAMEL_CASE}
lettersAndNumbers1234
${LDAP_LETTERS_AND_NUMBERS_1234}
aRANDOM_mixOf-3NAMINGConventions
${LDAP_A_RANDOM_MIX_OF_3_NAMING_CONVENTIONS}
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Default value
Description
ldap-user-search-filter
user-search-filter
(objectClass=*)
The search filter which should be used to retrieve the list of users from the LDAP directory. If a search DN is used (indirect user mapping), this filter will also restrict the users that can log into Guacamole.
ldap-group-search-filter
group-search-filter
(objectClass=*)
The search filter which should be used to retrieve the list of groups that may be used by other extensions to define permissions.
Property name (guacamole.properties
)
Property name (ldap-servers.yml
)
Default value
Description
ldap-dereference-aliases
dereference-aliases
never
The method that Guacamole should use to dereference LDAP aliases, if at all. Legal alias dereferencing modes are:
never
(do not dereference aliases at all)
searching
(dereference aliases only after the search base has been found)
finding
(dereference aliases only when finding the search base)
always
(dereference aliases in all cases)
ldap-follow-referrals
follow-referrals
false
If set to "true", referrals received from the LDAP directory will be automatically followed. By default, referrals are not followed.
ldap-max-referral-hops
max-referral-hops
5
The maximum number of referrals to follow before aborting an LDAP query. This property only has an effect if LDAP referral following is enabled. If referral following is enabled, the following performed is limited to 5 hops by default.
| localhost | The hostname of the database server. |
| 5432 | The port of the PostgreSQL service running on the database server. |
| The name of the database that Guacamole should issue queries against. |
| The username of the user that Guacamole should use to connect to the database. |
| The password Guacamole should provide when authenticating with the database. |
| 0 | The minimum length of each password, in characters. If specified, users will not be able to change their passwords to values that are not at least this length. By default, no minimum length is enforced. Empty passwords are never allowed. |
| false | If set to "true", require that all passwords contain at least one uppercase character and one lowercase character. By default, passwords are not required to contain mixed case. |
| false | If set to "true", require that all passwords contain at least one symbol, where a "symbol" is any non-alphanumeric character. By default, passwords are not required to contain symbols. |
| false | If set to "true", require that all passwords contain at least one digit, where a "digit" is any numeric character. By default, passwords are not required to contain digits. |
| false | If set to "true", prohibit passwords from containing the user's own username, regardless of case. By default, use of the user's own username within their password is not prevented. |
| The minimum number of days that must elapse between password changes (preventing users from changing passwords too frequency and defeating password reuse protections). By default, frequency of password changes is not restricted. |
| The maximum number of days that may elapse before users are required to change their passwords. By default, users passwords do not automatically expire. |
| The number of past passwords that should be remembered for each user. If specified, users will be prevented from reusing any of these passwords. By default, reuse of past passwords is not prevented. |
| 0 | The maximum number of concurrent connections to allow to any particular connection, where "0" represents unlimited. By default, no overall concurrency limits are enforced on connections. |
| 0 | The maximum number of concurrent connections to allow to any particular balancing connection group, where "0" represents unlimited. By default, no overall concurrency limits are enforced on connection groups. |
| 0 | The maximum number of concurrent connections to allow to any individual user to establish to a connection, where "0" represents unlimited. By default, no per-user concurrency limits are enforced on connections. |
| 1 | The maximum number of concurrent connections to allow to any individual user to establish to a balancing connection group, where "0" represents unlimited. By default, no each user is limited to a single connection for each balancing connection group, to avoid allowing any one user to exhaust the available connections within that group.. |
| 0 | The absolute maximum number of concurrent connections to allow to the Guacamole server as a whole, regardless of which users are establishing those connections and which connections or groups are being accessed, where "0" represents unlimited. By default, no absolute concurrent restrictions are enforced. |
| false | If set to "true", require that all successful authentication attempts be associated with a user defined within PostgreSQL. If a user authentications successfully via another mechanism (such as LDAP), that attempt will still be denied if no corresponding PostgreSQL user exists. By default, successful authentication attempts will be considered successful regardless of whether an account for that user exists within PostgreSQL. |
| localhost | The hostname of the database server. |
| 1433 | The port of the SQL Server service running on the database server. |
| The name of the database that Guacamole should issue queries against. |
| The username of the user that Guacamole should use to connect to the database. |
| The password Guacamole should provide when authenticating with the database. |
| 0 | The minimum length of each password, in characters. If specified, users will not be able to change their passwords to values that are not at least this length. By default, no minimum length is enforced. Empty passwords are never allowed. |
| false | If set to "true", require that all passwords contain at least one uppercase character and one lowercase character. By default, passwords are not required to contain mixed case. |
| false | If set to "true", require that all passwords contain at least one symbol, where a "symbol" is any non-alphanumeric character. By default, passwords are not required to contain symbols. |
| false | If set to "true", require that all passwords contain at least one digit, where a "digit" is any numeric character. By default, passwords are not required to contain digits. |
| false | If set to "true", prohibit passwords from containing the user's own username, regardless of case. By default, use of the user's own username within their password is not prevented. |
| The minimum number of days that must elapse between password changes (preventing users from changing passwords too frequency and defeating password reuse protections). By default, frequency of password changes is not restricted. |
| The maximum number of days that may elapse before users are required to change their passwords. By default, users passwords do not automatically expire. |
| The number of past passwords that should be remembered for each user. If specified, users will be prevented from reusing any of these passwords. By default, reuse of past passwords is not prevented. |
| 0 | The maximum number of concurrent connections to allow to any particular connection, where "0" represents unlimited. By default, no overall concurrency limits are enforced on connections. |
| 0 | The maximum number of concurrent connections to allow to any particular balancing connection group, where "0" represents unlimited. By default, no overall concurrency limits are enforced on connection groups. |
| 0 | The maximum number of concurrent connections to allow to any individual user to establish to a connection, where "0" represents unlimited. By default, no per-user concurrency limits are enforced on connections. |
| 1 | The maximum number of concurrent connections to allow to any individual user to establish to a balancing connection group, where "0" represents unlimited. By default, no each user is limited to a single connection for each balancing connection group, to avoid allowing any one user to exhaust the available connections within that group.. |
| 0 | The absolute maximum number of concurrent connections to allow to the Guacamole server as a whole, regardless of which users are establishing those connections and which connections or groups are being accessed, where "0" represents unlimited. By default, no absolute concurrent restrictions are enforced. |
| false | If set to "true", require that all successful authentication attempts be associated with a user defined within SQL Server. If a user authentications successfully via another mechanism (such as LDAP), that attempt will still be denied if no corresponding SQL Server user exists. By default, successful authentication attempts will be considered successful regardless of whether an account for that user exists within SQL Server. |
kcm-guacamole-auth-jdbc-postgresql
packagekcm-guacamole-auth-jdbc-sqlserver
packageAs 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.
By default KCM will lock a user out of logging in for 5 minutes after 5 failed attempts
Use the following properties to change the login attempt settings
Integrating Keeper Connection Manager with 3rd party software and applications
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.
Documentation
JavaDoc for the Apache Guacamole 1.3.0 core API (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, consulting on integration is included with premium subscriptions.
Historical release changelog for Keeper Connection Manager
Release notes are published at Keeper's Release Notes portal.
-> Keeper Connection Manager Release Notes
Common troubleshooting and log inspection
If things are not behaving as expected, a good first step is always to check the logs. There may be messages logged by Guacamole or guacd which describe exactly what is failing, or which will at least point you in the right direction toward resolving a problem.
If you installed Keeper Connection Manager using the Auto Docker Install method, you can use the kcm-setup.run script to check log files.
To look at individual log files, you can specify the type of log output:
If you want to start digging around the Docker images, the below commands will get you started:
When you have installed using the Custom Docker Install method, you can use the built-in docker and docker-compose logging commands.
For example, when using docker-compose:
Using the regular docker command, locate the container ID through either "docker ps":
Then you can reference the specific container to get the logs:
If Keeper Connection Manager is hanging during startup, or unable to connect to any hosts, one thing to quickly check is if the Linux machine is capable of generating enough entropy for random number generation. To resolve this, we recommend installing the haveged
package.
These packages can be installed using the commands below (CentOS / RHEL):
Verify that your server can access the internet
Depending on the configuration of your network and server, internet access may be unavailable. If this is the case, the site hosting the repository will not be reachable and the packages will not be able to be downloaded. You will need to adjust the configuration of your network/server to ensure the repository can be accessed. Alternatively, if your organization maintains its own internal set of repository mirrors, you can configure your repository to mirror ours and point your server at your mirror instead.
Verify that the firewall is not blocking access
CentOS and RHEL come with the "firewalld" firewall by default, typically allowing inbound connections only to port 22 for SSH. If firewalld is enabled on your system, and you wish to access to port 8080, you will need to either temporarily disable the firewall (if you are only testing whether things work as expected) or allow direct access to port 8080 (if another server on your network will be providing SSL termination, and this server is not publicly visible).
To disable the firewall temporarily:
To allow direct access to port 8080:
Verify that the server in question is reachable
If your server is on a private network, it may be the case that the machine you are testing from is simply unable to reach that network. You may need to move to a machine within the same network to perform your tests, or establish a temporary tunnel or bridge between the networks to cause the server to become reachable.
Verify that Tomcat is indeed running
The Apache Guacamole web application is run using Apache Tomcat. Installing Tomcat is part of the Keeper Connection Manager install procedures, and the Tomcat service must be running for the Guacamole web application installed as part of Keeper Connection Manager to become reachable. If unsure whether Tomcat is running, the easiest way to check is using systemctl:
If Tomcat is not running, it will need to be started for the web application to be accessible via port 8080. The service should also be set to automatically start on boot, such that the service will come back online after a server restart.
To start Tomcat manually:
To configure Tomcat to start automatically when the server next boots:
Verify that the web application (guacamole.war) is deployed
While we only strictly support Apache Tomcat, the packages provided by Keeper Connection Manager do not assume that you will be using Apache Tomcat. The file containing the web application, guacamole.war
, therefore must be manually deployed after Tomcat is installed. If the web application is not deployed, Tomcat will accept connections to port 8080 but will report errors when you attempt to access Guacamole.
The web application is deployed by creating a symbolic link to /opt/keeper/share/guacamole/guacamole.war
within /var/lib/tomcat/webapps
, as documented by the installation instructions. If deployed correctly, a directory listing of /var/lib/tomcat/webapps should show a symbolic link to guacamole.war
, even if the name of the link differs from the file it points to. For example, if deployed as "guacamole":
Or, if deployed to the root path:
Verify that the firewall is not blocking access
CentOS and RHEL come with the "firewalld" firewall by default, typically allowing inbound connections only to port 22 for SSH. If firewalld is enabled on your system, and you are using the same system to provide SSL termination, you will need allow direct access to the standard HTTPS port (443). To allow direct access to port 443:
Note that there is no need to expose direct access to port 8080 if the server will be serving as SSL termination for your deployment. Port 8080 would need to be available only locally, to be used strictly internally by the proxy.
Check whether SELinux is denying proxy connections to Tomcat
By default, the SELinux system will block both the Apache HTTP server and Nginx from establishing outbound network connections, including TCP connections to an internal instance of Apache Tomcat. If this is the case, you may see AVC denials within the SELinux audit logs (/var/log/audit/audit.log
), and SELinux must be configured to allow these connections by setting the httpd_can_network_connect
boolean to "1":
Verify that the reverse proxy is running
Following packaging best practices, neither the packages providing the Apache HTTP server nor the packages providing Nginx will start their corresponding services by default. They must be manually started and manually configured to start automatically on boot. If this has not been done, there will be no service listening on port 443, and connections will either timeout or be refused entirely.
To start the Apache HTTP server and configure it to start automatically on boot:
To start NGINX and configure it to start automatically on boot:
Verify that the "tomcat" user Is part of the "guacamole" group
The Keeper Connection Manager packages create a "guacamole" group for controlling access to files that should be readable only by the Apache Guacamole web application. Configuration files specific to Guacamole, like /etc/guacamole/guacamole.properties
, have their permissions set such that only root and members of the "guacamole" group have read access. As it is Apache Tomcat which runs the Guacamole web application, and the Tomcat service runs as the "tomcat" user, the "tomcat" user must be a member of the "guacamole" group:
If this is not done, Guacamole will not be able to read its own configuration files, and web application startup will fail.
Check whether SELinux is denying access to the database
By default, the SELinux system will block Apache Tomcat from establishing outbound network connections to databases, including connections to local database instances. If this is the case, you may see AVC denials within the SELinux audit logs (/var/log/audit/audit.log
), and SELinux must be configured to allow these connections by setting the tomcat_can_network_connect_db
boolean to "1":
The database initialization scripts may not have not been run
Apache Guacamole's database must be manually initialized using the SQL scripts provided. If these scripts have not been run, the tables required by Guacamole will not exist, and its attempts to query these tables will fail. If using MySQL, verify that you have indeed run the MySQL initialization scripts as documented. If using PostgreSQL, verify that you have run the PostgreSQL initialization scripts as documented, and that you did so prior to granting the required database permissions.
(If using PostgreSQL) Check whether PostgreSQL is configured to expect "Ident" authentication
If PostgreSQL has been installed locally, on the same server as Apache Guacamole, the default configuration of PostgreSQL will prevent Guacamole from authenticating with a username and password. The mechanisms used by PostgreSQL for authentication depend on the source of the database connection. By default, PostgreSQL is configured to expect "Ident" authentication rather than a username and password, which will result in Guacamole being unable to connect to PostgreSQL.
Check the contents of /var/lib/pgsql/data/pg_hba.conf
, looking for one or more lines which associate IPv4 or IPv6 loopback addresses with "Ident":
If found, the keyword ident
should be changed to md5
to allow username/password authentication from these addresses:
PostgreSQL will then need to be restarted to apply these changes:
(If using MySQL) Check whether MySQL is configured with default anonymous users
If MySQL or MariaDB are installed locally, on the same server as Apache Guacamole, the default configuration may prevent Guacamole from authenticating due to the way that MySQL and MariaDB handle authentication. If an anonymous user is defined for the same hostname/address, authentication using a non-anonymous user and password from the same hostname/address will fail.
This can be checked by querying the MySQL user table directly:
Any users with empty usernames in the results of the above query are anonymous users which may block authentication from succeeding:
Dropping those users should allow non-anonymous authentication from those same hosts to succeed:
Verify the necessary database permissions have been granted to the database user
Apache Guacamole requires SELECT
, INSERT
, UPDATE
, and DELETE
privileges on all tables within its database. For PostgreSQL, it additionally requires SELECT
and USAGE
privileges on all sequences in its database.
If using MySQL, verify that you have indeed run the GRANT
statement and FLUSH PRIVILEGES
as documented. It is important to remember that MySQL caches database privileges and will not apply changes to privileges unless FLUSH PRIVILEGES
is run.
If using PostgreSQL, verify that you have run both GRANT
statements as documented, and that you did so prior to granting the required database permissions. It is important to remember that PostgreSQL can only grant permissions related to tables and sequences that exist. If GRANT
statements are run before Guacamole's database tables exist, they will not have any effect.
Check for trailing whitespace after database-related properties
While the Java .properties files do not assign meaning to whitespace that occurs before a property value, everything after the first non-whitespace character of a property value is part of the property value, including further whitespace. If you are confident that all database-related properties within /etc/guacamole/guacamole.properties
look correct, check that you have not accidentally inserted whitespace at the end of what otherwise appears to be a correct value.
Check that your (administrative) Guacamole user account has permission to list LDAP users
Apache Guacamole's LDAP support will not bypass the permissions enforced by your LDAP directory. This means that your Guacamole user will only be able to see LDAP users within Guacamole's admin interface if your corresponding LDAP user has this permission to list these users, regardless of whether Guacamole's "search" LDAP user has permission and regardless of whether your database user has general permission to manage users.
If unsure whether your user has permission, a good way to check is to execute an LDAP query against your directory, binding using the DN and password associated with your LDAP account. The "ldapsearch" utility is a standard tool which can perform such a search:
where YOUR_LDAP_SERVER
is the hostname or IP address of your LDAP server, YOUR_LDAP_DN
is the full DN of your account within LDAP, and USER_BASE_DN
is the base DN of all relevant users within your LDAP directory (as specified with the ldap-user-base-dn
property in /etc/guacamole/guacamole.properties
).
Check that you are using LDAP credentials to sign in to Guacamole, not database credentials.
If your user account within the database has an associated password, and you specify that password instead of the password associated with your LDAP account, you will successfully authenticate against the database only. This is a valid authentication result, but means that your session will lack access to LDAP objects. To be able to access objects within LDAP, including users, you must authenticate with credentials that your LDAP directory will accept.
Check for trailing whitespace after LDAP-related properties
While the Java .properties files do not assign meaning to whitespace that occurs before a property value, everything after the first non-whitespace character of a property value is part of the property value, including further whitespace. If you are confident that all LDAP-related properties within /etc/guacamole/guacamole.properties
look correct, check that you have not accidentally inserted whitespace at the end of what otherwise appears to be a correct value. The presence of whitespace at the end of LDAP-related properties may result in queries failing and may cause Guacamole to incorrectly interpret the results of queries that appear to succeed.
Use the "Preferences" interface for changing your own password, not the administrative user editor
Apache Guacamole has two mechanisms available for changing a user's password: the user editor, for changing the passwords of other users (without having to know their current passwords), and the "Preferences" screen, for changing your own password after verifying that you know your current password. As only the "Preferences" screen verifies that you know your current password, this is the only mechanism which Guacamole will allow if you are making changes to your own user. If you attempt to change your own password using the user editor, permission will be denied. For administrators, the "Preferences" screen can be accessed by going to "Settings" and then selecting "Preferences".
Check that the user in question has permission to change their own password
User accounts defined within the Apache Guacamole database do not necessarily have permission to change their own passwords. Permission to update your own password must be explicitly granted by the administrator. If you are an administrator and you want a newly-created user to be able to change their own password, check the box next to the "Change own password" permission within the user editor.
Try explicitly specifying the security method
Recent versions of Windows require NLA (Network Level Authentication) by default, an RDP-specific security method which uses higher-grade encryption and which enforces authentication before allocating desktop session resources. If connections to your Windows RDP servers are failing, try selecting the "NLA" or "TLS" security mode within the failing connection(s) parameters. If you do not also specify the username, password, and (if applicable) domain, Guacamole will prompt you for these details upon connecting.
Similarly, older versions of Windows may not support NLA or TLS by default, and Guacamole's initial security negotiation may fail unless the older "RDP" security method is explicitly selected. In older versions of Guacamole, the "RDP" security method was the default.
Try disabling validation of the RDP server certificate
Both the NLA (Network Level Authentication) and TLS security modes involve client verification of the RDP server's certificate. In the case of most Windows servers, this certificate will be self-signed and cannot be verified. Lacking the ability to verify the certificate against a known certificate authority, Guacamole will refuse to complete the RDP connection. Individual RDP connections can be configured to bypass this verification by checking the "Ignore server certificate" option within the connection parameters.
Check whether Windows firewall rules are blocking RDP connections from guacd
The Windows firewall may be configured to block inbound RDP connections, either locally or through GPOs. If the Windows machine in question has historically been accessed using RDP, it may still be the case that RDP access is blocked for all but a specific subnet in which the Guacamole server does not reside. If this is the case, the Windows firewall should be reconfigured to allow the Guacamole server (or its subnet) to connect via RDP. The Windows server does not need to be publicly accessible.
Check that the drive path points to a directory that is writable by the "guacd" user or group
The Keeper Connection Manager packages create a "guacd" user and group for controlling access to files that should be accessible only by guacd. If you are configuring RDP drive redirection, and this user (or group) is not given write access to the directory chosen as the RDP drive path, guacd will not be able to read/write files within that directory as it emulates the redirected drive. Appropriate permissions and ownership should be assigned to any directory intended for use as an RDP connection's drive path:
When the packages are installed, the folder /var/lib/guacamole
will be created by default for each service.
The "guacd" service is run as the guacd user and the guacd user is the only user that needs read/write permission on the subfolders within the /var/lib/guacamole
subfolders, such as the "recordings" and "drives" folder.
The "guacamole" process runs as "guacamole" user, and needs read access to the "recordings" subfolder and files.
See CATALINA_OPTS
Description of the support offered for Keeper Connection Manager customers
Subscribers to Keeper Connection Manager receive continuous access to updates, released regularly according to a general release schedule, and support for each major release until it reaches end-of-life.
Additional support services are provided through the following options, depending on the specific product purchased:
Keeper Security is continuously working to improve the Keeper Connection Manager platform. Major updates of Keeper Connection Manager release once per year. Unlike updates to existing major releases, each new major version of Keeper Connection Manager may break compatibility with previous versions, and administrators will likely need to manually facilitate the upgrade from an older major release.
Each major release is a line of development which is maintained throughout its support lifecycle through issuing relatively regular updates, which users apply using the same package management tool that they used to install Keeper Connection Manager in the first place (YUM, an open source tool which is included with the Linux distributions we support).
Keeper Connection Manager provides API compatibility guarantees between minor releases. Each minor release of Keeper Connection Manager is backward compatible with prior minor releases. For example, Glyptodon Enterprise 1.1 is backward compatible with 1.0, Keeper Connection Manager (v2.8) and Glyptodon Enterprise 2.4 are backward compatible with 2.3, 2.2, etc.
Overall, this means:
Updating from one minor release to another will not require system or configuration changes. It will only involve updating the relevant packages (running yum upgrade
) and restarting Guacamole's services.
Guacamole extensions that are written for one minor release of Keeper Connection Manager will not require code changes to work with a newer minor release.
API compatibility within Keeper Connection Manager specifically covers:
The Guacamole core APIs made available to Guacamole extensions: guacamole-common, guacamole-common-js, and guacamole-ext.
The SQL schema used by Guacamole's database authentication extensions.
We will take reasonable efforts to maintain compatibility with other APIs present within the scope of the Guacamole stack, such as those inherited from external libraries or bundled dependencies, but may occasionally need to make updates that break compatibility. Examples of such libraries include (but are not limited to):
JavaScript libraries like AngularJS, jQuery, and Lodash.
Java frameworks like Jersey and Guice.
libguac, the core C library used by protocol support plugins for guacd.
Libraries that protocol support plugins for guacd may depend on, like FreeRDP, libtelnet, or libvncclient.
Each release of Keeper Connection Manager is supported for at least five years following the first general availability (GA) release. The five-year period of support for each release is further divided into the initial period of full support, during which regular updates can be expected, and the final period of extended support, during which updates are provided only for critical or security-related issues:
Following end of life (EOL), users will need to upgrade to a newer release to continue receiving updates and support. Users are advised to take advantage of the period of extended support as a grace period for migration, using the time provided to migrate to a newer release with full support, rather than allow support for a production deployment to lapse.
The date of each GA release, and the expected dates for the end of full support, end of extended support, and end of life will all be published online, but are subject to change.
If included with your purchased product, Keeper Connection Manager will provide support in the form of an online help desk, resolving issues through:
Converting support tickets to bug reports or feature requests (though priority and scheduling for bug reports and feature requests is at Keeper Connection Manager’s sole discretion).
If included with your purchased product, you may request custom branding from Keeper Connection Manager by opening a support ticket containing the details of the branding required. Keeper Connection Manager will provide a branding extension for Apache Guacamole which applies custom branding of your choosing to a deployment of Keeper Connection Manager, along with instructions for its installation. Once installed, the branding will be stable across upgrades. Custom branding may contain any or all of the following:
Your company’s name / product name
An arbitrary logo to be displayed on the login screen
An arbitrary tab / bookmark icon (“favicon”)
Disclaimer/warning text to be displayed above the login screen.
The branding extension may be revised at any time by opening a support ticket.
If included with your purchased product, Keeper Connection Manager will be available to remotely investigate and address reported issues if other means of support are insufficient to resolve the problem. After reporting the issue requiring investigation and describing what you have attempted thus far, you will need to provide Keeper Connection Manager with:
Temporary access to the system(s) in question via SSH or Apache Guacamole
Any necessary credentials
Remote intervention sessions must be scheduled in advance, and Keeper Connection Manager will make reasonable efforts to schedule remote intervention sessions in a timely manner.
If included with your purchased product, Keeper Connection Manager will be available by email and phone to consult regarding the details of your integration or deployment of Keeper Connection Manager, even if such integration/deployment is specific to your own custom software. Consultation over the phone must be scheduled in advance, and Keeper Connection Manager will make reasonable efforts to schedule any requested consultation in a timely manner.
Scope of integration and deployment consultation includes but is not limited to:
Discussing development related to custom authentication
Possible high-availability deployment configurations
Security best practices
Integrating Keeper Connection Manager within existing web applications
Troubleshooting issues within your custom integration of Keeper Connection Manager
Integration and deployment consultation does not include development services, such as the creation of custom code or documentation.
If your purchased product includes support services, the scope of those services is generally restricted to the following specific versions of software commonly used with Apache Guacamole, to the extent that the support deals directly with using Keeper Connection Manager as documented. Your purchased product may extend that support to include integration and deployment alongside your own software, even if the Keeper Connection Manager documentation does not cover that specific case.
The licenses of bundled software for installed Keeper Connection Manager packages can be found beneath the /opt/keeper/share
directory. Additionally, license information for installed packages may be queried using the "rpm
" utility, as license information is included in the metadata of all provided packages.
The packages and Docker images provided with Keeper Connection Manager contain both proprietary and open source software. In addition to Apache Guacamole, other open source software and libraries are included with Keeper Connection Manager to ensure the software is consistent and stable across all supported platforms.
Property | Description |
---|---|
Customers who deploy the Advanced Linux Install through package management are provided through Keeper Connection Manager's YUM repository (the “yum” tool will automatically apply updates when the administrator runs the command to do so).
Customers who deploy the Auto Docker Install version can use the .
Customers who deploy the Custom Docker Install version can use the .
Full Support | Extended Support | EOL |
---|
Responding to support tickets, so long as those tickets are within scope (see the ).
Tickets may be opened for issues encountered specifically with Keeper Connection Manager and for issues encountered with using a supported version of Keeper Connection Manager as documented with any of the software listed within the . Tickets are serviced for all supported releases of Keeper Connection Manager until EOL, and can be expected to be handled in a timely manner.
If included with your purchased product, Keeper Connection Manager will additionally provide support as needed over the phone, and the contact number for phone support can be found within . Phone support is available during Keeper Connection Manager’s business hours: Monday through Friday, 9:00 AM to 5:00 PM, Pacific Time.
Scope of phone support is generally limited to issues encountered specifically with Keeper Connection Manager and for issues encountered with using a supported version of Keeper Connection Manager as documented with any of the software listed within the , though your purchased product may expand this scope.
Issues encountered with software not explicitly listed in the
Browser | Description |
---|
Version | Description |
---|
OS Type | OS Version |
---|
Software | Software Version |
---|
Database | Version |
---|
Directory Type | Version |
---|
MFA Type | Version |
---|
Portions of this documentation have been derived and/or modified from the documentation distributed with , in particular the . Apache Guacamole and its User's Guide are distributed by the Apache Software Foundation under the , with the following copyright notice:
Bundled Software | License | Included in Package(s) |
---|
ban-max-invalid-attempts
The number of invalid attempts before a user is locked out
ban-address-duration
The amount of time in seconds a user is locked out for after hitting the invalid attempts limit
ban-max-addresses
The number of addresses that KCM will track to check for invalid attempts. Defaults to 10485760
Major release: | Annually (the only releases which can break compatibility). Major releases are numbered 1.0, 2.0, 3.0, etc. |
Minor/Maintenance release: | Every 3 months following general availability (updates to an existing major release which add new features, fix minor bugs, etc.). Minor/maintenance releases are numbered relative to the major release being updated: 1.1, 1.2, 1.3, etc. |
Security/Critical release: | ASAP (fixes to security vulnerabilities or critical bugs). Security/critical releases are numbered identically to minor/maintenance releases. |
Year 1-3 | Year 4-5 | Year 6+ |
Google Chrome | Any release still supported by Google |
Mozilla Firefox | Any release still supported by Mozilla |
Apple Safari: | Any release still supported by Apple |
Internet Explorer | 10, 11 |
Microsoft Edge | Any release still supported by Microsoft |
Tomcat 7.x | 7.0.37 or later release |
Tomcat 8.x | Any release |
Tomcat 9.x | Any release |
JBoss Web Server | 3.1 or later release |
CentOS | Any non-EOL release (currently 7) |
Red Hat Enterprise Linux | Any non-EOL release (currently 7 and 8) |
Rocky Linux | Any non-EOL release (currently 7 and 8) |
MySQL | Any non-EOL release AND any release packaged with a supported OS |
PostgreSQL | Any non-EOL release AND any release packaged with a supported OS |
SQL Server | Microsoft SQL Server 2008 or later, any edition |
OpenLDAP | Any actively-maintained release AND any release packaged with a supported OS |
Microsoft Active Directory | Any release still supported by Microsoft |
Duo | Web SDK |
TOTP | Any authentication device supporting the TOTP standard (such as Google Authenticator) |
NGINX | 1.3 or later release |
Apache |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Keeper Connection Manager Security Advisories
Keeper has partnered with Bugcrowd to manage our vulnerability disclosure program. Please submit reports through https://bugcrowd.com/keepersecurity or send an email to security@keepersecurity.com.
Keeper Connection Manager evaluates the factual details of each known vulnerability affecting Keeper Connection Manager and assigns severity ratings using the CVSS v3.1 scoring system, a standard owned by FIRST.Org, Inc. which FIRST has made freely available for public use. This scoring system produces a numeric rating between 0.0 and 10.0, which we then classify according to the "Qualitative Severity Rating Scale" published with the CVSS standard. The specific analysis that went into each assigned score can also be found within the document specific to the vulnerability, linked within the main table above.
Keeper Connection Manager 508 accessibility and ergonomics support
The reports in this page refer to older versions of Glyptodon before the Keeper Connection Manager branding. To remain as accurate as possible, the documentation below will refer to the product as Glyptodon when it is a version prior to 2.8.
Name of Product/Version: Glyptodon Enterprise (version 1.7)
Product Description: An HTML5 remote desktop gateway (Apache Guacamole 0.9.12-incubating with additional upstream changes/improvements backported) combined with corresponding support services and documentation.
Date: June 4, 2018
Contact Information: security@keepersecurity.com
Notes: The components covered by this report are the Apache Guacamole web application, as packaged by Glyptodon. The accessibility of the systems and/or applications within remote desktops accessed using Guacamole are inherently independent of Guacamole and will need to be considered separately.
Evaluation Methods Used: Testing is based on general product knowledge.
"Voluntary Product Accessibility Template" and "VPAT" are registered service marks of the Information Technology Industry Council (ITI). "Glyptodon" is a trademark of Glyptodon, Inc. "Apache", "Guacamole", "Apache Guacamole", and the Guacamole logo are trademarks of the Apache Software Foundation.
This report covers the degree of conformance for the following accessibility standard/guidelines:
The terms used in the Conformance Level information are defined as follows:
Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
Supports with Exceptions: Some functionality of the product does not meet the criterion.
Does Not Support: The majority of product functionality does not meet the criterion.
Not Applicable: The criterion is not relevant to the product.
Not Evaluated: The product has not been evaluated against the criterion. This can be used only in WCAG 2.0 Level AAA.
Tables 1 and 2 also document conformance with:
EN 301 549: Chapter 9 - Web, Chapter 10 - Non-Web documents, Section 11.2.1- Non-Web Software (excluding closed functionality), and Section 11.2.2 - Non-Web Software (closed functionality).
Revised Section 508: Chapter 5 – 501.1 Scope, 504.2 Content Creation or Editing, and Chapter 6 – 602.3 Electronic Support Documentation.
Note: When reporting on conformance with the WCAG 2.0 Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.0 Conformance Requirements.
Notes: This table covers the following components:
Web (Guacamole): The Apache Guacamole web application, as packaged within Glyptodon Enterprise.
Web (Docs): The Glyptodon Enterprise documentation hosted at https://enterprise.glyptodon.org/doc/ covering use of Glyptodon Enterprise and/or the version of Apache Guacamole packaged with Glyptodon Enterprise.
Notes: This table covers the following components:
Web (Guacamole): The Apache Guacamole web application, as packaged within Glyptodon Enterprise.
Web (Docs): The Glyptodon Enterprise documentation hosted at https://enterprise.glyptodon.org/doc/ covering use of Glyptodon Enterprise and/or the version of Apache Guacamole packaged with Glyptodon Enterprise.
Web (Account): The web interface provided to subscribers to retrieve Glyptodon Enterprise repository credentials, to make changes to payment information and the subscription, and to obtain support (https://enterprise.glyptodon.org/account/).
Notes: This table covers the following components:
Web (Guacamole): The Apache Guacamole web application, as packaged within Glyptodon Enterprise.
Web (Docs): The Glyptodon Enterprise documentation hosted at https://enterprise.glyptodon.org/doc/ covering use of Glyptodon Enterprise and/or the version of Apache Guacamole packaged with Glyptodon Enterprise.
Web (Account): The web interface provided to subscribers to retrieve Glyptodon Enterprise repository credentials, to make changes to payment information and the subscription, and to obtain support (https://enterprise.glyptodon.org/account/).
Notes: Not Applicable
Notes: This table is specific to the documentation and support services provided as part of Glyptodon Enterprise. It does not apply to Apache Guacamole.
Notes: Not Applicable. Guacamole and Glyptodon Enterprise do not provide two-way voice communication.
Notes: Not Applicable. Guacamole and Glyptodon Enterprise are purely software/services. No hardware is provided.
Notes: See information in the WCAG 2.0 section.
Notes: Not Applicable. All documentation provided via Glyptodon Enterprise is web-based.
Notes: Chapter 11 deals with software not already covered by Chapter 9. All components covered by this document are covered by Chapter 9. See information in the WCAG 2.0 section.
Notes: Not Applicable. Relay / emergency service access is not provided by Guacamole or Glyptodon Enterprise.
2.4.5 or later release, with installed
("node-process")
("node-util")
Severity (CVSS v3.1 score) | CVE ID | Description | Fixed in Keeper Connection Manager (or legacy Glyptodon) Release |
---|---|---|---|
Severity | CVSS score range |
---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Criteria | Conformance Level | Remarks and Explanations |
---|---|---|
Low (1.8)
CVE-2020-9497
Improper input validation of RDP static virtual channels
1.13, 2.1
Medium (5.9)
CVE-2020-9498
Dangling pointer in RDP static virtual channel handling
1.13, 2.1
Medium (4.1)
CVE-2020-11997
Inconsistent restriction of connection history visibility
1.14, 2.2
Medium (4.4)
CVE-2021-41767
Private tunnel identifier may be included in the non-private details of active connections
1.16, 2.6
High (8.7)
CVE-2021-43999
Improper validation of SAML responses
2.7
None
0.0
Low
0.1 - 3.9
Medium
4.0 - 6.9
High
7.0 - 8.9
Critical
9.0 - 10.0
Standard/Guideline
Included In Report
Web Content Accessibility Guidelines 2.0, at http://www.w3.org/TR/2008/REC-WCAG20-20081211/
Level A - Yes
Level AA - Yes
Level AAA - Yes
Revised Section 508 standards as published by the U.S. Access Board in the Federal Register on January 18, 2017
Corrections to the ICT Final Rule as published by the US Access Board in the Federal Register on January 22, 2018
Yes
EN 301 549 Accessibility requirements suitable for public procurement of ICT products and services in Europe, - V1.1.2 (2015-04)
Yes
1.1.1 Non-text Content (Level A)
Also applies to:
EN 301 549 Criteria
9.2.1 (Web)
10.2.1 (non-web document)
11.2.1.1 (Software)
11.2.2.1 (Closed Functionality Software)
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports with Exceptions
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): The expand/collapse (+/-) icon for connection groups does not have alternative text. All other images within Guacamole either have alternative text or are purely decorative.
Web (Docs): All non-text content within the documentation has alternative text or is purely decorative.
Web (Account): All non-text content within the account management / download interface provided to Glyptodon Enterprise subscribers has alternative text or is purely decorative.
1.2.1 Audio-only and Video-only (Prerecorded) (Level A)
Also applies to:
EN 301 549 Criteria
9.2.2 (Web)
10.2.2 (non-web document)
11.2.1.1 (Software)
11.2.2.2.1 and 11.2.2.2.2 (Closed Software)
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Not Applicable
Web (Docs): Supports
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain prerecorded content of any kind.
Web (Docs): The only prerecorded content within the Glyptodon Enterprise documentation are videos, which are provided as an alternative to the text documentation and are labeled as such.
Web (Account): There is no prerecorded content within the account management / download interface provided to Glyptodon Enterprise subscribers.
1.2.2 Captions (Prerecorded) (Level A)
Also applies to:
EN 301 549 Criteria
9.2.3 (Web)
10.2.3 (non-web document)
11.2.1.3 (Software)
11.2.2.3 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Not Applicable
Web (Docs): Supports
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain prerecorded content of any kind.
Web (Docs): The only prerecorded content within the Glyptodon Enterprise documentation are videos, and all such videos include captions.
Web (Account): There is no prerecorded content within the account management / download interface provided to Glyptodon Enterprise subscribers.
1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)
Also applies to:
EN 301 549 Criteria
9.2.4 (Web)
10.2.4 (non-web document)
11.2.1.4 (Software)
11.2.2.4 (Closed Software)
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Not Applicable
Web (Docs): Supports
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain prerecorded content of any kind.
Web (Docs): The only prerecorded content within the Glyptodon Enterprise documentation are videos, which are provided as an alternative to the text documentation and are labeled as such.
Web (Account): There is no prerecorded content within the account management / download interface provided to Glyptodon Enterprise subscribers.
1.3.1 Info and Relationships (Level A)
Also applies to:
EN 301 549 Criteria
9.2.7 (Web)
10.2.7 (non-web document)
11.2.1.7 (Software)
11.2.2.7 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): The relationships between presentation elements within Guacamole are always conveyed with corresponding text and semantic markup.
Web (Docs): The relationships between presentation elements within the Glyptodon Enterprise documentation are always conveyed with corresponding text and semantic markup.
Web (Account): The relationships between presentation elements within the Glyptodon Enterprise account / download interface are always conveyed with corresponding text and semantic markup.
1.3.2 Meaningful Sequence (Level A)
Also applies to:
EN 301 549 Criteria
9.2.8 (Web)
10.2.8 (non-web document)
11.2.1.8 (Software)
11.2.2.8 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Content which is related semantically is organized with appropriate header elements and/or nested structurally. Guacamole does not depend on nor assume any particular reading direction (RTL vs. LTR).
Web (Docs): The visual presentation of sections of the Glyptodon Enterprise documentation always exactly matches the programmatically determined order, with the exception of elements which do not affect the meaning of other elements (such as the navigation panel).
Web (Account): Where order has an effect on meaning, the visual presentation of sections of the Glyptodon Enterprise account / download interface always exactly matches the programmatically determined order.
1.3.3 Sensory Characteristics (Level A)
Also applies to:
EN 301 549 Criteria
9.2.9 (Web)
10.2.9 (non-web document)
11.2.1.9 (Software)
11.2.2.9 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports with Exceptions
Web (Docs): Supports with Exceptions
Web (Account): Supports
Web (Guacamole): The expand/collapse (+/-) icon for connection groups does not have alternative text. All other images within Guacamole either have alternative text or are purely decorative.
Web (Docs): The expand/collapse icon within the navigation panel does not have alternative text, however this icon is not necessary to expand/collapse groups within the panel, nor to determine whether a group is expanded. All other graphical elements within the Glyptodon Enterprise documentation either have alternative text or are purely decorative.
Web (Account): All images within the Glyptodon Enterprise account / download interface have alternative text or are purely decorative.
1.4.1 Use of Color (Level A)
Also applies to:
EN 301 549 Criteria
9.2.10 (Web)
10.2.10 (non-web document)
11.2.1.10 (Software)
11.2.2.10 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): All information conveyed with color is additionally conveyed with text.
Web (Docs): All information conveyed with color is additionally conveyed with text.
Web (Account): All information conveyed with color is additionally conveyed with text.
1.4.2 Audio Control (Level A)
Also applies to:
EN 301 549 Criteria
9.2.11 (Web)
10.2.11 (non-web document)
11.2.1.11 (Software)
11.2.2.11 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): The web application does not inherently provide audio controls, however the operating system of the remote desktop being accessed through Guacamole should provide such controls.
Web (Docs): There is no automatically playing content within the Glyptodon Enterprise documentation.
Web (Account): There is no automatically playing content within the Glyptodon Enterprise account / download interface.
2.1.1 Keyboard (Level A)
Also applies to:
EN 301 549 Criteria
9.2.15 (Web)
10.2.15 (non-web document)
11.2.1.15 (Software)
11.2.2.15 (Closed Software)
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): Not all elements of the Guacamole interface can be accessed/focused using the "Tab" key.
Web (Docs): Within the Glyptodon Enterprise documentation, absolutely all links and elements capable of receiving keyboard focus can be accessed/focused using the "Tab" key.
Web (Account): While most elements within the Glyptodon Enterprise account / download interface can be accessed/focused using the "Tab" key, the account menu cannot. Accessing this menu is necessary to log out. Additionally, some user interface components do not fully support keyboard interaction, such as drop down menus within account information edit screens.
2.1.2 No Keyboard Trap (Level A)
Also applies to:
EN 301 549 Criteria
9.2.16 (Web)
10.2.16 (non-web document)
11.2.1.16 (Software)
11.2.2.16 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): To the extent allowed by the browser, Guacamole does take control of all keystrokes while a connection is in use, however users may manually return focus to the browser by pressing Ctrl+Alt+Shift to open the Guacamole menu.
Web (Docs): Nothing within the Glyptodon Enterprise documentation takes control of the keyboard in any way.
Web (Account): Nothing within the Glyptodon Enterprise account / download interfaces takes control of the keyboard in any way.
2.2.1 Timing Adjustable (Level A)
Also applies to:
EN 301 549 Criteria
9.2.17 (Web)
10.2.17 (non-web document)
11.2.1.17 (Software)
11.2.2.17 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Does Not Support
Web (Docs): Not Applicable
Web (Account): Supports
Web (Guacamole): Session time limits are set by the system administrator and cannot be adjusted by users. By default, users will be automatically logged out after one hour of inactivity. Guacamole considers being connected to at least one connection to be activity, even if the user is not actively interacting with that connection.
Web (Docs): The Glyptodon Enterprise documentation is always available. No authentication is required to access the documentation and there are no time limits.
Web (Account): Users can elect to remain logged in to the Glyptodon Enterprise account / download interface by checking the "Remember me" box during login.
2.2.2 Pause, Stop, Hide (Level A)
Also applies to:
EN 301 549 Criteria
9.2.18 (Web)
10.2.18 (non-web document)
11.2.1.18 (Software)
11.2.2.18 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Not Applicable
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): The only moving/blinking/scrolling/auto-updating content within Guacamole is the remote desktop connection that a user is actively using. In such a case, the moving/blinking/scrolling/auto-updating is not only essential to the activity, it is the activity.
Web (Docs): The only moving/blinking/scrolling/auto-updating content within the Glyptodon Enterprise documentation are videos accompanying the text, and those videos do not automatically start.
Web (Account): There is no moving/blinking/scrolling/auto-updating content within the Glyptodon Enterprise account / download interface.
2.3.1 Three Flashes or Below Threshold (Level A)
Also applies to:
EN 301 549 Criteria
9.2.19 (Web)
10.2.19 (non-web document)
11.2.1.19 (Software)
11.2.2.19 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Guacamole’s interface does not contain anything that flashes.
Web (Docs): The Glyptodon Enterprise documentation does not contain anything that flashes.
Web (Account): The Glyptodon Enterprise account / download interface does not contain anything that flashes.
2.4.1 Bypass Blocks (Level A)
Also applies to:
EN 301 549 Criteria
9.2.20 (Web)
10.2.20 (non-web document) – Does not apply
11.2.1.20 (Software) – Does not apply
11.2.2.20 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software) – Does not apply to non-web software
504.2 (Authoring Tool)
602.3 (Support Docs) – Does not apply to non-web docs
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Content is not repeated. In cases where a page contains multiple content areas, those areas have proper heading elements.
Web (Docs): The only repeated content within the Glyptodon Enterprise documentation is the navigation panel, which is properly identified with ARIA landmark roles. The main content section is also identified with an ARIA landmark role, and all sections within the content are identified with heading elements.
Web (Account): The only repeated content within the Glyptodon Enterprise account / download interface is the navigation menu, which is properly identified with semantic markup. All sections within the main content are identified with heading elements.
2.4.2 Page Titled (Level A)
Also applies to:
EN 301 549 Criteria
9.2.21 (Web)
10.2.21 (non-web document)
11.2.1.21 (Software) - Does not apply
11.2.2.21 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): For most pages, the name of the web application (Apache Guacamole) is used as the title without context. When accessing a connection, the name of the connection is used as the title.
Web (Docs): Each page within the Glyptodon Enterprise documentation has a title element containing the unique title of the page.
Web (Account): All pages within the Glyptodon Enterprise account / download interface are titled: "My Account - Glyptodon Enterprise".
2.4.3 Focus Order (Level A)
Also applies to:
EN 301 549 Criteria
9.2.22 (Web)
10.2.22 (non-web document)
11.2.1.22 (Software)
11.2.2.22 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): Not all elements of the Guacamole interface can be accessed/focused using the "Tab" key.
Web (Docs): All elements within the Glyptodon Enterprise documentation that are capable of receiving focus can be accessed/focused in sequence using the "Tab" key.
Web (Account): While most elements within the Glyptodon Enterprise account / download interface can be accessed/focused using the "Tab" key, the account menu cannot. Accessing this menu is necessary to log out.
2.4.4 Link Purpose (In Context) (Level A)
Also applies to:
EN 301 549 Criteria
9.2.23 (Web)
10.2.23 (non-web document)
11.2.1.23 (Software)
11.2.2.23 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): All links have context and descriptive text.
Web (Docs): All links have context and descriptive text. Navigation links additionally have programmatically-determinable context through use of semantic elements and ARIA landmark roles.
Web (Account): All links have context and descriptive text. Navigation links additionally have programmatically-determinable context through use of semantic elements.
3.1.1 Language of Page (Level A)
Also applies to:
EN 301 549 Criteria
9.2.27 (Web)
10.2.27 (non-web document)
11.2.1.27 (Software)
11.2.2.27 (Closed Software)
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): The language of each page is not exposed such that it can be programmatically determined.
Web (Docs): The language of each page is exposed using the "lang" attribute on the top-level "html" element.
Web (Account): The language of each page is exposed using the "lang" attribute on the top-level "html" element.
3.2.1 On Focus (Level A)
Also applies to:
EN 301 549 Criteria
9.2.29 (Web)
10.2.29 (non-web document)
11.2.1.29 (Software)
11.2.2.29 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Simply receiving focus will not result in a change of context.
Web (Docs): Simply receiving focus will not result in a change of context.
Web (Account): Simply receiving focus will not result in a change of context.
3.2.2 On Input (Level A)
Also applies to:
EN 301 549 Criteria
9.2.30 (Web)
10.2.30 (non-web document)
11.2.1.30 (Software)
11.2.2.30 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports with Exceptions
Web (Docs): Supports with Exceptions
Web (Account): Supports
Web (Guacamole): Changing the display language or changing any setting within the Guacamole menu will take immediate effect. All other changes must be explicitly submitted to take effect.
Web (Docs): Changing the selected documentation version will immediately reload the page, replacing the current documentation with the version chosen (if available). The only other aspect of the interface which may receive input, the search box, must be manually submitted to have any effect.
Web (Account): Under no circumstances will user input have any effect unless explicitly submitted.
3.3.1 Error Identification (Level A)
Also applies to:
EN 301 549 Criteria
9.2.33 (Web)
10.2.33 (non-web document)
11.2.1.33 (Software)
11.2.2.33 (Closed Software)
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): If a user submits invalid information, an error message is displayed describing the problem.
Web (Docs): In the event of an error, such as navigating to a non-existent page, an error page is displayed describing the problem.
Web (Account): In the event of an error due to invalid data, an error message is displayed describing the problem.
3.3.2 Labels or Instructions (Level A)
Also applies to:
EN 301 549 Criteria
9.2.34 (Web)
10.2.34 (non-web document)
11.2.1.34 (Software)
11.2.2.34 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Labels and/or instructions are provided for absolutely all cases where user input is required.
Web (Docs): Labels are provided for absolutely all cases where user input is required.
Web (Account): Labels are provided for absolutely all cases where user input is required.
4.1.1 Parsing (Level A)
Also applies to:
EN 301 549 Criteria
9.2.37 (Web)
10.2.37 (non-web document)
11.2.1.37 (Software)
11.2.2.37 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): All markup (HTML) within Guacamole is valid, having complete and matching start/end tags for all elements, with elements nested as specified by relevant standards.
Web (Docs): All markup (HTML) within the Glyptodon Enterprise documentation is valid, having complete and matching start/end tags for all elements, with elements nested as specified by relevant standards.
Web (Account): All markup (HTML) within the Glyptodon Enterprise account / download interface is valid, having complete and matching start/end tags for all elements, with elements nested as specified by relevant standards.
4.1.2 Name, Role, Value (Level A)
Also applies to:
EN 301 549 Criteria
9.2.38 (Web)
10.2.38 (non-web document)
11.2.1.38 (Software)
11.2.2.38 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Only standard HTML controls are used.
Web (Docs): Only standard HTML controls are used.
Web (Account): With the exception of drop down menus within account edit screens, only standard HTML controls are used. The non-standard drop down menus are backed by standard HTML controls and function correctly if programmatically modified.
1.2.4 Captions (Live) (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.5 (Web)
10.2.5 (non-web document)
11.2.1.5 (Software)
11.2.2.5 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Not Applicable
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): Providing captions is not relevant to the functionality of the web application. If users require captions from specific software or videos within the remote desktop, such responsibility would fall on those programs.
Web (Docs): There is no live content within the Glyptodon Enterprise documentation.
Web (Account): There is no live content within the Glyptodon Enterprise account / download interface.
1.2.5 Audio Description (Prerecorded) (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.6 (Web)
10.2.6 (non-web document)
11.2.1.6 (Software)
11.2.2.6 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Not Applicable
Web (Docs): Does Not Support
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain any prerecorded content.
Web (Docs): While included videos are narrated, the narration is not sufficient to capture all important visual details within the video.
Web (Account): The Glyptodon Enterprise account / download interface does not contain any prerecorded content.
1.4.3 Contrast (Minimum) (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.12 (Web)
10.2.12 (non-web document)
11.2.1.12 (Software)
11.2.2.12 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports with Exceptions
Web (Account): Does Not Support
Web (Guacamole): All text is black over white background, where contrast ratio is 21:1.
Web (Docs): With the exception of the "GO" button in the search box, all text has a contrast ratio of at least 4.5:1.
Web (Account): While most text is dark gray over white background with a contrast ratio of 7.94:1, links are teal over white background with a contrast ratio below 4.5:1. Buttons and some callouts are also similarly low-contrast.
1.4.4 Resize text (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.13 (Web)
10.2.13 (non-web document)
11.2.1.13 (Software)
11.2.2.13 (Closed Software)
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports with Exceptions
Web (Account): Supports
Web (Guacamole): The content of the web application may be resized to at least 200% via the built-in zoom function of the web browser without loss of functionality or content. Additionally, any active remote desktop connection may be magnified to at least 200% using the zoom function within the "Display" section of the Guacamole menu.
Web (Docs): All text within the Glyptodon Enterprise documentation may be resized to at least 200% via the built-in zoom function of the web browser without loss of functionality or content. The navigation panel may be hidden, depending on whether sufficient space remains to display the panel.
Web (Account): All text within the Glyptodon Enterprise account / download interface may be resized to at least 200% via the built-in zoom function of the web browser without loss of functionality or content.
1.4.5 Images of Text (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.14 (Web)
10.2.14 (non-web document)
11.2.1.14 (Software)
11.2.2.14 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Images of text are never used to convey information.
Web (Docs): Images of text are never used to convey information.
Web (Account): Images of text are never used to convey information.
2.4.5 Multiple Ways (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.24 (Web)
10.2.24 (non-web document) – Does not apply
11.2.1.24 (Software) – Does not apply
11.2.2.24 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software) – Does not apply to non-web software
504.2 (Authoring Tool)
602.3 (Support Docs) – Does not apply to non-web docs
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): Navigating between pages within Guacamole always involves navigation bars / menus / hierarchical lists, and there is generally only one way to navigate to a particular page in each instance.
Web (Docs): In addition to a navigation panel, the Glyptodon Enterprise documentation provides a search mechanism, links which move through the documentation sequentially, breadcrumbs, and general links between pages.
Web (Account): Navigating between pages within the Glyptodon Enterprise account / download interface always involves a common navigation bar.
2.4.6 Headings and Labels (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.25 (Web)
10.2.25 (non-web document)
11.2.1.25 (Software)
11.2.2.25 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports with Exceptions
Web (Guacamole): Descriptive headings and labels are used throughout the Guacamole interface.
Web (Docs): Descriptive headings are used throughout the Glyptodon Enterprise documentation. Descriptive labels are used in the few cases where user input is applicable (the search box / navigation panel).
Web (Account): Descriptive headings and labels are used throughout the Glyptodon Enterprise account / download interface, however some required fields on edit screens are marked as required using an asterisk ("*"), with no other programmatically-readable text indicating the field is required.
l2.4.7 Focus Visible (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.26 (Web)
10.2.26 (non-web document)
11.2.1.26 (Software)
11.2.2.26 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Guacamole does not override browser-default focus indicators.
Web (Docs): While the Glyptodon Enterprise documentation does include some styling which is conditional depending on focus, this is not done to such a degree that the browser-default focus indicators are absent.
Web (Account): The Glyptodon Enterprise account / download interface does not override browser-default focus indicators.
3.1.2 Language of Parts (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.28 (Web)
10.2.28 (non-web document)
11.2.1.28 (Software) – Does not apply
11.2.2.28 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): The language of the parts of each page is not exposed such that it can be programmatically determined.
Web (Docs): Only a single language is used on all pages, and that language can be programmatically determined.
Web (Account): Only a single language is used on all pages, and that language can be programmatically determined.
3.2.3 Consistent Navigation (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.31 (Web)
10.2.31 (non-web document) – Does not apply
11.2.1.31 (Software) – Does not apply
11.2.2.31 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software) – Does not apply to non-web software
504.2 (Authoring Tool)
602.3 (Support Docs) – Does not apply to non-web docs
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): The only repeated navigational mechanism within Guacamole is the user menu, the order and contents of which are consistent in all cases.
Web (Docs): The navigation panel, common to all pages within the Glyptodon Enterprise documentation, is consistently ordered. Breadcrumb links, also common to all pages, consistently contain the parent page(s) of the current page in increasing order or depth.
Web (Account): The navigation menu, common to all pages within the Glyptodon Enterprise account / download interface, consistently contains the same links in the same order.
3.2.4 Consistent Identification (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.32 (Web)
10.2.32 (non-web document) – Does not apply
11.2.1.32 (Software) – Does not apply
11.2.2.32 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software) – Does not apply to non-web software
504.2 (Authoring Tool)
602.3 (Support Docs) – Does not apply to non-web docs
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Components of the web application which appear repeatedly are consistently labeled and styled.
Web (Docs): Common/repeated content within the Glyptodon Enterprise documentation is consistently labeled and styled. If such content is non-text and is not purely decorative, consistent text alternatives for the content are always provided.
Web (Account): Common/repeated content within the Glyptodon Enterprise account / download interface is consistently labeled.
3.3.3 Error Suggestion (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.35 (Web)
10.2.35 (non-web document)
11.2.1.35 (Software)
11.2.2.35 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): Automatic guidance for correcting errors in user input is generally not provided. Only an explicit, descriptive error is displayed.
Web (Docs): If an error occurs while accessing the documentation, such as if a user visits a page that does not exist, guidance is provided which advises the user of possible steps to take to correct the problem.
Web (Account): Automatic guidance for correcting errors in user input is generally not provided. Only an explicit, descriptive error is displayed.
3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)
Also applies to:
EN 301 549 Criteria
9.2.36 (Web)
10.2.36 (non-web document)
11.2.1.36 (Software)
11.2.2.36 (Closed Software) – Does not apply
11.6.2 (Authoring Tool)
12.1.2 (Product Docs)
12.2.4 (Support Docs)
2017 Section 508
501 (Web)(Software)
504.2 (Authoring Tool)
602.3 (Support Docs)
Web (Guacamole): Supports with Exceptions
Web (Docs): Not Applicable
Web (Account): Supports
Web (Guacamole): Destructive administrative tasks are explicitly confirmed before being allowed to take place. Modifications to connection configurations are applied immediately (without confirmation) if there are no errors preventing modification, however user input checking is not feasible given the broad, generic nature of connection parameters (virtually any value is conceivably valid).
Web (Docs): The Glyptodon Enterprise documentation does not allow the user to make changes to data, perform transactions, etc. It is purely a read-only, searchable documentation system.
Web (Account): User input checking is performed in all cases where data modification is allowed.
Criteria
Conformance Level
Remarks and Explanations
1.2.6 Sign Language (Prerecorded) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Not Applicable
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain any prerecorded content.
Web (Docs): The only prerecorded content within the Glyptodon Enterprise documentation are videos, which are provided as an alternative to the text documentation and are labeled as such.
Web (Account): The Glyptodon Enterprise account / download interface does not contain any prerecorded content.
1.2.7 Extended Audio Description (Prerecorded) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Not Applicable
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain any prerecorded content.
Web (Docs): The only prerecorded content within the Glyptodon Enterprise documentation are videos, which are provided as an alternative to the text documentation and are labeled as such.
Web (Account): The Glyptodon Enterprise account / download interface does not contain any prerecorded content.
1.2.8 Media Alternative (Prerecorded) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Not Applicable
Web (Docs): Supports
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain any prerecorded content.
Web (Docs): Videos are included within the Glyptodon Enterprise documentation only when they are accompanied by full, equivalent text. Such videos are the only prerecorded content within the Glyptodon Enterprise documentation.
Web (Account): The Glyptodon Enterprise account / download interface does not contain any prerecorded content.
1.2.9 Audio-only (Live) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Not Applicable
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain any live, audio-only content.
Web (Docs): The Glyptodon Enterprise documentation does not contain any live, audio-only content.
Web (Account): The Glyptodon Enterprise account / download interface does not contain any live, audio-only content.
1.4.6 Contrast Enhanced (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): The contrast ratio of text within the Guacamole interface is 21:1 (black text on white background).
Web (Docs): The contrast ratio of all text within the Glyptodon Enterprise documentation varies, but is always at least 7:1.
Web (Account): While most text is dark gray over white background with a contrast ratio of 7.94:1, links are teal over white background with a contrast ratio below 4.5:1. Some callouts are also similarly low-contrast.
1.4.7 Low or No Background Audio (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Not Applicable
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): Guacamole does not contain any prerecorded content.
Web (Docs): The Glyptodon Enterprise documentation does not contain any prerecorded, audio-only content.
Web (Account): The Glyptodon Enterprise account / download interface does not contain any prerecorded, audio-only content.
1.4.8 Visual Presentation (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Does Not Support
Web (Account): Does Not Support
Web (Guacamole): Foreground and background color for main content is explicitly specified via CSS.
Web (Docs): Foreground and background color for main content is explicitly specified via CSS.
Web (Account): Foreground and background color for main content is explicitly specified via CSS.
1.4.9 Images of Text (No Exception) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Images of text are never used to convey information.
Web (Docs): Images of text are never used to convey information. Screenshots may be used, and these screenshots may contain text, however such images are explicitly excluded from this criteria.
Web (Account): Images of text are never used to convey information.
2.1.3 Keyboard (No Exception) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): Not all elements of the Guacamole interface can be accessed/focused using the “Tab” key.
Web (Docs): Within the Glyptodon Enterprise documentation, absolutely all links and elements capable of receiving keyboard focus can be accessed/focused using the "Tab" key.
Web (Account): While most elements within the Glyptodon Enterprise account / download interface can be accessed/focused using the "Tab" key, the account menu cannot. Accessing this menu is necessary to log out. Additionally, some user interface components do not fully support keyboard interaction, such as drop down menus within account information edit screens.
2.2.3 No Timing (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Supports
Web (Account): Does Not Support
Web (Guacamole): Session time limits are set by the system administrator and cannot be adjusted by users. By default, users will be automatically logged out after one hour of inactivity. Guacamole considers being connected to at least one connection to be activity, even if the user is not actively interacting with that connection.
Web (Docs): The Glyptodon Enterprise documentation is always available. No authentication is required to access the documentation and there are no time limits.
Web (Account): A time limit applies to user sessions within the Glyptodon Enterprise account / download interface unless explicitly disabled by the user during login.
2.2.4 Interruptions (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Not Applicable
Web (Account): Not Applicable
Web (Guacamole): Alerts are used only to communicate critical errors or changes in connection status.
Web (Docs): The Glyptodon Enterprise documentation does not use alerts/interruptions of any kind.
Web (Account): The Glyptodon Enterprise account / download interface does not use alerts/interruptions of any kind.
2.2.5 Re-authenticating (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Not Applicable
Web (Account): Does Not Support
Web (Guacamole): State is lost upon session expiration.
Web (Docs): The Glyptodon Enterprise documentation is always available. No authentication is required to access the documentation and there are no time limits.
Web (Account): State is lost upon session expiration.
2.3.2 Three Flashes (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Guacamole’s interface does not contain anything that flashes.
Web (Docs): The Glyptodon Enterprise documentation does not contain anything that flashes.
Web (Account): The Glyptodon Enterprise account / download interface does not contain anything that flashes.
2.4.8 Location (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Pages within Guacamole are generally no more than one level deep. A link to the top-level page is always provided.
Web (Docs): The user's location within the documentation is indicated through both the navigation panel and breadcrumb links.
Web (Account): The user's location within the Glyptodon Enterprise account / download interface is indicated through style changes to the links within the navigation menu (the current page is highlighted).
2.4.9 Link Purpose (Link Only) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Link text is always descriptive.
Web (Docs): Link text is always descriptive.
Web (Account): Link text is always descriptive.
2.4.10 Section Headings (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Section headings are used throughout the Guacamole interface, wherever distinct sections exist.
Web (Docs): Section headings are consistently used within the Glyptodon Enterprise documentation to organize content by topic, subtopic, etc.
Web (Account): Where distinct sections exist, section headings are always used to organize the content.
3.1.3 Unusual Words (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Does Not Support
Web (Account): Does Not Support
Web (Guacamole): Technical terms specific to remote desktop or Guacamole administration are not independently defined and do not link to definitions.
Web (Docs): While the documentation is intended to be explanatory, many technical terms are not independently defined and do not link to definitions.
Web (Account): Any technical terms present are not independently defined and do not link to definitions.
3.1.4 Abbreviations (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Does Not Support
Web (Account): Does Not Support
Web (Guacamole): Abbreviations are not used within the Guacamole interface, with the exception of protocol names (VNC, RDP, SSH), which are not independently defined and do not link to definitions.
Web (Docs): Abbreviations are generally not independently defined and do not link to definitions.
Web (Account): Abbreviations are generally not independently defined and do not link to definitions.
3.1.5 Reading Level (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Does Not Support
Web (Account): Does Not Support
Web (Guacamole): No supplemental text at different reading levels is provided for any text within Guacamole.
Web (Docs): No supplemental text at different reading levels is provided for any text within the Glyptodon Enterprise documentation, which may be highly technical.
Web (Account): No supplemental text at different reading levels is provided for any text within the Glyptodon Enterprise account / download interface.
3.1.6 Pronunciation (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Does Not Support
Web (Account): Does Not Support
Web (Guacamole): No mechanism is provided to disambiguate words that differ in meaning solely by pronunciation.
Web (Docs): No mechanism is provided to disambiguate words that differ in meaning solely by pronunciation.
Web (Account): No mechanism is provided to disambiguate words that differ in meaning solely by pronunciation.
3.2.5 Change on Request (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Changes of context occur only when initiated by user request.
Web (Docs): Changes of context occur only when initiated by user request.
Web (Account): Changes of context occur only when initiated by user request.
3.3.5 Help (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Does Not Support
Web (Docs): Does Not Support
Web (Account): Does Not Support
Web (Guacamole): With the exception of brief instructional paragraphs, no contextual help is provided.
Web (Docs): The interface of the Glyptodon Enterprise documentation does not include contextual help.
Web (Account): The Glyptodon Enterprise account / download interface does not include contextual help.
3.3.6 Error Prevention (All) (Level AAA)
Also applies to:
EN 301 549 Criteria – Does not apply
2017 Section 508 – Does not apply
Web (Guacamole): Supports with Exceptions
Web (Docs): Supports
Web (Account): Supports
Web (Guacamole): Destructive administrative tasks are explicitly confirmed before being allowed to take place. Modifications to connection configurations are applied immediately (without confirmation) if there are no errors preventing modification.
Web (Docs): If a user submits invalid data when attempting to perform a search, the user is given the opportunity to correct their search terms.
Web (Account): Destructive administrative tasks are explicitly confirmed before being allowed to take place. Error checking is performed on input fields prior to accepting the user's submission.
302.1 Without Vision
Supports
No mode of operation requires vision, as text is always provided in a programmatically-readable form.
302.2 With Limited Vision
Supports with Exceptions
No mode of operation requires vision, as text is always provided in a programmatically-readable form. Guacamole and the Glyptodon Enterprise documentation additionally use high-contrast text. The Glyptodon Enterprise account / download interface contains some components with text that is relatively low-contrast.
302.3 Without Perception of Color
Supports
Color is never used as the sole means of indicating meaning. Text is always included which unambiguously describes the meaning of the content even if color is absent.
302.4 Without Hearing
Supports
Use of Guacamole and/or Glyptodon Enterprise does not depend on hearing.
302.5 With Limited Hearing
Supports
Use of Guacamole and/or Glyptodon Enterprise does not depend on hearing.
302.6 Without Speech
Supports
Use of Guacamole and/or Glyptodon Enterprise does not depend on speech.
302.7 With Limited Manipulation
Supports with Exceptions
Opening the Guacamole menu requires pressing three keys simultaneously (Ctrl+Alt+Shift). Some parts of the Guacamole interface are not reachable through keyboard interaction alone, and thus may require mouse interaction. Logging out from the Glyptodon Enterprise account / download interface requires opening a menu which can only be reached using the mouse.
302.8 With Limited Reach and Strength
Supports
Guacamole and/or Glyptodon Enterprise do not impose reach or strength requirements.
302.9 With Limited Language, Cognitive, and Learning Abilities
Does Not Support
The text within Guacamole and Glyptodon Enterprise contains technical jargon that is not defined and does not link to corresponding definitions.
501.1 Scope – Incorporation of WCAG 2.0 AA
See WCAG 2.0 section
See information in the WCAG 2.0 section.
502 Interoperability with Assistive Technology
Not Applicable
All components covered by this conformance report are web applications/services to which 502 and 503 do not apply, as no such component has access to platform accessibility services. From the text of Section 508:
EXCEPTION: Where Web applications do not have access to platform accessibility services and do not include components that have access to platform accessibility services, they shall not be required to conform to 502 or 503 provided that they conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).
503 Applications
Not Applicable
504 Authoring Tools
Not Applicable
No part of Guacamole or Glyptodon Enterprise constitutes an authoring tool.
601.1 Scope
Heading cell – no response required
Heading cell – no response required
602 Support Documentation
Heading cell – no response required
Heading cell – no response required
602.2 Accessibility and Compatibility Features
Does Not Support
Specific documentation is not provided on the usage of Guacamole or Glyptodon Enterprise with accessibility technologies.
602.3 Electronic Support Documentation
See WCAG 2.0 section
See information in the WCAG 2.0 section.
602.4 Alternate Formats for Non-Electronic Support Documentation
Not Applicable
All support documentation is provided in an electronic format.
603 Support Services
Heading cell – no response required
Heading cell – no response required
603.2 Information on Accessibility and Compatibility Features
Supports
For Glyptodon Enterprise subscriptions which include support services, those services include at least all documented features within scope. This report is part of that documentation.
603.3 Accommodation of Communication Needs
Supports
For Glyptodon Enterprise subscriptions which include support services, those services are provided at a minimum through email and/or a text-based support desk. The support desk has been verified as accessible against WCAG 2.0.
4.2.1 Usage without vision
Supports
No mode of operation requires vision, as text is always provided in a programmatically-readable form.
4.2.2 Usage with limited vision
Supports with Exceptions
No mode of operation requires vision, as text is always provided in a programmatically-readable form. Guacamole and the Glyptodon Enterprise documentation additionally use high-contrast text. The Glyptodon Enterprise account / download interface contains some components with text that is relatively low-contrast.
4.2.3 Usage without perception of colour
Supports
Color is never used as the sole means of indicating meaning. Text is always included which unambiguously describes the meaning of the content even if color is absent.
4.2.4 Usage without hearing
Supports
Use of Guacamole and/or Glyptodon Enterprise does not depend on hearing.
4.2.5 Usage with limited hearing
Supports
Use of Guacamole and/or Glyptodon Enterprise does not depend on hearing.
4.2.6 Usage without vocal capability
Supports
Use of Guacamole and/or Glyptodon Enterprise does not depend on speech.
4.2.7 Usage with limited manipulation or strength
Supports with Exceptions
Opening the Guacamole menu requires pressing three keys simultaneously (Ctrl+Alt+Shift). Some parts of the Guacamole interface are not reachable through keyboard interaction alone, and thus may require mouse interaction. Logging out from the Glyptodon Enterprise account / download interface requires opening a menu which can only be reached using the mouse.
4.2.8 Usage with limited reach
Supports
Guacamole and Glyptodon Enterprise do not impose reach requirements.
4.2.9 Minimize photosensitive seizure triggers
Supports
Guacamole and Glyptodon Enterprise do not contain anything that flashes.
4.2.10 Usage with limited cognition
Does Not Support
The text within Guacamole and Glyptodon Enterprise contains technical jargon that is not defined and does not link to corresponding definitions.
4.2.11 Privacy
Not Applicable
Any accessibility features with privacy implications, such as automatic audible echo of keys pressed, automatic reading of the screen, etc., are controlled by the browser and/or the platform on which the browser is running.
5.1 Closed functionality
Not Applicable
All functionality within Guacamole and Glyptodon Enterprise is open to accessibility technologies. In the case of a remote desktop connection being accessed through Guacamole, such accessibility technologies will additionally need to be running remotely (within the remote desktop session).
5.2 Activation of accessibility features
Not Applicable
The accessibility features provided by Guacamole and Glyptodon Enterprise do not need to be activated. They are implemented through leveraging proper semantic elements, structure, and/or ARIA landmark roles, and are inherently always active.
5.3 Biometrics
Not Applicable
Neither Guacamole nor the various Glyptodon Enterprise services make use of biometrics.
5.4 Preservation of accessibility information during conversion
Not Applicable
No information or communication which is converted by Guacamole or Glyptodon Enterprise contains accessibility information.
5.5 Operable parts
Not Applicable
Neither Guacamole nor the various Glyptodon Enterprise services have operable parts. They are purely software.
5.6 Locking or toggle controls
Not Applicable
Neither Guacamole nor the various Glyptodon Enterprise services include physical locking or toggling components. They are purely software.
5.7 Key repeat
Does Not Support
Guacamole implements a 500 millisecond key repeat delay and 50 millisecond key repeat rate which affects typable keys used within a remote desktop session. There is no mechanism provided for configuring the key repeat delay nor the key repeat rate.
5.8 Double-strike key acceptance
Does Not Support
Guacamole does not provide a mechanism for filtering out double keystrokes.
5.9 Simultaneous user actions
Does Not Support
Opening the Guacamole menu requires pressing three keys simultaneously (Ctrl+Alt+Shift). There is effectively no other method of opening the menu.
Criteria
Conformance Level
Remarks and Explanations
7.1 Caption processing technology
Heading cell – no response required
Heading cell – no response required
7.1.1 Captioning playback
Supports
Videos are included alongside the Glyptodon Enterprise documentation to complement equivalent text documents. Such videos include captioning which corresponds to the audio within the video.
7.1.2 Captioning synchronization
Supports
Captions within videos included alongside the Glyptodon Enterprise documentation preserve synchronization between audio and corresponding captions.
7.1.3 Preservation of captioning
Supports
Captioning information, if present, is inherently lost in transmission from the remote desktop to the Guacamole server, however the captions themselves are still graphically forwarded (just like any other content within the remote desktop session).
7.2.1 Audio description playback
Does Not Support
Audio descriptions are not provided for videos which accompany the Glyptodon Enterprise documentation.
7.2.2 Audio description synchronization
Does Not Support
Audio descriptions are not provided for videos which accompany the Glyptodon Enterprise documentation.
7.2.3 Preservation of audio description
Supports
Audio descriptions, if present within content in a remote desktop session, will be retransmitted by the Guacamole server just like any other audio within the remote desktop session.
7.3 User controls for captions and audio description
Not Applicable
Neither Guacamole nor Glyptodon Enterprise primarily display materials containing video with accompanying audio. Guacamole provides access to remote desktops (general applications and systems, not specifically video with accompanying audio), while Glyptodon Enterprise documentation and support services are primarily text-based.
12.1 Product documentation
Heading cell – no response required
Heading cell – no response required
12.1.1 Accessibility and compatibility features
Does Not Support
Specific documentation is not provided on the usage of Guacamole or Glyptodon Enterprise with accessibility technologies.
12.1.2 Accessible documentation
See WCAG 2.0 section
See information in WCAG section
12.2 Support Services
Heading cell – no response required
Heading cell – no response required
12.2.2 Information on accessibility and compatibility features
Supports
For Glyptodon Enterprise subscriptions which include support services, those services include at least all documented features within scope. This report is part of that documentation.
12.2.3 Effective communication
Supports
For Glyptodon Enterprise subscriptions which include support services, those services are provided at a minimum through email and/or a text-based support desk. The support desk has been verified as accessible against WCAG 2.0.
12.2.4 Accessible documentation
See WCAG 2.0 section
See information in WCAG section
Activating additional packages on the Auto Docker Install method
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.....
Upgrading Keeper Connection Manager with the Docker Manual Install method
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):
If you originally installed with the Auto Docker Install method (kcm-setup.run script), run the below command:
Select "Y" when prompted.