지금 지원 담당자와 채팅
지원 담당자와 채팅

One Identity Safeguard for Privileged Sessions 7.5 - 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

Using usergroups

How you should name usergroups depends on the way you manage your One Identity Safeguard for Privileged Sessions (SPS) users.

  • Local users: If you use only local users, create or modify usergroups on the Users & Access Control > Local User Groups page, assign or modify privileges on the Users & Access Control > Appliance Access page, and add users to the groups on the Users & Access Control > Local Users or the Users & Access Control > Local User Groups page.

  • LDAP users and LDAP groups: If you manage your users from LDAP, and also have LDAP groups that match the way you want to group your SPS users, create or modify your usergroups on the Users & Access Control > Appliance Access page and ensure that the name of your LDAP group and the SPS usergroup is the same. For example, to make members of the admins LDAP group be able to use SPS, create a usergroup called admins on the Users & Access Control > Appliance Access page and edit the privileges of the group as needed.

  • RADIUS users and local groups: This is the case when you manage users from RADIUS, but you cannot or do not want to create groups in LDAP. Create your local groups on the Users & Access Control > Appliance Access page, and add your RADIUS users to these groups on the Users & Access Control > Local User Groups page.

Built-in usergroups of One Identity Safeguard for Privileged Sessions (SPS)

One Identity Safeguard for Privileged Sessions (SPS) has the following usergroups by default. Note that you can modify and delete these usergroups as you see fit.

Figure 97: Users & Access Control > Appliance Access — Built-in usergroups of SPS

 Caution:

If you use LDAP authentication on the SPS web interface and want to use the default usergroups, you have to create these groups in your LDAP database and assign users to them. For details on using usergroups, see Using usergroups.

  • basic-view: View the settings in the Basic Settings menu, including the system logs of SPS. Members of this group can also execute commands on the Troubleshooting tab.

  • basic-write: Edit the settings in the Basic Settings menu. Members of this group can manage SPS as a host.

  • auth-view: View the names and privileges of the SPS administrators, the configured usergroups, and the authentication settings in the Users & Access Control menu. Members of this group can also view the history of configuration changes.

  • auth-write: Edit authentication settings and manage users and usergroups.

    		 Caution:

    Members of the auth-write group, or any other group with write privileges to the Users & Access Control menu are essentially equivalent to system administrators of SPS, because they can give themselves any privilege. Users with limited rights should never have such privileges.

    If a user with write privileges to the Users & Access Control menu gives himself new privileges (for example gives himself group membership to a new group), then he has to relogin to the SPS web interface to activate the new privilege.

  • search: Browse and download various logs and alerts in the Sessions menu. The members of this group have access to the audit trail files as well. Note that to open encrypted audit trail files, the proper encryption keys are required.

  • changelog: View the history of SPS configuration changes in the Users & Access Control > Configuration History menu.

  • report: Browse, create and manage reports, and add statistics-based chapters to the reports in the Reports menu. Users with this privilege can access every report. To grant access to users only to specific reports, use the Reports are accessible by the following groups option of the report. For details, see Configuring custom reports.

    NOTE: To control exactly which statistics-based chapters and reports can the user include in a report, use the Use static subchapters privileges.

  • policies-view: View the policies and settings in the Policies menu.

  • policies-write: Edit the policies and settings in the Policies menu.

  • ssh-view: View all connection and policy settings in the Traffic Controls > SSH menu.

  • ssh-write: Edit all connection and policy settings in the Traffic Controls > SSH menu.

  • rdp-view: View all connection and policy settings in the Traffic Controls > RDP menu.

  • rdp-write: Edit all connection and policy settings in the Traffic Controls > RDP menu.

  • telnet-view: View all connection and policy settings in the Traffic Controls > Telnet menu.

  • telnet-write: Edit all connection and policy settings in the Traffic Controls > Telnet menu.

  • vnc-view: View all connection and policy settings in the Traffic Controls > VNC menu.

  • vnc-write: Edit all connection and policy settings in the Traffic Controls > VNC menu.

  • indexing: Allows hosts running external indexers to access and download audit trails for automatic indexing. Note that the members of this group can access the SPS web interface as well, and download any audit trail directly.

  • ica-view: View all connection and policy settings in the Traffic Controls > ICA menu.

  • ica-write: Edit all connection and policy settings in the Traffic Controls > ICA menu.

  • http-view: View all connection and policy settings in the Traffic Controls > HTTP menu.

  • http-write: Edit all connection and policy settings in the Traffic Controls > HTTP menu.

  • indexer-view: View all connection and policy settings in the Indexer menu.

  • indexer-write: Edit all connection and policy settings in the Indexer menu.

Creating rules for restricting access to search audit data

If you want users to access audit data on the Search interface only for sessions for which they are granted permission, complete the following steps.

To be able to see the Audit Data Access menu item and use this functionality, you must enable the REST ACL check box as described below.

  1. Navigate to Users & Access Control > Appliance Access.

  2. Click Edit.

  3. Expand REST server.

  4. Select the REST ACL check box.

Figure 98: Users & Access Control > Appliance Access — Select REST ACL

The following describes how you can create rules to restrict the search by providing access privileges for users to audit data.

Prerequisites

  1. You have created a local user group as described in Managing local user groups.

  2. You have added search access rights to your local user group as described in Assigning privileges to user groups for the One Identity Safeguard for Privileged Sessions (SPS) web interface.

    NOTE: Ensure that you clear the Search in all connections check box as shown below.

    Figure 99: Users & Access Control > Appliance Access — Add search access rights to local user groups

  3. You have created a local user, and added the user to the local user group. For more information, see Managing user rights and usergroups.

