Converse agora com nosso suporte
Chat com o suporte

One Identity Safeguard for Privileged Sessions 6.0.4 - DEPRECATED RSA Multi-Factor Authentication - Tutorial

[cache]

This section contains the settings that determine how soon after performing an RSA authentication must the user repeat the authentication when opening a new session.

After the first RSA authentication of the user, SPS will not request a new RSA authentication from the user as long as the new authentications would happen within soft_timeout seconds from each other. After the hard_timeout expires (measured from the first RSA login of the user), SPS will request a new RSA authentication.

In other words, after opening the first session and authenticating on RSA, the user can keep opening other sessions without having to authenticate again on RSA as long as the time between opening any two sessions is less than soft_timeout, but must authenticate on RSA if hard_timeout expires.

[cache]
soft_timeout=15
hard_timeout=90
conn_limit=5
soft_timeout
Type: integer [seconds]
Required: yes, if you want caching
Default: N/A

Description: The time in seconds after which the SPS plugin requires a new RSA authentication for the next new session of the user, unless the user successfully authenticates another session within this period.

hard_timeout
Type: integer [seconds]
Required: yes, if you want caching
Default: N/A

Description: The time in seconds after which the SPS plugin requires a new RSA authentication for the next new session of the user. The time is measured from the last RSA authentication of the user.

conn_limit
Type: integer [number of]

Description: The cache can be used conn_limit times without multi-factor authentication. If the number of logins exceeds this number, the plugin will request multi-factor authentication again. If this parameter is not set, the number of logins from cache are unlimited.

[ldap]

This section contains the settings you configure when you need to use an LDAP query to map the usernames from your audited sessions to the usernames in RSA.

To look up the RSA username of the user from an LDAP/Active Directory database, configure the [ldap] section of the SPS RSA plugin. Typically, the SPS plugin queries the email address corresponding to the username from your LDAP or Active Directory database. For details on LDAP parameters, see [ldap].

If you configure both the append_domain parameter and the [ldap] section of the SPS RSA plugin, SPS appends the @ character and the value of the append_domain parameter to the value retrieved from the LDAP database.

For other methods of mapping gateway usernames to RSA usernames, see Mapping SPS usernames to RSA identities.

[ldap]
ldap_server_config=<SPS-LDAP-server-policy-name>
filter=(&(cn={})(objectClass=inetOrgPerson))
user_attribute=CN
ldap_server_config
Type: string
Required: no
Default: N/A

Description: The name of a configured LDAP server policy in SPS. For details on configuring LDAP policies, see "Authenticating users to an LDAP server" in the Administration Guide.

filter
Type: string
Required: no
Default: (&(cn={})(objectClass=inetOrgPerson))

Description: The LDAP filter query that locates the user based on the gateway username. The plugin automatically replaces the {} characters with the gateway username from the session.

filter=(&(cn={})(objectClass=inetOrgPerson))
user_attribute
Type: string
Required: no
Default: cn

Description: The name of the LDAP attribute that contains the RSA username.

[username_transform]

This section contains username transformation-related settings.

[username_transform]
append_domain=""
append_domain
Type: string (nonrequired, no default)
Required: no
Default: N/A

Description: If the gateway usernames are different from the RSA usernames, you must configure the SPS RSA plugin to map the gateway usernames to the RSA usernames.

To simply append a string to the gateway username, configure the append_domain parameter. In this case, SPS automatically appends the @ character and the value of this option to the username from the session, and uses the resulting username on the RSA server to authenticate the user. For example, if the domain is set as append_domain: example.com and the username is Example.User, the SPS plugin will look for the user Example.User@example.com on the RSA server.

If you configure both the append_domain parameter and the [ldap] section of the SPS RSA plugin, SPS appends the @ character and the value of the append_domain parameter to the value retrieved from the LDAP database.

For other methods of mapping gateway usernames to RSA usernames, see Mapping SPS usernames to RSA identities.

[question_1]

Type: integer [seconds]

Description: Used for communication between plugins. This is an interactive request/response right after authentication in order to supply data to credential store plugins. The question is transferred to the session cookie and all hooks of all plugins receive it.

For example, if you have an external authenticator app, you do not have to wait for the question to be prompted but can authenticate with a one-time password:

ssh otp=123456@root@scb

Name subsequent questions with the appropriate number, for example, [question_1], [question_2], and so on.

For details, see "Performing authentication with AA plugin in terminal connections" in the Administration Guide and "Performing authentication with AA plugin in Remote Desktop connections" in the Administration Guide.

key
Type: string
Required: yes
Default: N/A

Description: The name of the name-value pair.

prompt
Type: string
Required: yes
Default: N/A

Description: The question itself in text format.

disable_echo
Type: boolean yes|no
Required: no
Default: no

Description: Whether the answer to the question is visible (yes), or replaced with asterisks (no).

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação