Introduction
This document describes how you can use the services of Okta 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.
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
Okta Adaptive Multi-factor Authentication:
Okta is a cloud-based identity service offering identity, authentication, and access control functions as a service. To support multi-factor authentication, SPS integrates with the Okta identity management service. 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 a seamless and efficient user experience that is readily accepted by the users.
The One Identity Safeguard for Privileged Sessions can interact with your Okta account and can automatically request strong multi-factor authentication for your privileged users who are accessing the servers and services protected by SPS. Okta supports a broad range of authentication methods, including software, hardware, and cellphone-based solutions.
Solution benefits
Matt Magleby, Sr. Computer Scientist at Adobe One Identity Safeguard for Privileged Sessions helps us meet a portion of our compliance and internal security requirements related to access management.
Using SPS together with Okta provides the following benefits:
-
Easy-to-use multi-factor authentication secures privileged access to business-critical servers. The enforcement of a second-factor authentication and the availability of session recordings make access of high-risk users more secure.
-
Outband 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
-
PCI DSS 8.3: Secure all individual non-console administrative access and all remote access to the cardholder data environment (CDE) using MFA.
-
PART 500.12 Multi-Factor Authentication: Covered entities are required to apply MFA 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 MFA for network access to privileged accounts.
Technical requirements
In order to successfully connect SPS with RADIUS server, you need the following components.
In Okta :
-
A valid
-
An Okta API key. You will need it to configure the SPS plugin.
-
Your users must be
-
The users must activate their Okta accounts, and be able to perform the authentication required for the factor (for example, install the Okta mobile app, possess the required hardware token, and so on).
-
A factor that the SPS plugin supports must be enabled in Okta. Note that this is a global setting, you cannot selectively enable factors. For a list of factors that SPS supports, see Supported factors and scenarios.
In SPS:
-
A One Identity Safeguard for Privileged Sessions appliance (virtual or physical), at least version 5 F11.
-
A copy of the SPS
-
SPS must be able to access the
-
Depending on the factor you use to authenticate your users, your users might need Internet access as well, for example, to use the Okta Verify Push Notification factor. Note that the Okta app generates one-time passwords (OTPs) offline.
-
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
|
|
Caution:
Using custom plugins in SPS is recommended only if you are familiar with both Python and SPS. Product support applies only to SPS: that is, until the entry point of the Python code and passing the specified arguments to the Python code. One Identity is not responsible for the quality, resource requirements, or any bugs in the Python code, nor any crashes, service outages, or any other damage caused by the improper use of this feature, unless explicitly stated in a contract with One Identity. If you want to create a custom plugin, contact our Support Team for details and instructions. |
Supported factors and scenarios
The SPS Okta plugin can provide multi-factor authentication in the Remote Desktop (RDP), Secure Shell (SSH), and TELNET protocols. In RDP, using push notifications (when the user authenticates using the Okta mobil app) is the most convenient method. You can use another factor, but in this case the user must encode the OTP password into the username used in the connection, before trying to connect to the server.
Okta supports several different authentication backends ("factor types" in Okta terminology). When using one-time passwords (OTP-like factors), your users can specify which factor they use (from the ones available for them in Okta).
You can also set a default factor in the Okta configuration, it defaults to Okta Verify (One-Time Password).
The SPS Okta plugin supports the following authentication factors:
-
Google Authenticator (One-Time Password)
-
Okta Push Authentication
-
Okta Verify (One-Time Password)
-
RSA token
-
Symantec token (One-Time Password)
-
YubiKey token (One-Time Password)
You can also configure SPS to require multi-factor authentication only from selected users or usergroups. You can also specify exceptions, that is, require multi-factor authentication from everyone except the specified users. This allows you to have emergency or break-glass users who can access your servers even if the Okta services are not available. For details, see "[auth]" in the Okta Multi-Factor Authentication - Tutorial.
How SPS and Okta work together in detail
Figure 1: How SPS and
-
A user attempts to log in to a protected server.
-
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.
-
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].
-
-
Determining the
If the gateway usernames are different from the
-
Outband authentication on
If gateway authentication is successful, SPS connects the
-
For OTP-like authentication factors, SPS requests the OTP from the user, and sends it to the
-
For the
-
-
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.)
-
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 [authentication_cache].