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:

Field header
Parameter name
Default Value
Description

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:

  1. Update their settings within Duo to use v4 (“Universal Prompt”) instead of v2 (“Legacy”).

  2. 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)

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.run

Last updated

Was this helpful?