Chat now with support
Chat with Support

One Identity Safeguard for Privileged Passwords 6.10 - 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 Getting started with the desktop client Using the desktop client Search box 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 Certificates settings Cluster settings Enable or Disable Services settings External Integration settings Messaging settings (desktop client) Password Management settings Real-Time Reports Safeguard Access settings SSH Key Management 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: Regular Expressions About us

What are the access request states

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

Table 240: 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.

What do I do when an appliance goes into quarantine

Safeguard for Privileged Passwords hardware and virtual appliances can end up in a quarantine state if something goes wrong while doing certain activities. The best defense against losing data or compounding problems associated with quarantined appliances is a good and recent backup. For more information, see Backup and Retention settings. The appliance (at least one appliance in a clustered environment), should be set up to take a scheduled backup regularly, that should be saved to an archive server so that if something happens, you can recover with minimum downtime and loss.

Recovering from a quarantine state

  1. Follow these steps to create a quarantine bundle from the Recovery Kiosk. For more information, see Recovery Kiosk (Serial Kiosk).
    1. Prior to using the Quarantine Bundle function, set up a Windows share where the quarantine bundle is to be sent.

    2. From the Recovery Kiosk, select the Support Bundle option, click the right arrow, and select Quarantine Bundle.
    3. Enter the following information:
      • Address: Enter the address of the Windows share (<IP Address>\<ShareName>) where the support bundle is to be saved.
      • If the Windows share is not anonymous, enter the User name and Password or SSH Key.
    4. Click Copy to Share.
  2. You can now restart the appliance. Often, a quarantine happens because the system was waiting for a response that did not return in time. Restarting the appliance allows it to retry and frequently fixes itself.
    1. To restart a quarantined appliance, connect to the Recovery Kiosk for that appliance and restart it from there. Once the appliance has restarted, it will take several minutes for Safeguard for Privileged Passwords to start.
    2. If you log into the appliance using the desktop client while Safeguard for Privileged Passwords is starting, you will see a Maintenance mode screen. At the end of the Maintenance mode, you will see a Restart Desktop Client button or the Quarantine warning.
      1. If you see the Restart Desktop Client button, the restart successfully recovered the appliance and brought the appliance back in a healthy state.
      2. If the Quarantine warning appears, contact One Identity Technical Support and report the result.

        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. For more information, see Failing over to a replica by promoting it to be the new primary.

To remove a quarantined appliance from a cluster

You may want to remove a quarantined appliance from a cluster.

  1. First try to unjoin the replica appliance from the cluster. For more information, see Unjoining replicas from a cluster.
  2. If unjoining the appliance fails, reset the cluster to remove the appliance from the cluster. For more information, see Resetting a cluster that has lost consensus.
Considerations for a factory reset of a hardware appliance

Caution: Care should be taken when performing a factory reset against a physical appliance, because this operation removes all data and audit history, returning it to its original state when it first came from the factory. Performing a factory reset will NOT reset the BMC/IPMI interface or the IP address. However, the BMC/IPMI interface will need to be reenabled after the reset has completed (for more information, see Lights Out Management (BMC)).The appliance must go through configuration again as if it had just come from the factory. For more information, see Setting up Safeguard for Privileged Passwords for the first time.

In addition, performing a factory reset may change the default SSL certificate and default SSH host key.

The appliance resets to the current Long Term Support (LTS) version. For example, if you are using version 6.6 (feature release) or 6.0.6 LTS (maintenance Long Term Support release) and then factory reset, you appliance will reset down to 6.0 LTS and you will have to patch up to your current version. For more information, see Long Term Support (LTS) and Feature Releases.

One Identity Technical Support can determine if a factory reset is necessary. If a factory reset is the last option, you will need to Support to complete the operation.

  1. To perform a factory reset, connect to the Recovery Kiosk and select the Factory Reset option. For more information, see Factory reset from the Recovery Kiosk.

    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.

  2. Once the factory reset is complete:

    1. Re-configure the network interface settings.
    2. Re-apply any patches you had installed.
    3. If this is an unclustered appliance, upload and restore the most recent backup to retrieve your data. For more information, see Restore a backup.
    4. If the appliance was a member of a cluster, skip the restore step and join the appliance to the cluster as if it were a brand new appliance. For more information, see Enrolling replicas into a cluster.Safeguard for Privileged Passwords will take care of replicating all the data back to the appliance.

When does the rules engine run for dynamic grouping and tagging

Dynamic account groups are associated with rules engines that run when pertinent objects are created or changed. For example:

  • Whenever you add or change an asset account, all applicable rules are reevaluated against that asset account.
  • Whenever you change an asset account rule, the rule is reevaluated against all asset accounts within the scope of that rule. In other words, the rule is reevaluated against all asset accounts for grouping and the asset accounts within the designated partitions for tagging.

You can create a dynamic account group without any rules; however, no accounts will be added to this dynamic account group until you have added a rule.

In large environments, there is a possibility that the user interface may return before all of the rules have been reevaluated and you may not see the results you were expecting. If this happens, wait a few minutes and Refresh the screen to view the results.

Related topic:

Adding a dynamic account group

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.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating