Safeguard for Privileged Passwords supports Windows SSH systems. Windows SSH uses port 22 on the platform.
SPP 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 8
The OpenSSH port on Windows 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
- Ensure the SSH server service is running.
-
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, SPP will only discover and update services running as local accounts, and domain account dependencies will not be updated.
-
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.
SPP manages single sign-on (SSO) accounts on the vCenter Server platform.
To manage single sign-on accounts on the VMware vCenter Server platform
-
Enable SSH access to the vCenter appliance.
-
Use the SSO administrator account as the service account when creating the asset in Safeguard.
NOTE: If the administrator account is managed by Safeguard, then Safeguard will also attempt to synchronize
the local root account with the SSO administrator account.
-
When creating the managed account in Safeguard, you must use the fully qualified name of the SSO account. The default fully qualified name is <account>@vsphere.local.
SPP supports asset discovery for the vCenter Server platform.
To discover the virtual machines in Vsphere, ensure that the service account has HTTPS access to the vCenter Server.
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
- Open wmimgmt.msc.
- Right-click WMI Control (Local) and select Properties.
- Select the Security tab.
- Expand the Root node.
- Select the CIMV2 node.
- Click the Security button.
- Add user/group and select Remote Enable and Enable Account.
- Click OK.
To set Remote Activation permissions
- Open dcomcnfg.
- Expand Component Services > Computers.
- Right-click My Computer and select Properties.
- Open the COM Security tab.
- Under Launch and Activation Permissions, select Edit Limits.
- Add user/group and select Allow for Remote Activation.
- 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:
- Password change task requires that the Service account has the following delegated permissions:
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)
One Identity recommends the following resolutions to some of the common problems you may encounter as you deploy and use SPP. For more information about how to troubleshoot SPP, refer to the Appliance.