Chat now with support
Chat with Support

One Identity Safeguard for Privileged Passwords 2.9 - Administration Guide

Introduction System requirements Using the virtual appliance and web management console Installing the desktop client Setting up Safeguard for Privileged Passwords for the first time The console Navigation pane Privileged access requests Toolbox Accounts Account Groups Assets Asset Groups Discovery Entitlements Partitions Settings
Access Request settings Appliance settings Asset Management settings Backup and Retention settings Certificate settings Cluster settings External Integration settings Messaging settings Profile settings Safeguard Access settings Sessions settings
Users User Groups Disaster recovery and clusters Administrator permissions Preparing systems for management Troubleshooting Frequently asked questions Appendix A: Safeguard ports Appendix B: SPP 2.7 or later migration guidance Appendix C: SPP and SPS join guidance Appendix D: Historical changes by release Glossary

Appendix A: Safeguard ports

Safeguard for Privileged Passwords requires port availability for various system operations.

Port details

Safeguard network port details are in the following table.

Table 221: Safeguard ports

Use in SPP

Appliance Port

Protocol

Description

 

 MGMT

TCP

HTTPS used for a secure first-time configuration of the appliance. The IP address is a fixed address that cannot be changed. It is available in case the primary interface becomes unavailable.

Typically used: TCP/443 and IP address: 192.168.1.105.

Base operation

25

TCP

SMTP: Simple Mail Transfer

Base operation

53

TCP / UDP

DNS (Domain Name Server)

Base operation

123

 

NTP time synchronization

Base operation (AD Asset and Account Discovery, password check and change)

389

TCP

LDAP used for Active Directory Asset Discovery and Directory Accounts Discovery. The standard global catalog port, 3268 (LDAP), must be open on the firewall for every Windows global catalog server in the environment and SPP Appliance to communicate for directory management tasks (for example, adding a directory account, a directory user account, or a directory user group). LDAP uses port 389 for unencrypted connections. For more information, see the Microsoft publication How the Global Catalog Works.

For basic functionality when changing an OS account password, the following ports are required:

  • Windows Active Directory: TCP/389 and TCP/445
  • Windows, Windows Desktop: TCP/445

Also see:

Base operation (password check and change)

445

TCP SMB

NetLogon Service (NP-In) is used to perform password check and changes for Windows Active Directory and Windows, Windows Desktop. Also see port 389 and Prepare Windows systems

LDAPS 636   Supported for non-AD LDAP providers. The default LDAPS port is 636. Port 636 needs to be open to use LDAPS for non-AD LDAP providers.

WMI

135

(49152-

65535

Windows)

TCP

The firewall must be configured to allow WMI (Windows Management Instrumentation) for computer name and other lookups. WMI is also required if SPP performs any of the functions listed below on any Windows machine (whether it be a dependent system or a normal target platform):

  • Managing service account passwords
  • Managing scheduled task passwords
  • Restarting a service
  • Using Account Discovery on the target
  • Recording using embedded sessions

WMI / DCOM from DPA will need access to TCP/135 to initiate communication on the target. The conversation continues on a random negotiated port. On Windows 7 and Windows 2008 (and above) this is in the range: 49152 - 65535.

To limit the ports used by WMI/DCOM, refer to these Microsoft articles:

For Windows Active Directory, if using Account Discovery or Auto Discovery CLDAP ping UDP/389 is also required. See:

WMI

49152-65535

 

See port 135

Archiving

22

TCP (X0)

The Secure Shell (SSH) Protocol for SFTP/SCP transfers backups and session recordings to the archive server for the SPP embedded sessions module.

See:

Embedded sessions

22 and 3389

TCP (X1)

RDP (3389/TCP) is permitted inbound for PSM RDP sessions (SPP embedded sessions module). Users who will use the embedded session require access to the cluster X1 ports on port 3389 to make an RDP connection to the target system and to port 22 for SSH connections. See: KB article 262371.

