Chat now with support
Chat mit Support

One Identity Safeguard for Privileged Sessions 7.5.1 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS)
The philosophy of One Identity Safeguard for Privileged Sessions (SPS) Policies Credential Stores Plugin framework Indexing Supported protocols and client applications Modes of operation Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) Archive and backup concepts Maximizing the scope of auditing IPv6 in One Identity Safeguard for Privileged Sessions (SPS) SSH host keys Authenticating clients using public-key authentication in SSH The gateway authentication process Four-eyes authorization Network interfaces High Availability support in One Identity Safeguard for Privileged Sessions (SPS) Versions and releases of One Identity Safeguard for Privileged Sessions (SPS) Accessing and configuring One Identity Safeguard for Privileged Sessions (SPS)
Cloud deployment considerations The Welcome Wizard and the first login Basic settings
Supported web browsers The structure of the web interface Network settings Configuring date and time System logging, SNMP and e-mail alerts Configuring system monitoring on SPS Data and configuration backups Archiving Cleaning up audit data Using plugins Forwarding data to third-party systems Starling integration
User management and access control
Login settings Managing One Identity Safeguard for Privileged Sessions (SPS) users locally Setting password policies for local users Managing local user groups Managing One Identity Safeguard for Privileged Sessions (SPS) users from an LDAP database Authenticating users to a RADIUS server Authenticating users with X.509 certificates Authenticating users with SAML2 Managing user rights and usergroups Creating rules for restricting access to search audit data Displaying the privileges of users and user groups Listing and searching configuration changes
Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing One Identity Safeguard for Privileged Sessions (SPS) clusters Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster Upgrading One Identity Safeguard for Privileged Sessions (SPS) Managing the One Identity Safeguard for Privileged Sessions (SPS) license Accessing the One Identity Safeguard for Privileged Sessions (SPS) console Sealed mode Out-of-band management of One Identity Safeguard for Privileged Sessions (SPS) Managing the certificates used on One Identity Safeguard for Privileged Sessions (SPS)
General connection settings HTTP-specific settings ICA-specific settings MSSQL-specific settings RDP-specific settings SSH-specific settings Using Sudo with SPS Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) REST API One Identity Safeguard for Privileged Sessions (SPS) scenarios Troubleshooting One Identity Safeguard for Privileged Sessions (SPS)
Network troubleshooting Gathering data about system problems Viewing logs on One Identity Safeguard for Privileged Sessions (SPS) Changing log verbosity level of One Identity Safeguard for Privileged Sessions (SPS) Collecting logs and system information for error reporting Collecting logs and system information of the boot process for error reporting Support hotfixes Status history and statistics Troubleshooting a One Identity Safeguard for Privileged Sessions (SPS) cluster Understanding One Identity Safeguard for Privileged Sessions (SPS) RAID status Restoring One Identity Safeguard for Privileged Sessions (SPS) configuration and data VNC is not working with TLS Configuring the IPMI from the BIOS after losing IPMI password Incomplete TSA response received Using UPN usernames in audited SSH connections
Using SPS with SPP Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help Configuring SPS to use an LDAP backend Glossary

Adding a new Active Directory server

This section describes how to configure Active Directory (AD) servers.

To create a new Active Directory (AD) server

  1. To create a Microsoft Active directory server, navigate to Users & Access Control > Login options > Manage AD/LDAP Servers, click Add new server and select Active directory.

    Figure 86: Users & Access Control > Login Options > Manage AD/LDAP Servers — Active Directory

  2. In the Name field, enter the server name.

  3. Enter the IP address/hostname and the port of the LDAP server in the respective text boxes.

    Consider the following when specifying the address information:

    • If you want to encrypt the communication between SPS and the LDAP server, use the following port numbers:

      • For TLS, specify 636 as the port number.

      • For STARTTLS, specify 389 as the port number.

    • Use an IPv4 adress or a hostname.

    • To add multiple servers, click and enter the address of the next server. If a server is unreachable, SPS will try to connect to the next server in the list in failover mode.

    • When you configure the location of the LDAP server, that is, the IP address or hostname and the port number, you can use a Service record (SRV record), which is a type of information record in the DNS that maps the name of a service to the DNS name of the server. SRV records have the following format: _ldap._tcp.<SITE_NAME>._sites.dc._msdcs.<DOMAIN.NAME> in the Address field. SPS looks up the SRV record during committing the configuration change.

      For more information on SRV records, see the relevant Microsoft documentation.

    • Caution:

      If you connect to the LDAP server over a TLS-encrypted connection with certificate verification, you must fill the Address field with a name or IP address, which must be present in the certificate.

  4. Configure AD settings.

    • To also check group membership based on group Distinguished Names (DNs) in a user attribute, select Enable checking for group DNs in user objects and enter the name of the user attribute, for example, memberOf in the User attribute of group DNs field.

      Caution:

      If you have too many groups, using this option significantly slows down logging in to the SPS web interface.

      Use this option only if you have an LDAP schema where the user groups can only be determined from a user attribute that contains the group DNs.

    • To enable nested groups, select Enable AD group membership check, then Enable nested groups.

      Caution:

      Nested groups can slow down the query and cause the connection to timeout if the LDAP tree is very large. In this case, disable the Enable nested groups option.

    • To check for group membership based on user DNs in group attributes, use the Check the user DN in these groups option.

      For more information, see Active Directory LDAP backend.

  5. Configure the options of the Distinguished Names field.

    • In the User Base DN field, enter the name of the DN to be used as the base of queries regarding users (for example: OU=People,DC=demodomain,DC=exampleinc).

      NOTE: This field is mandatory. You can use the same value for the User Base DN and the Group Base DN settings.

      To speed up LDAP operations, specify a sufficiently narrow base for the LDAP subtrees where users and groups are stored.

    • In the Group Base DN field, enter the name of the DN to be used as the base of queries regarding groups (for example: OU=Groups,DC=demodomain,DC=exampleinc).

      NOTE: This field is mandatory. You can use the same value for the User Base DN and the Group Base DN settings.

      To speed up LDAP operations, specify a sufficiently narrow base for the LDAP subtrees where users and groups are stored.

    • In the Bind DN field, enter the Distinguished Name that SPS must use to bind to the LDAP directory (for example: CN=Administrator,DC=demodomain,DC=exampleinc).

      NOTE: SPS accepts both pre Windows 2000-style and Windows 2003-style account names, or User Principal Names (UPNs). For example, administrator@example.com is also accepted.

  6. Configure the Set shared secret option.

    To configure or change the password to use when binding to the LDAP server, click Set password, enter the password, and click Update.

    NOTE: SPS accepts passwords that are not longer than 150 characters and supports the following characters:

    • Letters A-Z, a-z

    • Numbers 0-9

    • The space character

    • Special characters: !"#$%&'()*+,-./:;<>=?@[]\^-`{}_|

  7. If you want to encrypt the communication between SPS and the LDAP server, in Encryption, select the TLS or the STARTTLS option and verify the certificate of the server.

    • If you want SPS to verify the certificate of the server, under Certificate requirements, select Trust Store.

      Caution:

      SPS checks if the certificate revocation list (CRL) has expired and that the CRL has been signed by the same certificate authority (CA).

      Caution:

      If you connect to the LDAP server over a TLS-encrypted connection with certificate verification, you must fill the Address field with a name or IP address, which must be present in the certificate.

    • If the LDAP server requires mutual authentication, that is, it expects a certificate from SPS, enable Authenticate as a client. Generate and sign a certificate for SPS, upload the certificate and its private key, and click Save.

    TIP: One Identity recommends using 2048-bit RSA keys (or stronger).

  8. To save your modifications, click Commit.

    NOTE: You must configure the usergroups in SPS, and possibly in your LDAP database. For details on using usergroups, see Using usergroups.

Adding a new POSIX LDAP server

This section describes how to configure POSIX LDAP servers.