To create search rules to access audit data

  1. If you have multiple SPS appliances and they are organized into a cluster where one of the nodes is the Search Master (or Central Search) node, log in to that node.

  2. Navigate to Users & Access Control > Audit Data Access.
  3. Click Create new.

    Figure 100: Users & Access Control > Audit Data Access — Create new audit data access rule (ADAR)

  4. In the Name field, enter a name for your rule.
  5. In the Groups field, enter an existing local user group for which you want to restrict access to audit data.
  6. In the Query field, enter the correct query syntax to define which audit data this user group can access.

  7. Optionally, for a quick visualization of the audit data that each group can access with this search query, click Preview.

    TIP: If required, modify the query syntax using the Query field, and the preview is updated accordingly.

Example: Restrict access to search audit data for a user

You want a user to access audit data on the Search interface related to the SSH protocol only.

  1. Create a local user group, for example, search-only-ssh as described in Managing local user groups.

  2. Add search access rights to your search-only-ssh user group as described in Assigning privileges to user groups for the One Identity Safeguard for Privileged Sessions (SPS) web interface.

    NOTE: Ensure that you clear the Search in all connections check box.

    Figure 101: Users & Access Control > Appliance Access — Add search access rights to local user groups

  3. Create an audit data access rule (ADAR) for the search-only-ssh user group. Use the correct query syntax, for example, protocol: SSH.

    Figure 102: Users & Access Control > Audit Data Access — Create new rule

    Optionally, for a quick visualization of the audit data that the search-only-ssh group can access with this search query, click Preview.

  4. Create a local user, and add the user to the search-only-ssh group. For more information, see Managing user rights and usergroups.

Result: Your local user will have access to audit data related to the SSH protocol only on the Search interface.

Figure 103: Sessions — Only SSH audit data is displayed for the user

Displaying the privileges of users and user groups

One Identity Safeguard for Privileged Sessions (SPS) version 3.2 and later provides an interface to query the user-rights and privileges of individual users and user groups. To display the privileges of a user or usergroup, navigate to Users & Access Control > Access Rights Report, enter the name of the user or group into the respective field, then click Filter. Note that:

  • It is not possible to filter on both the username and the group at the same time.

  • Partial matches are also displayed.

  • Usergroups can be local usergroups, userlists, or LDAP usergroups.

Web interface permissions

For usergroups accessing the SPS web interface, a table is displayed that lists the pages of the SPS web interface that the user or usergroup can access. The following information is displayed:

  • Page: The name of the page or group of pages, for example, Basic Settings.

  • Element: If a group has access only to a section of a page, the name of the element is listed here. For example, a particular Channel Policy.

  • Group: The name of the usergroup.

  • Permission: The type of access that the user or usergroup has to the page: read or read and write/perform.

Figure 104: Users & Access Control > Access Rights Report — Displaying web interface permissions

Connection permissions

To review which servers a user or usergroup can access, SPS collects the main information about the connections the user or group is permitted to use. The following information is displayed.

NOTE: To display the usergroups that can access a specific Connection Policy, open the Connection Policy, then on the Connections page, select Show connection permissions > Show.

Figure 105: Users & Access Control > Connection permissions — Displaying connection permissions

  • Gateway group: Lists the group memberships required to access the connection. Group memberships can be restricted at the following places:

    • Connection > Gateway authentication > Groups

    • Channel Policies > Gateway group

    • Policies > Usermapping Policies > Groups

  • Source: Refers to the following field from the session database:

    Source IP: The IP address of the client.

  • To: Refers to the following field from the session database:

    Destination IP: The IP address of the server as requested by the client.

  • To port: Refers to the following field from the session database:

    Destination port: The port number of the server as requested by the client.

  • Target: Refers to the following field from the session database:

    Server IP: The IP address of the server connected by SPS.

  • Target port: Refers to the following field from the session database:

    Server port: The port number of the server connected by SPS.

  • Remote user: Refers to the following field from the session database:

    Username on server: The username used to log in to the remote server. This username can differ from the client-side username if usermapping is used in the connection. For details on usermapping, see Configuring usermapping policies.

  • Remote group: The group that can access the destination server, as set in the Usermapping Policy (if any).

  • Protocol: The protocol used in the connection (Citrix ICA, HTTP, RDP, SSH, Telnet, or VNC).

  • Connection: Refers to the following field from the session database:

    Connection policy ID: The identifier of the connection policy.

  • Authorizer: Refers to the following field from the session database:

    Four-eyes authorizer: The username of the user who authorized the session. Available only if 4-eyes authorization is required for the channel. For details on 4-eyes authorization, see Configuring four-eyes authorization.

  • Auth type: The authentication method used in the client-side connection during gateway authentication.

  • Channel: The type of the channel, for example, session-shell.

  • Time: The name of the Time Policy used in the connection.

  • LDAP: The name of the LDAP Server used in the connection (if any).

  • Credential store: The name of the Credential Store used in the connection (if any).

  • Audit: Indicates if the connection is recorded into audit trails.

Usergroup memberships

When searching for users, the table displays the group memberships of the matching users. When searching for usergroups, the table displays the members of the matching groups. The following information is displayed:

  • User: The username of the user.

  • Group: The name of the usergroup or userlist.

  • Exception: Usernames that are denied in case of default-deny userlists managed locally on SPS.

Figure 106: Users & Access Control > Connection permissions — Displaying usergroup and userlist memberships

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택