KCM Version 2.19.2
Released on December 7, 2024
TOTP autofill support for RBI
In addition to autofill support of usernames and passwords, RBI can now autofill TOTP codes. The field that should receive the TOTP code must be declared in the autofill rules with a totp-code-field property:
Property Name
Description
totp-code-field
A CSS selector or XPath expression that matches the unique DOM element of the input field that should receive the current TOTP code.
If using XPath, the expression must start with a leading slash to clearly differentiate XPath from CSS.
For RBI to be able to generate TOTP codes, the TOTP secret must be provided ahead of time, along with any required details like the hash algorithm and the number of digits in each generated code:
Two-Factor Code Algorithm
totp-algorithm
SHA1
The hash algorithm that should be used to generate TOTP codes. Possible values are SHA1, SHA256, and SHA512.
Digits in Two-Factor Code
totp-digits
6
The number of digits which should be included in each generated TOTP code. Legal values are 6, 7, or 8.
Two-Factor Code Period (Seconds)
totp-period
30
The duration that each generated code should remain valid, in seconds.
Two-Factor Code Secret
totp-secret
N/A
The secret key that should be used to generate TOTP codes. This key will be unique to each user of the destination website and can be pulled dynamically from KSM using parameter tokens (see below).
Additional ${*_TOTP_SECRET} tokens are provided to allow the TOTP secret to be dynamically retrieved from the Keeper Vault using KSM. For example, to pull the TOTP code for the user account associated with an RBI connection, you would use the ${KEEPER_USER_TOTP_SECRET} parameter token.
Parameter Token
Description
${KEEPER_SERVER_TOTP_SECRET}
Retrieves: The TOTP secret associated with the record.
Matches: Record with hostname / IP address matching the value of the hostname / IP address in the “url” connection parameter.
${KEEPER_USER_TOTP_SECRET}
Retrieves: The TOTP secret associated with the record.
Matches: Record with login matching the “username” connection parameter
The following tokens are technically also defined, but do not currently have any practical use (there is no TOTP code generation needed for RDP):
Parameter Token
Description
${KEEPER_GATEWAY_TOTP_SECRET}
Retrieves: The TOTP secret associated with the record.
Matches: Record with hostname / IP address matching the value of the “gateway-hostname” connection parameter.
${KEEPER_GATEWAY_USER_TOTP_SECRET}
Retrieves: The TOTP secret associated with the record.
Matches: Record with login matching the “gateway-username” connection parameter.
Migration from Duo v2 to v4
The migration to Duo Web SDK v4 is incompatible with v2. If a customer has been using KCM with v2 despite Duo ending support for that version (through asking Duo to allow them to do so), they will need to:
Update their settings within Duo to use v4 (“Universal Prompt”) instead of v2 (“Legacy”).
Edit their KCM configuration to use the new properties/variables and their corresponding values from their Duo account (see below).
Any customer that has been using v2 and cannot yet change their settings to migrate to v4 will need to continue using KCM 2.19.0 or older until they can migrate.
Duo ceased supporting v2 of their “Web SDK” in favor of v4 (also known as the Duo “Universal Prompt”) some time ago, maintaining availability of v2 only for customers that require and request this. KCM has now been updated to use this new version. Duo’s Web SDK v4 is incompatible with v2 and uses different configuration options:
Property Name
Environment Variable
Description
duo-api-hostname
DUO_API_HOSTNAME
REQUIRED. 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.
duo-auth-timeout
DUO_AUTH_TIMEOUT
The timeout, in minutes, for in-progress Duo authentication attempts. Authentication attempts exceeding this duration will be invalidated. By default, Duo authentication attempts will time out after 5 minutes.
duo-client-id
DUO_CLIENT_ID
REQUIRED. The client ID provided for you by Duo when KCM was added as a "Web SDK" application. This value can be found within the application details in Duo's "Admin" panel.
duo-client-secret
DUO_CLIENT_SECRET
REQUIRED. The client secret provided for you by Duo when KCM was added as a "Web SDK" application. This value can be found within the application details in Duo's "Admin" panel.
duo-redirect-uri
DUO_REDIRECT_URI
REQUIRED. The user-facing URI that the Duo service can use to redirect an authenticated user's browser back to KCM.
The duo-application-key, duo-integration-key, and duo-secret-key properties (and the DUO_APPLICATION_KEY, DUO_INTEGRATION_KEY, and DUO_SECRET_KEY variables) are specific to v2 of Duo’s Web SDK and no longer have any effect.
Verbose mode for KCM install script (kcm-setup.run)
kcm-setup.run)This new debug/verbose mode for the KCM install script is mainly of use for obtaining debugging information that the KCM development team can use to troubleshoot customer issues that otherwise have no explanation. It’s unlikely that this variable will be useful to customers outside that context and the sheer verbosity resulting from using it might cause confusion.
The kcm-setup.run script now supports a KCM_SETUP_DEBUG environment variable that causes the script to run in verbose mode, printing out all commands run and all output from those commands. This debug output can be sent directly to the terminal or to a file depending on the value of KCM_SETUP_DEBUG.
export KCM_SETUP_DEBUG=/path/to/file
sudo -E ./kcm-setup.runLast updated
Was this helpful?