One Identity Safeguard for Privileged Sessions 6.0 LTS - DEPRECATED RSA Multi-Factor Authentication - Tutorial

Introduction

This document describes how you can use the services of multi-factor authentication provider RSA to authenticate the sessions of your privileged users with One Identity Safeguard for Privileged Sessions (SPS).

One Identity Safeguard for Privileged Sessions:

One Identity Safeguard for Privileged Sessions (SPS) controls privileged access to remote IT systems, records activities in searchable, movie-like audit trails, and prevents malicious actions. SPS is a quickly deployable enterprise device, completely independent from clients and servers — integrating seamlessly into existing networks. It captures the activity data necessary for user profiling and enables full user session drill down for forensic investigations.

RSA Adaptive Multi-factor Authentication:

To support multi-factor authentication, SPS integrates with the identity management service RSA. This enables you to leverage an additional out-of-band factor (typically through the user’s registered smartphone) when authenticating the user. The additional factor is processed in-line with the connection, so users do not have to switch to an external application to process the additional factor. This results in an efficient user experience that is readily accepted by the users.

The One Identity Safeguard for Privileged Sessions can interact with your RSA account and can automatically request multi-factor authentication for your privileged users who are accessing the servers and services protected by SPS.

Figure 1: How SPS and RSA work together

Solution benefits

Using SPS together with RSA provides the following benefits:

• Easy-to-use multi-factor authentication to secure your privileged users who access your business-critical servers. The enforcement of a second-factor authentication and the availability of session recordings make the access of high-risk users more secure.

• Out-of-band authentication to protect against privileged identity theft.

• Logs and audits administrative network traffic.

• Integrates with existing LDAP user directory.

• Easy and fast deployment and implementation: a network-level solution that does not require installing agents on clients or servers.

• Can forward user logs into Splunk for long-term storage and analysis.

• Supports SSH and RDP protocols to access both Linux and Windows servers, without disrupting the daily workflow of your system administrators and other privileged users.

• Supports strong authentication methods, including SSH keys and certificates.

Meet compliance requirements

ISO 27001, ISO 27018, SOC 2, and other regulations and industry standards include authentication-related requirements, for example, multi-factor authentication (MFA) for accessing production systems, and the logging of all administrative sessions. In addition to other requirements, using SPS and RSA helps you comply with the following requirements:

• PCI DSS 8.3: Secure all individual non-console administrative access and all access to the cardholder data environment (CDE) using multi-factor authentication.

• PART 500.12 Multi-Factor Authentication: Covered entities are required to apply multi-factor authentication for:

  • Each individual accessing the covered entity’s internal systems.

  • Authorized access to database servers that allow access to nonpublic information.

  • Third parties accessing nonpublic information.

• NIST 800-53 IA-2, Identification and Authentication, network access to privileged accounts: The information system implements multi-factor authentication for network access to privileged accounts

SPS acts as a central authentication gateway, enforcing strong authentication before users access sensitive IT assets. SPS can integrate with remote user directories to resolve the group memberships of users who access nonpublic information. Credentials for accessing information systems can be retrieved transparently from SPS's local credential store or a third-party password management system. This method protects the confidentiality of passwords as users can never access them. When used together with RSA (or another multi-factor authentication provider), SPS directs all connections to the authentication tool, and upon successful authentication, it permits the user to access the information system.

How SPS and RSA MFA work together

Figure 2: How SPS and RSA work together

1. A user attempts to log in to a protected server.

2. Gateway authentication on SPS

   SPS receives the connection request and authenticates the user. SPS can authenticate the user to a number of external user directories, for example, LDAP, Microsoft Active Directory, or RADIUS. This authentication is the first factor.

3. Authentication using RSA SecurID Access

   If gateway authentication is successful, SPS connects the RSA Authentication Manager. Then SPS requests the second authentication factor from the user and sends it to the RSA server for verification.

4. If multi-factor authentication is successful, the user can start working, while SPS records the user's activities. (Optionally, SPS can retrieve credentials from a local or external credential store or password vault, and perform authentication on the server with credentials that are not known to the user.)

Technical requirements

In order to successfully connect SPS with RSA, you need the following components.

In RSA:

• An RSA Authentication Manager deployed.

• RADIUS access parameters, for example, host, port, and an RSA shared secret. You will need it to configure the SPS plugin.

• Your users must be enrolled in RSA Authentication Manager.

• The users must be able to perform the authentication required for the fasctor (for example, possess the required RSA SecurID Hardware Token).

In SPS:

• A One Identity Safeguard for Privileged Sessions appliance (virtual or physical), at least version 5 F1.

• A copy of the SPS RSA plugin. This plugin is an Authentication and Authorization (AA) plugin customized to work with the RSA multi-factor authentication service.

• SPS must be able to access the RADIUS port of the RSA Authentication Manager.

• SPS supports AA plugins in the RDP, SSH, and Telnet protocols.

• In RDP, using an AA plugin together with Network Level Authentication in a Connection Policy has the same limitations as using Network Level Authentication without domain membership. For details, see "Network Level Authentication without domain membership" in the Administration Guide.

• In RDP, using an AA plugin requires TLS-encrypted RDP connections. For details, see "Enabling TLS-encryption for RDP connections" in the Administration Guide.

Availability and support of the plugin

The SPS RADIUS (RSA) Multi-Factor Authentication plugin is available as-is, free of charge to every SPS customer from the Plugin Page. In case you need any customizations or additional features, contact our Support Team.

How SPS and RSA work together in detail

Figure 3: How SPS and RSA work together

1. A user attempts to log in to a protected server.

2. Gateway authentication on SPS

   SPS receives the connection request and authenticates the user. SPS can authenticate the user to a number of external user directories, for example, LDAP, Microsoft Active Directory, or RADIUS. This authentication is the first factor.

3. Check if the user is exempt from multi-factor authentication

   You can configure SPS using whitelists and blacklists to selectively require multi-factor authentication for your users, for example, to create break-glass access for specific users.

   • If multi-factor authentication is not required, the user can start working, while SPS records the user's activities. The procedure ends here.

   • If multi-factor authentication is required, SPS continues the procedure with the next step.

   For details on creating exemption lists, see whitelist.

4. Determining the RSA username

   If the gateway usernames are different from the RSA usernames, you must configure the SPS RSA plugin to map the gateway usernames to the RSA usernames. The mapping can be as simple as appending a domain name to the gateway username, or you can query an LDAP or Microsoft Active Directory server. For details, see Mapping SPS usernames to RSA identities.

5. Authentication using RSA SecurID Access

   If gateway authentication is successful, SPS connects the RSA Authentication Manager. Then SPS requests the second authentication factor from the user and sends it to the RSA server for verification.

6. If multi-factor authentication is successful, the user can start working, while SPS records the user's activities. (Optionally, SPS can retrieve credentials from a local or external credential store or password vault, and perform authentication on the server with credentials that are not known to the user.)

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