Converse agora com nosso suporte
Chat com o suporte

One Identity Safeguard for Privileged Passwords 7.0.2 LTS - 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 Privileged access requests Appliance Management
Appliance Backup and Retention Certificates Cluster Enable or Disable 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
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 About us

How do I prevent Safeguard for Privileged Passwords messages when making RDP connections

When making an RDP connection, you may encounter two different certificate messages.

  • Unsigned RDP file message

    This message occurs when Remote Desktop Connection opens the RDP file that is downloaded when you click Play in the Safeguard for Privileged Passwords user interface.

    We are currently working on a solution that will allow Safeguard for Privileged Passwords to sign this RDP file to avoid this message.

  • Untrusted server certification message

    This message occurs when the workstation has not trusted the Safeguard for Privileged Passwords RDP Connection Signing Certificate.

    NOTE: The IP address of the connecting server is that of the Safeguard appliance.

    To avoid this message, you must trust the RDP Connection Signing Certificate and certificates in its chain of trust or replace the current certificate with an enterprise certificate and chain of trust that is trusted.

    One Identity recommends that you replace the entire configuration with your own trusted enterprise PKI. This would result in a structure such as:

    • Your Root CA
      • Your Issuing CA
        • Your RDP Signing Certificate (from Safeguard CSR)
          • <Sessions module generated certificate>

    The Root CA, Issuing CA, and RDP Signing Certificates can be distributed via Group Policy, Active Directory, or other distribution means.

How do I set up telnet and TN3270/TN5250 session access requests

Safeguard for Privileged Passwords (SPP) supports session access requests with mainframes using software terminal emulation including telnet and TN3270/TN5250 over telnet. Safeguard for Privileged Sessions (SPS) version 6.1 or higher is used for session recording.

Actions

  • Security officers can record activities of administrators who maintain critical systems running on IBM iSeries and mainframe computers.
  • Asset Administrators can:
    • Customize the TN3270/TN5250 login screen field detection to work for the Safeguard custom login setup.
    • Mark an asset as supporting telnet sessions and specify if the asset is available.
  • Security Policy Administrators can create an entitlement with an access policy that includes session access using telnet and TN3270/TN5250 sessions over telnet.
  • Requesters' log in experience follows the regular client telnet or TN3270/TN5250 interface even when the session is being recorded. Sessions are not launched from Safeguard for Privileged Passwords and all required log in information is available through Safeguard for Privileged Passwords.

Steps for sessions access requests using telnet and TN3270/TN5250 over telnet

IMPORTANT: Assistance with One Identity Professional Services is required for help with configurations and installation including available plug-ins, policy creation, pattern files, shortcuts, and best practices.

SPS set up steps

Complete the following set up steps in Safeguard for Privileged Sessions (SPS). For operation details, see the One Identity Safeguard for Privileged Sessions Administration Guide: One Identity Safeguard for Privileged Sessions Administration Guide.

  • Import the necessary plug-in to supply authentication and authorization (AA) and credential store (credstore) information to authenticate with and pull the credentials from SPP. The plug-in file and instructions are available at the Safeguard Custom Platform Home wiki on GitHub.
  • Create and assign Pattern Sets that use pattern files specific to the log in experience for each connection. A pattern file describes the log in experience for a specific system. The pattern file may include the on-screen location of the user name, password or SSH key field location, login result, descriptions, states, and other required detail. Because log in experiences vary from mainframe to mainframe, custom pattern files must be created, uploaded, and referenced by the system-related connection policy. Template pattern files and instructions are available at the Safeguard Custom Platform Home wiki on GitHub.

CAUTION: Template pattern files are provided for information only. Customized telnet and TN3270/TN5250 pattern files need to be created. Updates, error checking, and testing are required before using them in production.

  • Specify each Authentication Policy and list the authentication methods that can be used in a connection.
  • Create and configure each Connection Policy. Multiple connection policies are typically required because of the uniqueness of each system log on experience and related pattern file as well as the fact that inband destinations are not used for TN3270/TN5250 over telnet.
    For example, telnet can be used for inband destinations. However, inband destinations are not used for TN3270/TN5250 over telnet. Instead, a fixed address including the port and server can be identified which results in the need for a different connection policy for each mainframe. A fixed address in SPS includes the port used; the SPP asset port is not used in the connection but is usually the same.
  • Export a configuration file, if desired.
  • Configure basic settings for the SSH server, cluster interface, and cluster management.
SPP set up steps

Complete the following set up steps in Safeguard for Privileged Passwords (SPP).

  • The Asset Administrator adds the mainframe asset including the Telnet Session Port that is identified on the Asset Management > Asset > Management tab. For more information, see Adding an asset.
  • The Security Policy Administrator sets the Access Type (Telnet) on the Security Policy Management > Entitlements > Access Request Policies tab.
SPP requester steps

In SPP after all configuration is complete, the requester proceeds based on the terminal service application in use.

  • For a terminal service application that uses an inband connection string (like telnet), click  Copy to copy the Hostname Connection String and check out the password or SSH key. Then, paste the information in the log in screen.
  • If the terminal service application requires more information for log in (for example, TN3270/TN5250 over telnet):
    • Click Show to display values that may include Vault Address (the SPP address), a one-time Token, Username, Asset, and Sessions Module (the SPS address).
    • Click  Copy by any of the values to copy a single value. Or, you can click  Copy at the right of all values to copy the entire the connection string, if that is required by your terminal service application.
    • Paste the necessary information into your terminal service application.
  • Click  Check-In Request to complete the password or SSH key check out process. This makes the session request available to reviewers.
  • Click Hide to conceal the information from view.

NOTE: The user would copy an entire connection string if, for example, you have a launcher to take the connection string and launch the profile of the terminal service application.

How do Safeguard for Privileged Passwords database servers use SSL

Some database servers use Secure Socket Layer (SSL) when communicating with Safeguard for Privileged Passwords. Depending on the platform type, version, and configuration, the database server can either use SSL for only encrypting the session or it can use SSL for encrypting and verifying the authenticity of the database server.

ODBC Transport

The following platforms use the ODBC transport. Safeguard for Privileged Passwords installs the appropriate software driver on the appliance to communicate with the platform. The configuration data that Safeguard for Privileged Passwords uses to initialize a connection with the server is in the form of a connection string consisting of a colon-separated list of driver-specific options.

By default, the database servers encrypt the login data, but not the subsequent data passed on the connection. You must configure SSL and enable it on the database server to enable encryption for the session data.

Microsoft SQL Server

MicrosoftSQL Serveris always capable of encrypting the connection with SSL. It listens on a single port for both SSL and non-SSL connections.

If you have set the Force Encryption option to yes on the SQL server, then it uses SSL to encrypt the data, regardless of whether the Safeguard for Privileged Passwords client requests it or not.

You can set the Force Encryption option to yes on the SQL server without configuring a server certificate. In this case, the SQL server transparently generates a self-signed certificate to use when a Safeguard for Privileged Passwords client requests encryption. This makes it possible for the SQL server to use SSL only to provide encryption for the session without verifying the server certificate.

NOTE: It is not possible from within a running session to detect whether the SQL server is using SSL for encryption.

Table 215: Microsoft SQL Server SSL support
Safeguard for Privileged Passwords Client Options Microsoft SQL Server Configuration

Result

Use SSL Encryption Verify SSL Cert Force Encryption Server Cert Configured
No n/a No n/a The SQL Server does not encrypt the session.
Yes No n/a No Safeguard for Privileged Passwords requests that the SQL server encrypt the session using a generated self-signed certificate.
Yes No n/a Yes Safeguard for Privileged Passwords requests that the SQL server encrypt the session using the server certificate.
Yes Yes n/a No The SQL server rejects the connection as there is no certificate to verify against.
Yes Yes n/a Yes Safeguard for Privileged Passwords requests that the SQL server encrypt the session and verify the server certificate against the trusted CA certificates in Safeguard for Privileged Passwords.

MySQL Server

To support SSL you must compile the MySQL server software with SSL support and correctly configure it with a CA certificate and server certificate. If there is any problem with the certificate, the MySQL server may log an error and start up without SSL support. In this case the MySQL server rejects the request to enable SSL for a session as there is no certificate to verify against and does not encrypt the session. The MySQL server listens on a single port for both types of connections.

The behavior of the MySQL server depends on the server version and configuration. In some versions of MySQL, the server enables SSL by default on all Safeguard for Privileged Passwords client sessions once it is configured.

If the MySQL server defaults to using SSL, or requires SSL for a user, the MySQL server encrypts the session even if the Safeguard for Privileged Passwords client does not request it. However, the Safeguard for Privileged Passwords client cannot request to use SSL just for encryption; it can only request SSL if you have imported the correct CA certificate to Safeguard for Privileged Passwords.

NOTE: It is possible to detect that SSL is in use from within a session by examining the session variables. That is, the Safeguard for Privileged Passwords client can detect if a request to use SSL has not been honored and displays an error.

Table 216: MySQL Server SSL support
Safeguard for Privileged Passwords Use SSL Encryption Option SSL Supported on MySQL Server

Result
No No Unencrypted session.
No Yes Determined by the MySQL server. The server encrypts the session if it defaults to using SSL or requires it for this user.
Yes No Safeguard for Privileged Passwords client detects this and reports a failure.
Yes Yes Safeguard for Privileged Passwords requests that the MySQL server encrypt the session and verity the server certificate against the trusted CA certificate in Safeguard for Privileged Passwords

For more information, see Preparing MySQL servers.

Sybase ASE Server

To support SSL you must correctly configure the Sybase server with a CA certificate and server certificate. The Sybase server listens on different ports for SSL and non-SSL connections, and rejects a mismatched request from a Safeguard for Privileged Passwords client to a particular port.

The Safeguard for Privileged Passwords client cannot request to use SSL just for encryption; it can only request SSL if you have imported the correct CA certificate to Safeguard for Privileged Passwords.

Table 217: Sybase ASE Server SSL support
Safeguard for Privileged Passwords Use SSL Encryption Option Sybase Server Listening Port Uses SSL

Result
No No Unencrypted session.
No Yes

The Sybase server rejects the connection attempt.

NOTE: The ODBC driver cannot detect that this is an SSL error and displays a client cannot connect error.

Yes No The Sybase server rejects the session with an SSL error.
Yes Yes Safeguard for Privileged Passwords requests that the Sybase server encrypt the session and verify the server certificate against the trusted CA certificates in Safeguard for Privileged Passwords.

For more information, see Preparing Sybase (Adaptive Server Enterprise) servers.

What are the access request states

Safeguard for Privileged Passwordsuses the following access request states, which change as a request steps through the workflow process.

Table 218: Access request states
State Description
Available Approved requests that are ready for the requester. That is, for password or SSH key release requests, the requester can view or copy the password or SSH key. For session access requests, the requester can launch the session.
Approved Requests that have been approved, but the check out time has not arrived.
Denied Requests denied by the approver.
Expired Requests for which the Checkout Duration has elapsed.
Pending Requests that are waiting for approval.
Revoked

Approved requests retracted by the approver.

NOTE: The approver can revoke a request between the time the requester views it and checks it back in.

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação