This document describes how you can use the services of ServiceNow to authenticate
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
SPS integrates with ServiceNow by enabling ticket ID request and validation during authentication
The integration adds an additional security layer to the gateway authentication performed on SPS by verifying that the user has a valid reason to access the server. SPS prompts the user for a valid ServiceNow ticket ID, and upon successful authorization, it permits the user to access the information system.
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.
Figure 1: How SPS and
A user attempts to log in to a protected server.
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.
You can configure SPS using whitelists and blacklists to selectively require multi-factor authentication
If multi-factor authentication
If multi-factor authentication
For details on creating exemption lists, see
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
If gateway authentication is successful, SPS prompts the user for a valid ServiceNow ticket ID. Then SPS connects to the ServiceNow server and runs a predefined query, and upon successful authorization, it permits the user to access the information system.
If multi-factor authentication
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
In order to successfully connect SPS with RADIUS server, you need the following components.
An active ServiceNow instance.
A One Identity Safeguard for Privileged Sessions appliance (virtual or physical), at least version SPS
A copy of the SPS ServiceNow plugin. This plugin is an Authentication and Authorization (AA) plugin customized to work with ServiceNow.
SPS must be able to access the
The connection also requires the
SPS supports AA plugins in the MSSQL, 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.
In RDP, using an AA plugin requires TLS-encrypted RDP connections. For details, see "Enabling TLS-encryption for RDP connections" in the Administration Guide.
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. |
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center