Dynamic Tokens
Using the integration between Connection Manager and Vault with dynamic field lookups
Last updated
Using the integration between Connection Manager and Vault with dynamic field lookups
Last updated
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.
Parameter Token | Description |
| Retrieves: “Login” field of single matched record Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter |
| 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 |
| 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 |
| Retrieves: “Password” field of single matched record Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter |
| Retrieves: “Domain” custom field of single matched record Matches: Record with hostname / IP address matching the value of the “hostname” connection parameter |
| Retrieves: “Private Key” field (or single .pem file attachment) of single matched record Matches: Record with login matching the “username” connection parameter |
| Retrieves: “Passphrase” field (or “password” if no passphrase) of single matched record Matches: Record with login matching the “username” connection parameter |
| Retrieves: “Password” field of single matched record Matches: Record with login matching the “username” connection parameter |
| Retrieves: “Domain” custom field of single matched record Matches: Record with login matching the “username” connection parameter |
| Retrieves: “Login” field of single matched record Matches: Record with custom "Domain" field matching the value of the “domain” connection parameter |
| Retrieves: “Password” field of single matched record Matches: Record with login matching the “domain” connection parameter |
The tokens below are applicable only to connection types that have gateway support (RDP).
Parameter Token | Description |
| Retrieves: “Login” field of single matched record Matches: Record with hostname / IP address matching the value of the “gateway-hostname” connection parameter. |
| 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. |
| 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. |
| Retrieves: “Password” field of single matched record Matches: Record with hostname / IP address matching the value of the “gateway-hostname” connection parameter. |
| Retrieves: “Private Key” field (or single .pem file attachment) of single matched record Matches: Record with login matching the “gateway-username” connection parameter. |
| Retrieves: “Passphrase” field (or “password” if no passphrase) of single matched record Matches: Record with login matching the “gateway-username” connection parameter |
| Retrieves: “Password” field of single matched record Matches: Record with login matching the “gateway-username” connection parameter |
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