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

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

Configure your RSA account for SPS

Prerequisites:
  • Administrator access to your RSA account.

  • Make sure that you have all the required components listed in Technical requirements.

  1. Add users to your RSA account.

    The users you want to authenticate with SPS must have an activated account in RSA. For details on adding or importing your users, see Integrating LDAP Directories in RSA Authentication Manager Administrator's Guide in the RSA documentation.

  2. Enable Multi-factor Authentication (MFA) for your organization.

    Optionally, you can create a Multi-factor Policy in RSA to enable MFA only for the group of users who you want to authenticate with SPS.

    For details, see Policy Enforcement in RSA Authentication Manager Administrator's Guide in the RSA documentation.

  3. Retrieve the RADIUS access parameters.

    RADIUS access parameters, (for example, host, port, and an RSA shared secret).

Configure SPS to use RADIUS multi-factor authentication

Prerequisites:
  • Your RADIUS secret and other RADIUS server parameters that are required for configuration.

  • Administrator access to SPS.

  • Make sure that you have all the required components listed in Technical requirements.

To configure SPS to use RADIUS multi-factor authentication

  1. Download the SPS RADIUS (RSA) Multi-Factor Authentication plugin

    SPS customers can download the official plugin from GitHub.

  2. Upload the plugin to SPS

    Upload the plugin to SPS. For details, see the "Using a custom Authentication and Authorization plugin to authenticate on the target hosts" in the Administration Guide.

  3. Configure the plugin on SPS

    The plugin includes a default configuration file, which is an ini-style configuration file with sections and name=value pairs. You can edit this configuration file on the Policies > AA Plugin Configurations page of the SPS web interface.

    1. Configure the usermapping settings if needed. SPS must find out which RSA user belongs to the username of the authenticated connection. For that, it can query your LDAP/Microsoft Active Directory server. For details, see [USERMAPPING].

    2. Configure other parameters of your plugin as needed for your environment. For details, see SPS RADIUS plugin parameter reference.

  4. Configure a Connection policy and test it

    Configure a Connection policy on SPS. In the AA plugin field of the Connection policy, select the SPS RADIUS plugin you configured in the previous step, then start a session to test it. For details on how a user can perform multi-factor authentication, see Perform multi-factor authentication with the SPS RADIUS plugin in terminal connections and Perform multi-factor authentication with the SPS RADIUS plugin in Remote Desktop connections.

SPS RADIUS plugin parameter reference

This section describes the available options of the SPS RSA plugin.

The plugin uses an ini-style configuration file with sections and name=value pairs. This format consists of sections, led by a [section] header and followed by name=value entries. Note that the leading whitespace is removed from values. The values can contain format strings, which refer to other values in the same section. For example, the following section would resolve the %(dir)s value to the value of the dir entry (/var in this case).

[section name]
dirname=%(dir)s/mydirectory
dir=/var

All reference expansions are done on demand. Lines beginning with # or ; are ignored and may be used to provide comments.

You can edit the configuration file from the SPS web interface. The following code snippet is a sample configuration file.

Sample configuration file
[radius]
server=<radius-server-ip-or-hostname>
port=1812
secret=$
auth_type=pap
conn_retries=3
conn_timeout=5

[auth]
prompt=Press Enter for push notification or type one-time password:
disable_echo=no

[connection_limit by=client_ip_gateway_user]
limit=0

[authentication_cache]
hard_timeout=90
soft_timeout=15
reuse_limit=0

######[WHITELIST]######

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

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

######[USERMAPPING]######

[usermapping source=explicit]
<user-name-1>=<id-1>
<user-name-2>=<id-2>

[usermapping source=ldap_server]
user_attribute=description

[username_transform]
append_domain=<domain-without-@-character>

[ldap_server]
name=<name-of-LDAP-server-policy>

[credential_store]
name=<name-of-credential-store-policy-that-hosts-sensitive-data>

[logging]
log_level=info

[https_proxy]
server=<proxy-server-name-or-ip>
port=3128

[question_1]
prompt=<prompt-to-show-to-the-user>
key=<target-key-for-the-answer>
disable_echo=yes

[radius]

This section contains the options related to your RADIUS (RSA) connectivity.

Declaration
[radius]
server=<radius-server-ip-or-hostname>
port=1812
secret=<$-or-shared-secret-with-radius-server>
auth_type=pap
conn_retries=3
conn_timeout=5
server
Type: string
Required: yes
Default: N/A

Description: The name of your server where the RADIUS interface is available. Enter either the IP address or the hostname.

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

Caution:

This parameter contains sensitive data. Make sure to store this data in your local Credential Store. Type the $ value for this parameter in production.

For details, see "Store sensitive plugin data securely".

Only enter a value different than $ for this parameter in the configuration for testing purposes in a secure, non-production environment.

Description: Your RADIUS shared secret. SPS uses this to communicate with the RADIUS server. For details on using a local Credential Store to host this data, read Store sensitive plugin data securely.

port
Type: integer
Required: no
Default: 1812

Description: The port where the RADIUS server is listening for access requests.

auth_type
Type: string (chap | pap)
Required: no
Default: pap

Description: RADIUS authentication type.

  • chap: CHAP (Challenge-Handshake Authentication Protocol) is a more secure authentication scheme than PAP. In a CHAP scheme, the following process establishes a user identity:

    1. After the link between the user machine and the authenticating server is established, the server sends a challenge message to the connection requester. The requester responds with a value obtained by using a one-way hash function.

    2. The server checks the response by comparing it against its own calculation of the expected hash value.

    3. If the values match, the authentication is acknowledged, otherwise the connection is terminated.

    At any time, the server can request the connected party to send a new challenge message. CHAP identifiers are changed frequently and the server can make an authentication request at any time.

  • pap: The Password Authentication Protocol (PAP) provides a simple method for a user to authenticate using a two-way handshake. PAP only executes this process when establishing the initial link to the authenticating server. A user machine repeatedly sends an ID/Password pair to the authenticating server until authentication is acknowledged or the connection is terminated.

    Use PAP authentication where a plain text password must be available to simulate a login at a remote host. This method provides a similar level of security to the usual user login at the remote host.

conn_timeout
Type: integer [in seconds]
Required: no
Default: 10

Description: Number of seconds to wait for an answer at each retry.

conn_retries
Type: integer
Required: no
Default: 3

Description: Number of times to retry sending a RADIUS request if the communication fails.

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択