立即与支持人员聊天
与支持团队交流

One Identity Safeguard for Privileged Sessions 6.0.1 - DEPRECATED inWebo Multi-Factor Authentication - Tutorial

[cache]

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

After the first inWebo authentication of the user, SPS will not request a new inWebo 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 inWebo login of the user), SPS will request a new inWebo authentication.

In other words, after opening the first session and authenticating on inWebo, the user can keep opening other sessions without having to authenticate again on inWebo as long as the time between opening any two sessions is less than soft_timeout, but must authenticate on inWebo 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 inWebo 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 inWebo authentication for the next new session of the user. The time is measured from the last inWebo 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 inWebo.

To look up the inWebo username of the user from an LDAP/Active Directory database, configure the [ldap] section of the SPS inWebo 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 inWebo 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 inWebo usernames, see Mapping SPS usernames to inWebo 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 inWebo 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 inWebo usernames, you must configure the SPS inWebo plugin to map the gateway usernames to the inWebo 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 inWebo 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 inWebo server.

If you configure both the append_domain parameter and the [ldap] section of the SPS inWebo 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 inWebo usernames, see Mapping SPS usernames to inWebo 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).

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级