To create a new POSIX LDAP server

  1. To create a POSIX LDAP server, navigate to Users & Access Control > Login options > Manage AD/LDAP Servers, click Add new server and select POSIX LDAP.

    Figure 87: Users & Access Control > Login Options > Manage AD/LDAP Servers — POSIX LDAP

  2. In the Name field, enter the server name.

  3. Enter the IP address/hostname and the port of the LDAP server in the respective text boxes.

    Consider the following when specifying the address information:

    • If you want to encrypt the communication between SPS and the LDAP server, use the following port numbers:

      • For TLS, specify 636 as the port number.

      • For STARTTLS, specify 389 as the port number.

    • Use an IPv4 adress or a hostname.

    • To add multiple servers, click and enter the address of the next server. If a server is unreachable, SPS will try to connect to the next server in the list in failover mode.

    • When you configure the location of the LDAP server, that is, the IP address or hostname and the port number, you can use a Service record (SRV record), which is a type of information record in the DNS that maps the name of a service to the DNS name of the server. SRV records have the following format: _ldap._tcp.<SITE_NAME>._sites.dc._msdcs.<DOMAIN.NAME> in the Address field. SPS looks up the SRV record during committing the configuration change.

      For more information on SRV records, see the relevant Microsoft documentation.

    • Caution:

      If you connect to the LDAP server over a TLS-encrypted connection with certificate verification, you must fill the Address field with a name or IP address, which must be present in the certificate.

  4. Configure POSIX settings.

    If your LDAP server uses a custom POSIX LDAP scheme, you might need to set which LDAP attributes store the username, or the attributes that set group memberships. For example, if your LDAP scheme does not use the uid attribute to store the usernames, set the Username (user ID) attribute name option.

    In addition to the primary group membership checking, you can allow checking for supplementary group memberships by selecting Enable POSIX group membership check and specifying the POSIX group membership attribute name field.

    To also check group membership based on group Distinguished Names (DNs) in a user attribute, select Enable checking for group DNs in user objects. Then, enter the name of the user attribute (for example, memberOf) in the User attribute of group DNs field, and objectClass (for example, groupOfNames) in the Group objectClass field.

    Caution:

    If you have too many groups, using this option significantly slows down logging in to the SPS web interface.

    Use this option only if you have an LDAP schema where the user groups can only be determined from a user attribute that contains the group DNs.

    To check for group membership based on user DNs in group attributes, use the Check the user DN in these groups option.

    For more information, see POSIX LDAP backend.

    For an overview about LDAP user and group resolution in SPS, see Overview.

  5. Configure the options of the Distinguished Names field.

    • In the User Base DN field, enter the name of the DN to be used as the base of queries regarding users (for example: OU=People,DC=demodomain,DC=exampleinc).

      NOTE: This field is mandatory. You can use the same value for the User Base DN and the Group Base DN settings.

      To speed up LDAP operations, specify a sufficiently narrow base for the LDAP subtrees where users and groups are stored.

    • In the Group Base DN field, enter the name of the DN to be used as the base of queries regarding groups (for example: OU=Groups,DC=demodomain,DC=exampleinc).

      NOTE: This field is mandatory. You can use the same value for the User Base DN and the Group Base DN settings.

      To speed up LDAP operations, specify a sufficiently narrow base for the LDAP subtrees where users and groups are stored.

    • In the Bind DN field, enter the Distinguished Name that SPS must use to bind to the LDAP directory (for example: CN=Administrator,DC=demodomain,DC=exampleinc).

      NOTE: SPS accepts both pre Windows 2000-style and Windows 2003-style account names, or User Principal Names (UPNs). For example, administrator@example.com is also accepted.

  6. If you want to encrypt the communication between SPS and the LDAP server, in Encryption, select the TLS or the STARTTLS option and verify the certificate of the server.

    • If you want SPS to verify the certificate of the server, under Certificate requirements, select Trust Store.

      Caution:

      SPS checks if the certificate revocation list (CRL) has expired and that the CRL has been signed by the same certificate authority (CA).

      Caution:

      If you connect to the LDAP server over a TLS-encrypted connection with certificate verification, you must fill the Address field with a name or IP address, which must be present in the certificate.

    • If the LDAP server requires mutual authentication, that is, it expects a certificate from SPS, enable Authenticate as a client. Generate and sign a certificate for SPS, upload the certificate and its private key, and click Save.

    TIP: One Identity recommends using 2048-bit RSA keys (or stronger).

  7. To save your modifications, click Commit.

    NOTE: You must configure the usergroups in SPS, and possibly in your LDAP database. For details on using usergroups, see Using usergroups.

Overview

Access control in SPS is based on groups. Whenever a user needs to access a protected resource, like navigating to a configuration page on the SPS web interface, or opening a channel in a connection, SPS checks the access control list associated with the resource in question.

The access control lists grant access to groups. Therefore, SPS needs to determine which groups the user is a member of to evaluate the access rules.

When you configure SPS to use an LDAP backend, SPS will:

  1. Identify the user. For more information, see User identification below.

  2. Determine the relevant groups the user is a member of. For more information, see Group membership resolution below.

User identification

SPS works with plain usernames, for example, administrator. This must be unambiguously resolved to an LDAP user object in order to determine the user’s groups. If a user identification returns multiple results, SPS treats this as an error, and access to the user in question is denied.

Only the user object returned in this phase is used for group membership checks, and not the original plain username.

User resolution depends on the type of the backend (POSIX or Active Directory).

For more information, see the backend-specific sections below.

Group membership resolution

SPS works with plain group names, for example, superusers. For group membership checks, SPS looks up a relevant group object in LDAP and checks if the user object returned during user identification is a member of that group. Since some of the group object’s attributes are always used for group membership checks, the group object must also exist in LDAP.

Group membership resolution depends on the LDAP backend type.

For more information, see the backend-specific sections below.

Common to all backends

All backends have configurable parameters relevant for user identification and group membership:

  • bind_dn and bind_password: Bind DN and Bind password are used for user identification and group membership check during authentication to the LDAP database. If you leave it empty, SPS will try to bind anonymously.

  • user_base_dn: User Base DN is where SPS searches for users.

  • group_base_dn: Group Base DN is where SPS searches for groups. Only groups under this base are considered for membership.

  • memberof_check: the Enable checking for group DNs in user objects setting allows checking a configurable attribute in the user object. This attribute contains a list of group DNs the user is additionally a member of. This user attribute is usually memberOf. For more information, see the backend-specific sections below.

  • user_dn_in_groups: Check the user DN in these groups is a list of additional group object classes and their respective attributes where SPS will look for member user DNs. For more information, see the backend-specific sections below.

All comparisons and searches are done by SPS in a way that plain user and group names are matched with attribute values by the LDAP server. As a result, user and group names are case insensitive if and only if the matching rule for the attribute in question is case insensitive in the LDAP database.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen