The One Identity Safeguard for Privileged Sessions (SPS) web interface can authenticate users to an external LDAP database to simplify the integration of SPS to your existing infrastructure. You can also specify multiple LDAP servers, so that if the first server becomes unavailable, SPS can try to connect to another server.
NOTE: Consider the following:
-
Local users, including the admin user, are available by default.
-
The admin user has every privilege and cannot be deleted.
-
SPS accepts both pre-Windows 2000 style and Windows 2003 style User Principal Names (UPNs). UPNs consist of a username, the at (@) character, and a domain name, for example administrator@example.com.
-
For SSH usernames, SPS supports only valid UTF-8 strings.
-
The following characters cannot be used in:
-
When using RADIUS authentication with LDAP users, the users are authenticated to the RADIUS server. However, their group memberships are managed in LDAP. For details, see Authenticating users to a RADIUS server in the Administration Guide.
- If the matching rule for an attribute is case insensitive in the LDAP database, SPS treats user names and group names in a case-insensitive manner.
Prerequisites
Make sure that the response timeout of the LDAP/Active Directory server is set to a minimum of 120 seconds.
To configure an LDAP server
-
Navigate to Users & Access Control > Login options > Manage AD/LDAP Servers.
-
Select the LDAP server from the list. Alternatively, if no LDAP server exists yet, click Add new server and select the server type you want to create:
The One Identity Safeguard for Privileged Sessions (SPS) web interface can authenticate users to an external LDAP database to simplify the integration of SPS to your existing infrastructure. You can also specify multiple LDAP servers, so that if the first server becomes unavailable, SPS can try to connect to another server.
NOTE: Consider the following:
-
Local users, including the admin user, are available by default.
-
The admin user has every privilege and cannot be deleted.
-
SPS accepts both pre-Windows 2000 style and Windows 2003 style User Principal Names (UPNs). UPNs consist of a username, the at (@) character, and a domain name, for example administrator@example.com.
-
For SSH usernames, SPS supports only valid UTF-8 strings.
-
The following characters cannot be used in:
-
When using RADIUS authentication with LDAP users, the users are authenticated to the RADIUS server. However, their group memberships are managed in LDAP. For details, see Authenticating users to a RADIUS server in the Administration Guide.
- If the matching rule for an attribute is case insensitive in the LDAP database, SPS treats user names and group names in a case-insensitive manner.
Prerequisites
Make sure that the response timeout of the LDAP/Active Directory server is set to a minimum of 120 seconds.
To configure an LDAP server
-
Navigate to Users & Access Control > Login options > Manage AD/LDAP Servers.
-
Select the LDAP server from the list. Alternatively, if no LDAP server exists yet, click Add new server and select the server type you want to create:
This section and its subsections describe how you can handle user names in User Principal Name (UPN) format in One Identity Safeguard for Privileged Sessions (SPS).
About the UPN format
The UPN format is a user name in an email-like format, which consists of three parts:
UPN user names are common in many applications and protocols. In Active Directory, the domain identifier selects the Active Directory domain that the user belongs to.
NOTE: Even though a UPN user name may look like an email address, it is not always a valid email address. Similarly, a person's valid email address is not necessarily a valid UPN user name, either.
Multiple identifiers of a single user entity while using UPN user names
In SPS, user identifiers are used in several places. For example, users can specify their user name as part of their login credentials, administrators can create groups of users for authorization purposes, and auditors can search for the activities of a certain person.
In Active Directory, several user name forms may refer to the same person. For example, these three can all belong to a single Active Directory user object:
-
EXAMPLE\exampleuser (down-level user name)
-
exampleuser@example.local
-
ExampleUser@example.com (UPN with an alternative suffix).
When it comes to Windows authentication, the user is free to choose from any of the user name forms above. However, SPS components are only aware of the specified form of the user name.
Case-sensitivity while using UPN user names
User identifiers are case-insensitive in Windows and Active Directory, and in most POSIX LDAP schemas as well. On the other hand, other operating systems, and SPS in particular, handle user identifiers in a case-sensitive manner.
Consequently, the username strings, which are used for authentication at a remote Windows or AD/LDAP, are case-insensitive. For example, one can specify Administrator, administrator, or even aDMinIstRaTor during login, they are not different from the authentication point of view.
For convenience reasons, search also works in a case-insensitive manner.
However, for the following functions, SPS requires a case exact match:
-
Credential stores
-
Remote authentication (SAML2, Radius, X.509) with a local backend
-
Usermapping policies
-
Local user lists (remote or gateway groups)
For example, if there is a local credential store entry for administrator at a given target server, the user name in the connection must be exactly administrator, even though authentication would succeed with other forms of capitalization as well. Remote credential stores (such as One Identity Safeguard for Privileged Passwords), on the other hand, may accept user names in a case-insensitive manner.
For more information about how case-sensitivity and case matching applies to using the UPN format in usermapping policies, see Using UPN user names in usermapping policies.
Differences in protocols while using UPN user names
Unlike other protocols, RDP allows the explicit specification of the Windows domain during authentication. When the user specifies the target username string as a down-level user name in NetBIOS format, SPS splits the string into an actual username (that is, the part after the \ character) and a domain. In this case, only the actual user name is used for usermapping policies, credential stores, AA plugins and user lists.
As an example, when the username string is specified as DOMAINNAME\example, the usermapping policy requires a record for the actual user name example, and not for the whole username string.
For protocols other than RDP, SPS does not split the username string to username and domain.
NOTE: Historically, SPS versions before 8.0 LTS also split UPN user names to a local username and a domain for the RDP protocol. However, in SPS version 8.0 LTS and later versions, this operation is no longer performed.
For specific information about how differences in protocols affect AA plugins and the UPN format, see UPN user names and AA plugins.
Using UPN user names in usermapping policies
In SPS, you can use the User Principal Name (UPN) format in usermapping policies that let administrators control who can use specific user names at target servers.
For more information about usermapping policies, see Configuring usermapping policies.
When the Ignore UPN suffix in user names option is selected on the SPS web interface (it is selected by default), only the local identifier part (that is, the characters before the @ character) will be used to match the remote user name. This means that if you specify administrator as the remote user name, it will match for administrator@example.domain and administrator@other.domain as well. The session is authorized on the target server side, depending on the target server’s configuration.
If you want to be more specific in allowing which remote users can be used, you can disable the Ignore UPN suffix in user names option. In this case, you have to specify the exact user name in the remote user name. For example, if you have example.domain and other.domain specified as alternate UPN suffixes, and additionally, you want to enable the use of user names in NetBIOS format, you have to add the following three entries to the usermapping policy:
Using UPN user names in groups (user lists)
You can use the UPN format in groups (that is, user lists) in SPS.
For more information about user lists, see Creating and editing user lists.
In SPS, local user lists do not allow specifying the members in UPN format because they can be used as exclusion lists (also known as deny lists), and the exclusion could be easily circumvented by using alternate user name forms. Therefore, when a user name is checked against a local user list, the UPN suffix is always ignored.
User groups managed in AD / LDAP can be used with UPN user names as well.
UPN user names and AA plugins
On the SPS web interface, the ignore_upn_suffix_for_rdp option is used for AA plugins. This option controls how AA plugins receive the username string from SPS, and it is set to true by default.
When the ignore_upn_suffix_for_rdp option is set and the RDP protocol is in use, UPN user names are split into a local username part and a domain part. Otherwise, the domain will be empty and the username string is unchanged.
When the AA plugin is invoked for an RDP session, username strings in the NetBIOS format (that is, in the DOMAIN\username format) are always split into a username and a domain part before being passed to the plugin.
For any other protocols, the username strings are never altered, and the domain part is never set.
One Identity Safeguard for Privileged Sessions (SPS) can authenticate its users to an external RADIUS server. Group memberships of the users must be managed either locally on SPS or in an LDAP database.
|
|
Caution:
The challenge/response authentication method is currently not supported. Use other authentication methods (for example password, SecureID). |
Authenticating SPS users to a RADIUS server
To authenticate SPS users to a RADIUS server, complete the following steps.
-
Navigate to Users & Access Control > Login Options.
-
To configure a RADIUS login method, select one of the following options:
The following figure shows the configuration options of the RADIUS login method.
Figure 80: Users & Access Control > Login options — Configuring RADIUS authentication
-
In the Name field, specify a name for the login option.
-
(Optional) Enable the RADIUS login method.
-
To add a new RADIUS server, click Create new RADIUS server.
-
In the Address field, enter the IP address or domain name of the RADIUS server. Use an IPv4 address or hostname.
-
In the Server port field, enter the port number.
-
In the Shared secret field, enter the password that SPS can use to access the RADIUS server.
NOTE: SPS accepts passwords that are not longer than 150 characters and supports the following characters:
-
Click Save.
-
(Optional) To add more RADIUS servers, click 
and repeat the procedure for adding a new RADIUS server.
If a server is unreachable, SPS tries to connect to the next server in the list in failover mode.
-
Select the authentication protocol.
-
To use the Password Authentication Protocol, select PAP.
-
To use the Challenge-Handshake Authentication Protocol, select CHAP.
-
Select LDAP server or Local as the Authorization Backend.
-
(Optional) To add a new LDAP server, click New LDAP server under Authorization backend and select one of the server types:
-
Script reference is filled out automatically when you specify the name for the login option. Special characters are automatically replaced with dashes ("-"). The Script name is a unique, human readable ID that is used by the REST API clients to select the login method.
-
To save your modifications, click Commit.
|
|
Caution:
After you commit this configuration, the SPS web interface will be available only after successfully authenticating to the RADIUS server. Note that the default admin account of SPS will be able to login normally, even if the RADIUS server is unaccessible. |
