Tchater maintenant avec le support
Tchattez avec un ingénieur du support

One Identity Safeguard for Privileged Sessions 7.0.4 LTS - ServiceNow - 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 authentication of the user, SPS will not request a new 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 login of the user), SPS will request a new authentication.

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

Declaration
[authentication_cache]
soft_timeout=15
hard_timeout=90
reuse_limit=5
soft_timeout
Type: integer [in seconds]
Required: yes, if you want caching
Default: N/A
Min value: 0
Max value: 2147483647

Description: The time in seconds after which the SPS plugin requires a new 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
Min value: 0
Max value: 2147483647

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

reuse_limit
Type: integer [number of]
Required: Optional
Default: 0
Min value: 0
Max value: 2147483647

Description: The number of times that you can reuse the authentication cache before the SPS plugin requires from you a new authentication for the next session. The default is 0, which means that the authentication cache is not unlimited, but it is turned off.

In the example, if reuse_limit is set to 5, and you successfully authenticated with multi-factor authentication, the next 5 authentications are bypassed in the next 90 seconds (hard_timeout), if there is no gap bigger than 15 seconds (soft_timeout) between the authentications.

If any of the hard_timeout, soft_timeout, or reuse_limit parameters, which operate independently from one another, exceed the configured limit, the SPS plugin requires you to authenticate for the new session.

[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 authentication.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation