Chatta subito con l'assistenza
Chat con il supporto

One Identity Safeguard for Privileged Sessions 7.0.4 LTS - Starling Two-Factor Authentication- Tutorial

[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 Starling 2FA authentication.

[whitelist source=user_list]

The [whitelist source=user_list] section allows whitelisting users based on a User List policy configured in SPS (Policies > User Lists). To enable this whitelist, configure one of the use cases below.

NOTE: The user names are compared to the User List in a case-sensitive manner.

Declaration
[whitelist source=user_list]
name=<name-of-user-list-policy>

For details on creating user lists, see "Creating and editing user lists" in the Administration Guide.

name
Type: string
Required: no
Default: N/A

Description: The name of a User List policy containing gateway users configured on SPS (Policies > User Lists). You can use this option to selectively require multi-factor authentication for your users (for example, to create break-glass access for specific users).

Use case #1: Allow no user except certain users

To allow specific users to connect without providing Starling 2FA credentials, the User List policy should have the following settings:

  • Set Allow to No user and list the users in the Except list.
  • Then type the name of this User List policy as the value of the name parameter.
Use case #2: Allow all users except certain users

To enforce Starling 2FA authentication for selected users, the User List policy should have the following settings:

  • Set Allow to All users and list the users in the Except list.
  • Then type the name of this User List policy as the value of the name parameter.

[whitelist source=ldap_server_group]

The [whitelist source=ldap_server_group] section allows whitelisting users based on LDAP Server group membership. To enable this whitelist, configure one of the use cases below.

NOTE: The user names and groups are compared in LDAP in a case-insensitive manner.

Declaration
[whitelist source=ldap_server_group]
allow=<no_user-or-all_users>
except=<group-1>,<group-2>
allow
Type: string (all_users | no_users)
Required: no
Default: N/A

Description: This parameter defines whether to allow all users or no user to connect without providing Starling 2FA credentials. Used together with the except parameter, you can define specific LDAP/AD group(s) that are exempt from this rule.

except
Type: string
Required: no
Default: N/A

Description: This parameter defines those specific LDAP/AD group(s) that are exempt from the rule defined by the allow parameter.

Use case #1: Allow no user except members of specific group(s)

To allow members of specific LDAP/AD group(s) to connect without providing Starling 2FA credentials, type the names of these LDAP/AD groups as values of the except parameter and set the allow parameter to no_user:

[whitelist source=ldap_server_group]
allow=<no_user>
except=<group-1>,<group-2>

You must configure the name of the LDAP Server policy in the [ldap_server] section.

Use case #2: Allow all users except members of specific group(s)

To enforce Starling 2FA authentication only on members of specific LDAP/AD group(s), type the names of these LDAP/AD groups as values of the except parameter and set the allow parameter to all_users:

[whitelist source=ldap_server_group]
allow=<all_users>
except=<group-1>,<group-2>

You must configure the name of the LDAP Server policy in the [ldap_server] section.

[USERMAPPING]

By default, SPS assumes that the external Starling 2FA identity of the user is the same as the gateway username (that is, the username the user used to authenticate on SPS during the gateway authentication). If there was no gateway authentication, then the server username is used for authentication.

The gateway usernames are different from the external Starling 2FA identities. You must configure the SPS Starling 2FA plugin to map the gateway usernames to the external Starling 2FA identities.

The external identity is the Starling ID. To obtain the Starling ID:

  1. Download the Starling 2FA mobile application from the platform-specific (Apple or Android) application store.

  2. Configure the mobile application.

  3. Once the mobile application is integrated with Starling, open the Settings of the mobile application.

  4. From the MY ACCOUNT tab, copy the Starling 2FA ID.

You can use the following methods:

The Explicit method has priority over the LDAP server method.

If you have configured neither the append_domain parameter nor any of the [USERMAPPING] sections, SPS assumes that the external Starling 2FA identity of the user is the same as the gateway username.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione