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.
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.
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.
|Safeguard for Privileged Passwords Client Options||Microsoft SQL Server Configuration||
|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.|
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.
|Safeguard for Privileged Passwords Use SSL Encryption Option||SSL Suppofrted on MySQL Server||
|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|
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.
|Safeguard for Privileged Passwords Use SSL Encryption Option||Sybase Server Listening Port uses SSL||
The Sybase server rejects the connection attempt.
|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.|
|Available||Approved requests that are ready for the requester. That is, for password release requests, the requester can view or copy the password. For session access requests, the requester can launch the session.|
|Approved||Requests that have been approved, but the checkout 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.|
Approved requests retracted by the approver.
Safeguard for Privileged Passwords Appliances can end up in a quarantine state if something goes wrong while doing certain activities with the Safeguard for Privileged Passwords Appliance. The best defense against losing data or compounding problems associated with quarantined appliances is a good and recent backup (Backup and Retention settings). The appliance (at least one appliance in a clustered environment), should be set up to take a scheduled backup regularly, which should be saved to an archive server so that if something happens, you can recover with minimum downtime and loss.
To recover an appliance in a quarantine state
If a Safeguard for Privileged Passwords Appliance goes into a quarantine state, use one of the following options to recover:
Unless you have a good reason not to restart the appliance, this should be your first step. Often times, a quarantine happens because the system was waiting for a response that did not return in time. Restarting the Safeguard for Privileged Passwords Appliance allows it to retry and frequently fixes itself.
If the Quarantine warning appears, proceed to Option 2.
||NOTE: Clustered environment: If the quarantined appliance was the primary appliance, use the Failover option to reassign the primary appliance role to a healthy member of the cluster (Failing over to a replica by promoting it to be the new primary).|
If restarting the appliance did not fix the problem, it will be necessary to do a factory reset on the appliance in order to fix it.
|Caution: Factory reset returns the appliance to its original state when it first came from the factory. All data and configuration settings will be lost and any patches applied will be removed.|
To perform a factory reset, connect to the recovery kiosk and select the Factory Reset option (Factory reset from recovery kiosk).
|NOTE: You must contact One Identity Technical Support to complete the operation.|
Once the factory reset is started, you must wait until it finishes (it could take up to 30 minutes to complete). When the factory reset is complete, the kiosk will return an Online indicator.
Once the factory reset is complete:
One Identity Safeguard for Privileged Passwords embedded sessions module enables you to issue privileged access to users for a specific period or session and gives you the ability to record, archive, and replay user sessions so that your company can meet its auditing and compliance requirements.
Before using Privileged Sessions, make sure the following settings and configuration are in place:
Ensure the necessary SSH algorithms are configured for any Unix or Linux machines that are going to be using SSH.
NOTE: Safeguard for Privileged Passwords ships with default SSH algorithms configured for Unix and Linux machines. To add new algorithms, use the API endpoint: