Converse agora com nosso suporte
Chat com o suporte

One Identity Safeguard for Privileged Passwords 7.4 - Administration Guide

Introduction System requirements and versions Using API and PowerShell tools Using the virtual appliance and web management console Cloud deployment considerations Setting up Safeguard for Privileged Passwords for the first time Using the web client Home page Privileged access requests Appliance Management
Appliance Backup and Retention Certificates Cluster Global Services External Integration Real-Time Reports Safeguard Access Appliance Management Settings
Asset Management
Account Automation Accounts Assets Partitions Discovery Profiles Tags Registered Connectors Custom platforms Importing objects
Security Policy Management
Access Request Activity Account Groups Application to Application Cloud Assistant Asset Groups Entitlements Linked Accounts User Groups Security Policy Settings
User Management Reports Disaster recovery and clusters Administrator permissions Preparing systems for management Troubleshooting Frequently asked questions Appendix A: Safeguard ports Appendix B: SPP and SPS join guidance Appendix C: Regular Expressions

Why did the password or SSH key change during an open request

There are three ways a password or SSH key can change while a user has it checked out.

  1. An Asset Administrator manually changes the password or SSH key. See: Checking, changing, or setting an account password or Checking, changing, or setting an SSH key.
  2. A profile was scheduled to automatically change the password or SSH key. See: Change Password or Change SSH Key settings.
  3. A policy allows both simultaneous access and requires that the password or SSH key change when a user checks it in.

If the password or SSH key changes while a user has it checked out, and the current request is still valid, the user can select either Copy or Show Password or Show SSH Key again to obtain the new password.

Appendix A: Safeguard ports

SPP requires port availability for various system operations.

Port details

Safeguard network port details are in the following table.

Table 234: 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

88

TCP / UDP

For communication with Active Directory, Safeguard uses port 88 (for example, Kerbos authorization against Active Directory).

Base operation:
AD Asset and Account Discovery, password check and change

389

TCP / UDP

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 and SSH key check and change)

 445

TCP SMB

NetLogon Service (NP-In) is used to perform:

  • Password check and changes for Windows Active Directory
  • Password and SSH key check and changes for Windows, Windows Desktop.

Also see port 389 and Preparing 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 Windows Management Instrumentation (WMI) 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

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

SPP/SPS internal communications

8649

TCP

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

  • SPS to SPP:
    • SPS completes the link 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

UDP (X0)

WireGuard (655) is open for secure VPN communication between appliances in a clustered high-availability configuration.

To enroll an appliance into a cluster, the appliance must communicate over port 655 UDP and port 443 TCP, and must have IPv4 or IPv6 network addresses (not mixed). If both IPv4 and IPv6 are available for the connection then IPv6 will be used. 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 and port 443 TCP, and must have IPv4 or IPv6 network addresses (not mixed). If both IPv4 and IPv6 are available for the connection then IPv6 will be used. 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).

Kiosk

 DB9

SERIAL

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

Radius server

1812

 

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

SonicWALL SMA or CMS appliance

8443

TCP / UDP

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

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).

Telnet

23

TCP

Telnet

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

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 – port is not supported for the platform

Other Managed - port is not supported for the platform

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

Ubuntu – 22

Vcenter Server – 22, 443

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, appliance port 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 and SSH key Workflow

Cloud Assistant - 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 and SPS join guidance

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

Once linked, all sessions are initiated by the SPP appliance via an access request and managed by the Safeguard for Privileged Sessions appliance and sessions are recorded via the Sessions Appliance.

CAUTION: When linking your Safeguard for Privileged Sessions (SPS) deployment to your SPP (SPP) deployment, ensure that the SPS and SPP versions match exactly, and keep the versions synchronized during an upgrade. For example, you can only link SPS version 6.6 to SPP version 6.6, and if you upgrade SPS to version 6.7, you must also upgrade SPP to 6.7.

Make sure that you do not mix Long Term Supported (LTS) and feature releases. For example, do not link an SPS version 6.0.1 to an SPP version 6.1.

NOTE: If you have a single node Safeguard for Privileged Sessions cluster where the Central Management node is also the Search Master, SPP will be unable to launch sessions. There has to be at least one Safeguard for Privileged Sessions appliance in the cluster that is capable of recording sessions. See the One Identity Safeguard for Privileged Sessions Administration Guide, Managing Safeguard for Privileged Sessions (SPS) clusters.

Additional overview information can be found in the One Identity Safeguard for Privileged Sessions Administration Guide, Using SPS with SPP.

NOTE: Configuration options and details related to Safeguard for Privileged Sessions will only be visible to customers that have purchased and joined the product to One Identity Safeguard for Privileged Passwords.

Session recording, playback, and storage after the link
  • Sessions recorded after the link are playable through SPP and are stored on the Safeguard for Privileged Sessions appliance. An archive server can be set up through Safeguard for Privileged Sessions.
Functionality after the link

The following functionality handled in SPP's user interface is available in Safeguard for Privileged Sessions after the link.

  • Session certificate assignment is handled by Safeguard for Privileged Sessions. The certificate is available for audit by the Auditor.
  • The primary provider names must match for a Safeguard for Privileged Sessions initiated RDP connection with SPP. See KB article 311852.

The following functionality is available in SPP after the link.

  • During the link, SPP sets the SPS Connection Policy to safeguard_default for SSH or safeguard_rdp for 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 link. These include: General, Scope, Security, and Workflow tabs.
  • The Activity Center shows all old sessions and new sessions per the configuration. You can play back a session from SPP. Starting with session player 1.9.4, sessions can be played in SPP with full indexing (which makes the privileged users' activity searchable). However, if you are using an earlier version of the sessions player then indexing is only available in Safeguard for Privileged Sessions.
  • Entitlement reports have not changed.
  • On the Dashboard, administrators can still view and manage access requests and accounts failing tasks as usual.
  • When integrating with Safeguard for Privileged Sessions, you can effectively enable Single Sign-On (SSO) between the two applications by creating and using the same SAML2 external federation login provider in both. The Login Provider ID value from SPP (for more information, see Identity and Authentication) must then be entered into the Safeguard for Privileged Sessions Script Reference field when creating the matching SAML2 login method.
Step 1: Link Safeguard for Privileged Sessions and SPP

The link is initiated from Safeguard for Privileged Sessions. For details about the link steps and issue resolution, see the One Identity Safeguard for Privileged Sessions Administration Guide.

NOTE: SPP can target a specific Safeguard for Privileged Sessions appliance or network interface by IP address. This is done by configuring the Safeguard for Privileged Sessions connection policy to specify an explicit TO address (for example, CIDR notation /32). When that connection policy is selected as the Safeguard for Privileged Sessions connection policy for the access policy, SPP will construct a connection string that targets that specific IP address.

Pay attention to the roles assigned to the Safeguard for Privileged Sessions nodes. The following caution is offered to avoid losing session playback from SPP.

CAUTION: Do not switch the role of a Safeguard for Privileged Sessions 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 Safeguard for Privileged Sessions 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 Safeguard for Privileged Sessions nodes and roles, see the One Identity Safeguard for Privileged Sessions Administration Guide: One Identity Safeguard for Privileged Sessions - Technical Documentation.

Step 2: Perform post link activities in SPP and Safeguard for Privileged Sessions

Steps to perform in SPP

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

    Navigate to Appliance > Cluster > Managed Networks. For more information, see Managed Networks.

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

    Go to Appliance > Cluster > Session Appliances. For more information, see Session Appliances with Safeguard for Privileged Sessions link.

    If you soft delete a session connection, then reconnect, the access policies remain available. If you hard delete, the Security Policy Administrator will need to relink and reestablish the Safeguard for Privileged Sessions Connection Policy. For more information, see Connection deletion: soft delete versus hard delete.

  3. The Security 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 Security Policy Management > 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 Security tab, go to the SPS Connection Policy. The host name of the cluster master is displayed first followed by the IP address: 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 Security Policy Administrator checks any other tab, as needed. The link does not affect the settings on the tabs including the General, Scope, Security, and Workflow tabs.

Steps to perform in Safeguard for Privileged Sessions

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

Standard operating procedure after the initial link

If you add another Safeguard for Privileged Sessions (SPS) cluster after the initial link, follow these standard operating procedures:

  1. Add link connections. For more information, see Session Appliances with Safeguard for Privileged Sessions link.
  2. Identify the session settings on the entitlements access request policy (SPS Connection Policy that 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.

Appendix C: Regular Expressions

Regular expressions are used to parse large amounts of data to find matching patterns and validate a predefined pattern. For example, in SPP, regular expressions are used for:

  • Account Discovery rules (Property Constraints, Name Ranges and Group Ranges). Partial matches are acceptable (unless the regular expression itself is defined to only return exact matches).
  • Ticket numbers when an external ticketing system is not used. Matches must be exact.

For details, see these Microsoft resources:

Best practices for ticketing not tied to external ticket system

These best practices are for adding a regular expression for ticketing not tied to an external ticket system. For more information, see Ticket systems.

If you use an alternation construct (“|” which is “or”), the longest matching expression is defined first to the least matching expression because Windows.Net regular expression (regex) stops after finding the first match.

For example: A{3}[0-9]{5}ZZZ|A{3}[0-9]{5} is advised instead of the reverse order. Sample entry results follow for the A{3}[0-9]{5}ZZZ|A{3}[0-9]{5} expression:

User entry: Match?  
AAA12345 Yes. Matched on the second regex  
AAA12345Z No. There is no exact match.  
AAA12345ZZZ

Yes. Matched on the first regex.

If the expression were reversed (A{3}[0-9]{5}|A{3}[0-9]{5}ZZZ) there would be a partial match on the first expression and the entry would be returned as invalid.

 

You may want to wrap each expression in an alternation construct with the anchors ^ and $ when using alternation constructs. An example follows: ^A{3}[0-9]{5}ZZZ$|^A{3}[0-9]{5}$.

The ? lazy quantifier should be avoided, especially at the end of the expression. For example, if the regex is A{3}[0-9]? and the user enters AAA12345, AAA1 is returned as a matched string which is not an exact match of AAA12345.

If the greedy quantifier (*) is used against AAA12345 then the matched string will be AAA12345 and be an exact match.

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação