Tchater maintenant avec le support
Tchattez avec un ingénieur du support

One Identity Safeguard for Privileged Passwords 7.0 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
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 Reasons
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

Activating a read-only appliance

Appliances that have been unjoined from a Safeguard for Privileged Passwords cluster or restored from a backup are placed in a Read-only mode.

You can activate an appliance in Read-only mode so you can add, delete, and modify data, apply access request workflow, and so on.

The appliance in Read-only mode must be online in order to use the Activate task. If it is offline or the cluster does not have consensus (that is, the majority of the remaining members are offline/unable to communicate), you must use the Cluster Reset option to rebuild your cluster. For more information, see Resetting a cluster that has lost consensus.

CAUTION: Activating an appliance that is in Read-Only mode will take it out of the Read-only state and enable password and SSH key check and change for managed accounts. Ensure that no other Safeguard for Privileged Passwords Appliance is actively monitoring these accounts, otherwise access to managed accounts could be lost.

To activate a read-only appliance

  1. Log in to the read-only appliance as an Appliance Administrator.

  2. Go to Cluster Management where the cluster view (on the left) displays one primary appliance with a yellow warning icon indicating the appliance is in a Read-only mode.

    • web client: Navigate to Cluster | Cluster Management. 
  3. In the cluster view (on the left), select the read-only node to be activated.
  4. Click Activate.

  5. In the Activate confirmation dialog, enter the word Activate and click OK to proceed.

    The appliance's node in the cluster view (on the left) no longer displays the yellow warning icon and the state is now Online.

Diagnosing a cluster member

The diagnostic tools are available to an Appliance Administrator or Operations Administrator for the currently connected appliance and any other appliances (replicas) in the cluster.

To run diagnostics on a clustered appliance

  1. Go to Cluster Management:
    • web client: Navigate to Cluster | Cluster Management. 
  2. From the cluster view (on the left) select the appliance to be diagnosed.

  3. Click Diagnose.

  4. Click Network Diagnostics.

  5. Choose the type of test to perform and complete the steps.

    • ARP: Use Address Resolution Protocol (ARP) to discover the Interface, Internet Address, Physical Address, and Type (dynamic or static).
    • Netstat: Use netstat to display the active connection protocol, local address, foreign address, and state.
    • NS Lookup: To obtain your domain name or IP address.
    • Ping: To verify your network connectivity and response time.
    • Show Routes: To retrieve routing table information.
    • Telnet: To access remote computers over TCP/IP networks like the internet.
    • Throughput: Test throughput to other appliances in the cluster.
    • Trace Route: To obtain your router information; trace route determines the paths packets take from one IP address to another.

Patching cluster members

When an appliance update is released, apply the patch so all appliances in the cluster are on the same version. See About cluster patching for more information on how Safeguard for Privileged Passwords handles access requests and system failures during the cluster patching process.

Prior to installing an update patch to a cluster

  • Ensure all appliances in the cluster are online and healthy. Any warnings or problems should be addressed before cluster patching. The patch install process will fail if any of the cluster members are unhealthy or cannot be contacted.

    IMPORTANT: The primary appliance orchestrates the cluster upgrade; therefore, the primary appliance must stay online and have a solid network connection with all of the replica appliances in the cluster. If this cannot be reasonably assured, you should unjoin the replica appliances from the cluster, individually upgrade them, and then re-enroll them into cluster.

  • It is highly recommended to take a backup of your primary appliance before applying a patch. For more information, see Backup and Restore.
  • You may want to unjoin a replica from the cluster to serve as a backup appliance. In case of a catastrophic failure, you can activate the unjoined replica to be the primary. If the cluster patching process is successful, upgrade the unjoined replica, and then re-enroll it back into the cluster.

To patch appliances in a cluster

  1. Log in to the primary appliance, as an Appliance Administrator.
  2. Go to the patch updates page:
    • web client: Navigate to Appliance | Patch Updates.

  3. Click Upload a File and browse to select an update file.

    The patch will be uploaded and distributed to all of the appliances in the cluster.

    NOTE: If you make changes to the cluster, such as adding a new replica, while a patch is staged, the update file must be distributed to the new cluster member before the patch install process can begin. Safeguard for Privileged Passwords will not allow the patch install process to begin until all of the cluster members report that they have the update file stored locally.

    NOTE: Clicking the Cancel button during the distribution process stops the distribution of the update file to the replicas. At this point, you can click one of the following buttons:

    • Remove to remove the update file from all of the appliances in the cluster.
    • Distribute to Cluster to continue distributing the update file to each replica in the cluster.

  4. Once the file has been successfully distributed to all of the replicas in the cluster, click the Install Now button.

    The primary appliance will go into Maintenance mode to begin the update operation. Once the primary appliance is successfully updated, Safeguard for Privileged Passwords will perform the update operation on each replica, one at a time. During an update operation, the cluster will be locked so that no other cluster operations can interfere with the update operation. Once the update operation is completed on all cluster members, the cluster will automatically unlock so normal operations can resume.

    The Cluster view shows that an update operation is in progress and the cluster members that are locked, awaiting to install the update file. Go to:

    • web client: Navigate to Cluster | Cluster Management.

    In addition, go to Patch Updates:

    • web client: Navigate to Appliance | Patch Updates.

About cluster patching

The following information provides insight into how Safeguard for Privileged Passwords processes access requests during the cluster patching process. It also describes what happens if a cluster member loses power or network connectivity during the patching process.

Service guarantees

During a cluster upgrade, the cluster is split logically into the current version (side A) and the upgrade version (side B). Access request workflow is only enabled on one side at a time. Audit logs run on both sides and merge when the cluster patch completes. Initially, access request workflow is only enabled on side A, and replicas in PatchPending state can perform access requests. As appliances upgrade and move to side B, the access workflow migrates to side B when side B has a majority of the appliances. At this point in the upgrade process, replicas in PatchPending state can no longer perform access requests; however, all of the upgraded cluster members can perform access requests. There is a small window where access request workflow is unavailable as the data migrates from one side to the other.

Failure scenarios

If the primary appliance loses power or loses network connectivity during the upgrade process, it will try to resume the upgrade on restart.

If a replica is disconnected or loses power during an upgrade process, the replica will most likely go into quarantine mode. The primary appliance will skip that appliance and remove it from the cluster. This replica will need to be reset, upgraded, and then re-enrolled into the cluster manually to recover.

Configuration for password and SSH key check out

The policy may be configured such that a password or SSH key reset is required before the password or SSH key can be checked out again. If that is the case, the following can be temporarily configured prior to cluster patching and access request to allow for password or SSH key check out when a password or SSH key has not been reset.

  • The policy can be set to allow multiple accesses.
  • The policy can be set to not require a password or SSH key change at check in.
  • Emergency requests can be allowed so the user does not have to wait for the password or SSH key to be reset.
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation