サポートと今すぐチャット
サポートとのチャット

One Identity Safeguard for Privileged Sessions 6.0.11 - RADIUS Multi-Factor Authentication - Tutorial

[auth]

This section contains the options related to authentication.

Declaration
[auth]
prompt=Press Enter for push notification or type one-time password:
disable_echo=yes
prompt
Type: string
Required: no
Default: Press Enter for push notification or type one-time password:

Description: SPS displays this text to the user in a terminal connection to request an OTP interactively. The text is displayed only if the user uses an OTP-like factor, and does not send the OTP in the connection request.

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

Description: For better security, you can hide the characters (OTP or password) that the user types after the prompt. To hide the characters (replace them with asterisks), set disable_echo to yes.

[connection_limit by=client_ip_gateway_user]

This section contains the options related to limiting parallel sessions.

Declaration
[connection_limit by=client_ip_gateway_user]
limit=0
limit
Type: integer
Required: no
Default: 0

Description: To limit the number of parallel sessions the gateway user can start from a given client IP address, configure limit. For an unlimited number of sessions, type 0.

[authentication_cache]

This section contains the settings that determine how soon after performing a 2FA/MFA authentication the user must repeat the authentication when opening a new session.

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

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

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

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

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

Description: The time in seconds after which the SPS plugin requires a new RADIUS server authentication for the next new session of the user. The time is measured from the last RADIUS server 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.

[WHITELIST]

Having to perform multi-factor authentication to a remote server every time the user opens a session can be tedious and inconvenient for the users, and can impact their productivity. SPS offers the following methods to solve this problem:

  • In SPS, the Connection policy determines the type of authentication required to access a server. If you do not need multi-factor authentication for accessing specific servers, configure your Connection policies accordingly.

  • If the user opens a new session within a short period, they can do so without having to perform multi-factor authentication. After this configurable grace period expires, the user must perform multi-factor authentication to open the next session. For details, see [authentication_cache].

  • The [whitelist source=user_list] and [whitelist source=ldap_server_group] sections allow configuring authentication whitelists and blacklists based on a User List policy or an LDAP Server policy. These two sections are independent, therefore any of the two can be configured and, for example, can create break-glass access for specific users to allow them to bypass RADIUS server authentication.

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択