SPP/SPS internal communications

8649

TCP

Used for the SPP/SPS internal communications when SPS is joined with SPP.

  • SPS to SPP:
    • SPS completes the join by talking to SPP on port 8649.
    • SPS authenticates a new session and acquires the password from SPP by talking on port 8649.
    • SPS queries SPP for cluster information and the appliance version.
  • SPP to SPS:
    • SPP queries SPS for cluster information and node roles.
    • SPP pushes SSH host keys to SPS when a session is initiated.
    • SPP queries SPS for session playback, follow mode, and session termination.

In SPS, the nodes require UDP ports 500 and 4500 and TCP 8649. For the latest detail, see the SPS Administration Guide, Enabling cluster management.

Firewall

655

TCP / UDP (X0)

TINC (655) is open for secure VPN communication between appliances in a clustered high-availability configuration. TINC perfers UDP and uses TCP if UDP is unreliable. See KB article 232671.

To enroll an appliance into a cluster, the appliance must communicate over port 655 UDP/TCP and port 443 TCP and must have IPv4 or IPv6 network addresses (not mixed). See:

Firewall and Client and Web browser points

443

TCP

(X0)

HTTPS over TLS/SSL (443/TCP) permits inbound requests (for client/Web/API access). Used to initially log on to the appliance to join the cluster member. Users must have access to the cluster X0 ports on port 443.

To enroll an appliance into a cluster, the appliance must communicate over port 655 UDP/TCP and port 443 TCP and must have IPv4 or IPv6 network addresses (not mixed). See:

The port is used to prepare VMware ESXi host. See:

Global catalog

3268

 

The LDAP standard global catalog port for Active Directory. The standard global catalog port, 3268 (LDAP), must be open on the firewall for every Windows global catalog server in the environment and SPP Appliance to communicate for directory management tasks (for example, adding a directory account, a directory user account, or a directory user group). LDAP uses port 389 for unencrypted connections. For more information, see the Microsoft publication How the Global Catalog Works. Also see:

There are no services listening for this port on a member/server workstation (local configuration).

SQL server

1433

 

The port on which the SQL server will be listening for connections. See information related to authenticating an asset, Password (local service account).

Radius server

1812

 

Default port number that a Radius server uses to listen for authentication requests. See Adding identity and authentication providers.

Kiosk

DB9

SERIAL

To connect to the Safeguard Kiosk. See KB article 233584.

 

23

TCP

Telnet

 

8443

TCP/ UDP

For SonicWALL SMA or CMS appliance. See information related to authenticating an asset, Password (local service account).

Platform ports

ACF2 – 23

ACF2 LDAP – 389

AIX – 22

AWS – 443

Cent OS – 22

Cisco Pix – 22

Debian – 22

IDRAC – 22

ESXi - 443 default

F5 - 22 default

Facebook (deprecated) - 443

Fortinet – 22 default

Free BSD – 22

HP iLO

IBM i – 23

JunOS – 22

MongoDB - https://docs.mongodb.com/manual/reference/default-mongodb-port/

MySQL – 3306

Oracle – 1521

Oracle Linux – 1521

OSX – 22

Other – no default port

Other Linux – 22

Pan OS – 22

PostgreSQL – 5432 default

RACF – 23

RACF LDAP – 389

RHEL – 22

SAP Hana – 39013 default

SAP Netweaver – 3300

Solaris – 22

SoniOS – 22

SonicWall SMA – 22

SQL – 1433

SUSE – 22

SyBase – 5002

Top Secret – 23

Top Secret LDAP – 389

Twitter (deprecated) – 443

Ubuntu – 22

Windows (various depanding on OS type) – 135/389/445 and maybe dynamic ports

Archiving

Archiving uses uses SFTP/SCP and CIFS.

  • SFTP/SCP: 22 TCP (X0). See the Port details table, 22 for X0.
  • CIFS: Uses UDP ports 137 and 138 and TCP ports 139 and 445.
Backup

Same as Archiving.

External Authentication

Federation – Port 443

Secondary Auth – Radius Port 1812

Starling - Port 443

External Integration

SNMP – Port 162 UDP

SMTP - Port 25 TCP Simple Mail Transfer

SysLog – 514 UDP

External Integration for Password Workflow

Approval Anywhere - 443

Ticketing – ServiceNow 443

Ticketing - Remedy 1433 (communicates to the SQL server directly)

Other

NTP – port 123 UDP

Directories – Ports 389 LDAP and 3268 global catalog

Appendix B: SPP 2.7 or later migration guidance

Appendix C: SPP and SPS join guidance

CAUTION: The embedded sessions module in Safeguard for Privileged Passwords version 2.7 (and later) will be removed in a future release (to be determined). For uninterrupted service, organizations are advised to join to the more robust Safeguard for Privileged Sessions Appliance for sessions recording and playback.

Safeguard for Privileged Passwords version 2.7 introduced the ability to join Safeguard for Privileged Sessions for session recording and auditing.

The Asset Administrator can join a Safeguard for Privileged Sessions (SPS) cluster to a Safeguard for Privileged Password (SPP) cluster of one appliance or more for session recording and auditing. The actual join must be between the SPP primary and the SPS cluster master. This means that the Safeguard for Privileged Sessions (SPS) cluster is aware of each node in an SPP cluster and vice-versa.

Once joined, all sessions are initiated by the SPP appliance via an access request and managed by the SPS appliance and sessions are recorded via the Sessions Appliance.

Session recording, playback, and storage after the join
  • Sessions recorded after the join are playable through SPP and are stored on the SPS appliance. An archive server can be set up through SPS.
  • Sessions recorded prior to joining the Safeguard Sessions Appliances are not migrated to the SPS appliance. For that reason, it is recommended that the SPP sessions be migrated to an archive server prior to the join.
Functionality in SPS after the join

The following functionality handled in SPP's user interface is available in SPS after the join.

  • Session certificate assignment is handled by SPS. The certificate is available for audit by the Auditor.
  • After the join, you will set the following configurations in SPS. There is no migration of the SPP settings added via Administrative Tools | Entitlements | Access Request Policies | Session Settings. These include:
    • Session recording
    • SSH related command detection and controls (such as SFTP, SCP, and X11 forwarding)
    • RDP related command detection and controls (such as Windows title detection and allowing the clipboard)
  • In SPS, you will set the SSH banner text that is shown to session users when they initiate a privileged session notifying them the session will be recorded.
  • In SPS, you will identify the SSH host key presented to the user's SSH client when an SSH session is started.
  • In SPS, you will identify the status of the session module, such as session module health.
  • In SPS, you can edit the default policy.
Functionality in SPP after the join
  • During the join, SPP sets the SPS Connection Policy to safeguard_default for SSH or RDP, as appropriate and may need to be changed. This default is nothing more than SSH or RDP connection policy.
  • Other configuration set via the Access Request Policies dialog, are not affected by the join. These include: General, Scope, Requester, Approver, Reviewer, Access Config, Time Restrictions, and Emergency tabs.
  • The Activity Center shows all old sessions and new sessions per the configuration. You can playback a session from SPP. However, the session index which makes the privileged users' activity searchable is only available from SPS.
  • Entitlement reports have not changed.
  • On the Dashboard, administrators can still view and manage access requests and accounts failing tasks as usual.
  • After the join, Administrative Tools | Settings | Sessions functionality is no longer available and is handled via SPS. This includes session recording management, sessions module, SSH banner, and SSH host key.
Step 1: Prepare for the join

Move all session recording files from Safeguard for Privileged Passwords to an archive server.

  1. Move the SPP embedded sessions recordings from local SPP to an archive server.
    • If the join is complete, use the API to archive existing SPP sessions.

      1. Use the API PUT Core/v2/SessionArchiveConfigs/{id}. Call this API giving it the id of the archive server (GET Core/v2/ArchiveServers) and the id of the appliance (GET Core/SessionArchiveConfigs). Calling the above POST API will assign an archive server to archive session recordings. Within a few minutes, all remaining recordings will be moved to the archive server and removed from the local SPP storage.
      2. Test the playback of a recording stored on the archive server. You will need to download it before you can play it. For more information, see Replaying a session.
  2. Ensure the join is performed when open access requests are not pending, if possible.

    When the SPS session connection is joined, open access requests are automatically closed. When you double-click the event in the Activity Center, the event details Action is Evicted.

  3. Back up your appliances and archive servers. For more information, see Backup and Retention settings.
Step 2: Join SPS and SPP

The join is initiated from Safeguard for Privileged Sessions. For details about the join steps and issue resolution, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions - Technical Documentation.

Pay attention to the roles assigned to the SPS nodes. The following caution is offered to avoid losing session playback from SPP.

CAUTION: Do not switch the role of an SPS node from the Search Local role to Search Minion role. If you do, playback of the sessions recorded while in the Search Local role may not be played back from the SPP appliance and may only be played back via the SPS web user interface. Recordings made with the node in Search Minion role are pushed to the Search Master node and are available for download to SPP. For details about SPS nodes and roles, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions - Technical Documentation.

Step 3: Perform post join activities in SPP and SPS

Perform these steps in SPP:

  1. The Appliance Administrator assigns the managed networks for sessions management.

    Navigate to Administrative Tools | Settings | Cluster | Managed Networks. For more information, see Managed Networks.

  2. The Appliance Administrator can view, delete, or edit join connections, as needed.

    Go to Administrative Tools | Settings | Cluster | Session Appliances. For more information, see Session Appliances with SPS join.

    If you soft delete a session connection then reconnect, the access policies remain available. If you hard delete, the Policy Administrator will need to rejoin and reestablish the SPS Connection Policy via Administrative Tools | Entitlements | Access Request Policies | Session Settings. For more information, see Connection deletion: soft delete versus hard delete.

  3. The Policy Administrator identifies the session settings on the entitlements access request policy.

    Perform the following steps to ensure each policy's session setting is correctly assigned.

    1. Navigate to Administrative Tools | Entitlements, select an entitlement, and open Access Request Policies.
    2. Double-click a policy, or select a policy and click Edit Access Policy.
    3. On the Session Settings tab, go to the SPS Connection Policy. The IP address of the cluster master is displayed first followed by the SPS cluster description: safeguard_default.

    4. If needed, select the cluster or appliance to which the policy applies.

      For more information, see Session Settings tab on page 1.

  4. While on the Access Request Policies dialog, the Policy Administrator checks any other tabs, as needed. The join does not affect the settings on the tabs including the General, Scope, Requester, Approver, Reviewer, Access Config, Time Restrictions, and Emergency tabs.

In SPS:

Complete any set up in SPS required (such as setting up an archive server, the SSH banner, the SSH host key, and SSH or RDP related command detection and controls). For details, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions - Technical Documentation. :

Standard operating procedure after the initial join

If you add another SPS cluster after the initial join, follow these standard operating procedures:

  1. Add join connections. For more information, see Session Appliances with SPS join.
  2. Identify the session settings on the entitlements access request policy (SPS Connection Policy which is the IP address of the cluster master). For more information, see Creating an access request policy.
  3. Assign the managed networks. For more information, see Managed Networks.
Reversing the join

CAUTION: It is not recommended to reverse the join. However, if you were using the embedded session prior to the join, you can return to the embedded sessions module via a factory reset or restoring the backup taken before the join. For more information, see Reversing the SPP to SPS join.

Appendix D: Historical changes by release

IMPORTANT: The following feature update information is relevant only for the designated release.

Related Documents