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

Preparing Windows SSH systems

Safeguard for Privileged Passwords supports Windows SSH systems. Windows SSH uses port 22 on the platform.

OpenSSH on Windows 7 and 8

The OpenSSH port on Windows 7 and 8 has server-side limitations on command execution. Password operations may appear to run more slowly because commands do not return until the timeout expires, even if the command has already completed on the server. You may need to tune the Connection Timeout (CommandTimeout) when running TestConnection, ChangePassword, and CheckPassword in order to allow these password operations enough time to run while still allowing enough time to avoid timeouts for other conditions specific to your network.

To prepare Windows SSH systems for Safeguard for Privileged Passwords

  1. Ensure the SSH server service is running.
  2. Create a service account on the asset and assign it a password:

    • Directory Configuration

      If the Windows SSH system is joined to a domain that will be managed in Safeguard for Privileged Passwords, you can use a directory account, such as a Microsoft Active Directory account to manage the asset. Enable the Password Never Expires option; once you add the asset to Safeguard for Privileged Passwords, you can have the service account password auto-managed to keep it secure.

      -OR-

    • Local Configuration

      If the Windows SSH system is not joined to a domain, then use a local service account that has been granted sufficient permissions.

      IMPORTANT: A local account does not have the access necessary to discover services running as domain accounts, so if a local account is used, Safeguard for Privileged Passwords will only discover services running as local accounts, and domain account dependencies will not be updated.

  3. Ensure the service account is added to the local Administrator's group to allow change password permissions.

Troubleshooting

One Identity recommends the following resolutions to some of the common problems you may encounter as you deploy and use Safeguard for Privileged Passwords. For more information about how to troubleshoot Safeguard for Privileged Passwords, refer to the Appliance settings.

Related Topics

Frequently asked questions

Anti-CSRF (cross-site request forgery) token error

Cross-site request forgery (CSRF) occurs when unauthorized commands are transmitted from a user that the web application trusts. Anti-CSRF is a type of CSRF protection. It is a random string that is only known by the user's browser and the web application

If you receive an Anti Cross-Site Request Forgery token error when attempting to log in to Safeguard for Privileged Passwords using Microsoft Internet Explorer 9 on Windows 7 SP1, this indicates that cookies are blocked.

To resolve this issue

  1. In Internet Explorer, open Tools and choose Internet Options.
  2. In the Privacy tab, click the Advanced button.
  3. Select the Always allow session cookies option.

Appliance is sick

There are so many possible root causes for a sick appliance. If you receive an error that the appliance is sick take the following steps.

  1. Check network connectivity between nodes.
  2. Wait (up to 30m) to see if the error resolves automatically.
  3. If the error persists, create a support bundle and contact support. For more information, see Support bundle.
Categories of appliance sick events by error message prefix

There are 6 categories for appliance sick events which can be distinguished by the error message prefix.

Audit Log is sick : <reason>

There is an error in the underlying audit log database. The reason will provide more details about the exact issue. Typically this is due to loss of consensus as a result of network connectivity. This may be the result of temporary network conditions and, if so, it will resolve automatically after a few minutes. If not, check network connectivity between Safeguard nodes. After ruling out network connectivity, generate a support bundle and contact Support. Do not reboot the appliance until consulting with Support. In some cases, rebooting the appliance can make the condition worse.

Access Request Workflow is sick : <reason>

There is an error in the underlying password workflow database. The reason will provide more details about the exact issue. Typically this is due to loss of consensus as a result of network connectivity. This may be the result of temporary network conditions and, if so, it will resolve automatically after a few minutes. If not, check network connectivity between Safeguard nodes. After ruling out network connectivity, generate a support bundle and contact Support.

Policy Data is sick : <reason>

There is an error in the underlying policy database. The reason will provide more details about the exact issue. Typically this occurs when a replica has lost network connectivity to the primary. This may be the result of temporary network conditions and, if so, it will resolve automatically after a few minutes. If not, check network connectivity between Safeguard nodes. After ruling out network connectivity, generate a support bundle and contact Support.

Cluster Connectivity is sick : <reason>

There is an error in the VPN connection between Safeguard nodes. The reason will provide more details about the exact issue. This may be the result of temporary network conditions and, if so, it will resolve automatically after a few minutes. If not, check network connectivity between Safeguard nodes on the public IP address since the VPN is tunneled over the public IP. After ruling out network connectivity, generate a support bundle and contact Support.

Appliance Resource Usage is sick : <reason>

A Safeguard process or underlying database is exhibiting unexpectedly high OS resource usage (CPU, Memory, Disk). The reason will provide more details about the exact issue. Restarting the appliance may resolve this issue. If the problem persists or recurs frequently, generate a support bundle and contact Support.

Sessions Module is sick : <reason>

There is an error in the embedded sessions module. This issue can occur only on SPP 2.x as the internal sessions module was removed in later versions. Typically, restarting the sessions module will resolve this issue. If the problem persists after restarting the sessions module, generate a support bundle and contact Support.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating