サポートと今すぐチャット
サポートとのチャット

Safeguard for Privileged Passwords On Demand Hosted - 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 Activity Center Search box Privileged access requests Toolbox Accounts Account Groups Assets
General/Properties tab (asset) Accounts tab (asset) Account Dependencies tab (asset) Owners tab (asset) Access Request Policies tab (asset) Asset Groups tab (asset) Discovered SSH Keys (asset) Discovered Services tab (asset) History tab (asset) Managing assets
Asset Groups Discovery Entitlements Linked Accounts Partitions Profiles Settings
Access Request settings Appliance settings Asset Management settings Tags Backup and Retention settings Certificates settings Cluster settings Enable or Disable Services settings External Integration settings Password Management settings Real-Time Reports Safeguard Access settings SSH Key Management settings Security Policy 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 systems

Safeguard for Privileged Passwords supports Windows systems.

To prepare Windows systems for Safeguard for Privileged Passwords

  1. Create a service account on the asset and assign it a password:

    • Directory Configuration

      If the Windows 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 system is not joined to a domain, then use a local service account that has been granted sufficient permissions.

  2. Grant the service account sufficient permissions to change account permissions to allow changing account passwords. For more information, see Minimum required permissions for Windows assets.

  3. Configure the system's firewall to allow the following predefined incoming rules:

    • Windows Management Instrumentation (DCOM-In)

    • Windows Management Instrumentation (WMI-In)

    • NetLogon Service (NP-In)

    These rules allow incoming traffic on TCP port 135 and TCP SMB 445, respectively.

  4. Ensure the following ports are accessible:

    • Port 389 is LDAP for connections. LDAP port 389 connections are used for Active Directory Asset Discovery and Directory Account Discovery.

    • Port 445 SMB is used to perform password check and changes.
    • When possible, RPC ephemeral ports should also be accessible. For more information, see Service overview and network port requirements for Windows.

  5. Change the local security policy:

    Before Safeguard for Privileged Passwords can reset local account passwords on Windows systems, using a service account that is a non-built-in administrator, you must change the local security policy to disable the User Account Control (UAC) Admin Approval Mode (Run all administrators in Admin Approval Mode) option. For more information, see Change password or SSH key fails.

For additional information on ports, see Safeguard ports.

Preparing WinRM systems

Safeguard for Privileged Passwords supports Windows Remote Management (WinRM) systems.

To prepare Windows Remote Management (WinRM) systems for Safeguard for Privileged Passwords

  1. The initial configuration requirements for WinRM depend on whether or not you are using SSL.

    • For SSL (this is when USE SSL Encryption and Verify SSL Certificate are enabled for the asset):

      1. You need to manually add a CA signed certificate to the asset:

        IMPORTANT: You will need to upload the CA certificate to Safeguard (this can be done via both the desktop client and web client.

        On the asset, the certificate should be installed in the LocalMachine\My store and the CA should be in the LocalMachine\TrustedRoots store. If you use an intermediate that should be in the LocalMachine\Intermediate store.

        Ensure the following requirements are met for the certificate:

        • CN must match the hostname of the asset.

        • CRL must be present and resolvable.

        • Server Authentication enhanced key usage is required.

        1. The HTTPS listener needs to be registered in WinRM using the following command: winrm create winrm/config/Listener?Address=*+transport=HTTPS @{Hostname="<hostname>";CertificateThumbprint="<thumbprint>"}

        2. Use the following command to set the certificate: winrm set winrm/config/service @{CertificateThumbprint="<thumbprint>"}

        3. Open port 5986 in the firewall.

        4. Restart the Windows Remoting service.

    • For non-SSL:

      1. On the asset, run the following command: Enable-PSRemoting -Force.

  2. Create a service account on the asset and assign it a password:

    • Directory Configuration

      If the Windows 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 system is not joined to a domain, then use a local service account that has been granted sufficient permissions.

  3. Grant the service account sufficient permissions to change account permissions to allow changing account passwords. For more information, see Minimum required permissions for Windows assets.

Preparing Windows SSH systems

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

Safeguard for Privileged Passwords requires that C:\Windows\System32\cmd.exe be configured as the default shell for SSH (for more information, see OpenSSH Server configuration for Windows Server and Windows).

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. For more information, see Minimum required permissions for Windows assets.

Minimum required permissions for Windows assets

The following minimum permissions are required for Windows assets to perform directory password management and sessions management tasks using Windows Management Instrumentation (WMI).

Asset password management

Using a local account or domain account:

  • (Only applies to Windows Desktop and Windows Server) Test connection, Check connection, Password check, and Account discovery tasks require the following permissions:
    • Remote Enable permission on WMI's CIMV2 Namespace
    • Enable Account permission on WMI's CIMV2 Namespace

    • Remote Activation permission on computer via DCOM.

      To set Remote Enable and Enable Account permissions

      1. Open wmimgmt.msc.
      2. Right-click WMI Control (Local) and select Properties.
      3. Select the Security tab.
      4. Expand the Root node.
      5. Select the CIMV2 node.
      6. Click the Security button.
      7. Add user/group and select Remote Enable and Enable Account.
      8. Click OK.

      To set Remote Activation permissions

      1. Open dcomcnfg.
      2. Expand Component Services | Computers.
      3. Right-click My Computer and select Properties.
      4. Open the COM Security tab.
      5. Under Launch and Activation Permissions, select Edit Limits.
      6. Add user/group and select Allow for Remote Activation.
      7. Click OK.
  • Password change task requires the following permission:
    • Member of Local Administrators group
Domain password management

Using a Domain account:

  • Test connection, Check connection, Password check, and Account discovery tasks require the following permissions:
    • Member of Domain Users
  • Password change task requires that the Service account has the following delegated permissions:
    • LockoutTime (Read/Write)

    • Account Restrictions (Read/Write)

    • Reset Password

Asset session access

Using a local account:

  • Member of Remote Desktop Users group
  • Defined in the "Allow log on through Remote Desktop Services" policy (directly or via group membership)
  • Not defined in the "Deny log on through Remote Desktop Services" policy (directly or via group membership)

Using a Domain account:

  • Defined in the Remote Desktop Users group or be a member of a domain security group by a group policy update to the Remote Desktop Users group for that asset
  • Defined in the "Allow log on through Remote Desktop Services" policy (directly or via group membership)
  • Not defined in the "Deny log on through Remote Desktop Services" policy (directly or via group membership)
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択