Configuring CredSSP for WinRM with PowerShell

Introduction

In some cases, a PowerShell script may need to access resources outside of a Verify Privilege Vault machine. This requires that any credentials are delegated to the target machine. Verify Privilege Vault runs PowerShell scripts using Windows Remote Management (WinRM), which does not allow credential delegation by default. To allow credential delegation, the Verify Privilege Vault machine must have Credential Security Support Provider (CredSSP) enabled. CredSSP is a security support provider that allows a client to delegate credentials to a target server.

CredSSP is required for dealing with double-hop scenarios. Per Microsoft documentation:

• CredSSP authentication is intended for environments where Kerberos delegation cannot be used.

• Support for CredSSP was added to allow a user to connect to a remote server and have the ability to access a second-hop machine, such as a file share.

• The first hop we make to their DE or web node (Enter-PSSession localhost), if they are running code locally from there and then doing a remote call (e.g. testing access to a remote UNC path) it will then require the second hop.

Enabling CredSSP for WinRM in Verify Privilege Vault

1. Go to Administration > Configuration. The General tab of the Configuration page appears:

   

2. Click Edit button at the bottom of the page.

3. Click to select the Enable CredSSP Authentication for WinRM checkbox.

4. Click the Save button.

Configuring CredSSP for WinRM on the Verify Privilege Vault Machine

1. Log on to the machine running Verify Privilege Vault.

2. Run Windows PowerShell as an administrator.

3. Enable client-side CredSSP by running:

   Enable-WSManCredSSP -Role Client -DelegateComputer <Verify Privilege Vault fully qualified machine name>

   For example:

   Enable-WSManCredSSP -Role Client -DelegateComputer <localhost>

   localhost is the actual string that Verify Privilege Vault uses to generate the PowerShell run space. Sometimes customers need both localhost and FQDN entries. In theory, those entries should be the same, thus not needing a second one.

4. Enable server-side CredSSP by running:

   Enable-WSManCredSSP -Role Server

5. The Web server always uses a specified account to run the PowerShell scripts. Considerations:

   • Ensure that account is added to the "Remote Management Users" local group on each Web server.

   • For RPCs with custom password changers, this would be "Change Password Using," and then select "Privileged Account."

   • For PowerShell password changers in the classic UI, this would be "Run PowerShell Using" and can alternatively be configured as the "Default Privileged Account" at the template level.

   • For custom dependencies using PowerShell scripts, this would be the "Run As" secret.

   • If you use any form of extensible discovery, this account needs to be the first secret that is linked to the scanner. Any additional secrets linked to the scanner are typically associated with authentication to the destination system.

Configuring CredSSP for WinRM on a Distributed Engine

You can alternatively configure CredSSP and the credential delegation to occur from your distributed engines by changing this setting at the site level:

1. Go to Admin > Distributed Engine. The Distribute Engine Configuration page appears:

   

2. Click the site panel button for the desired DE. The panel expands, displaying the DEs for that site:

   

3. Click the site name link at the top of the panel. The site's page appears:

   

4. Scroll down to see the Enable CredSSP Authentication for WinRM listing in the Advanced Site Configuration section.

5. If it is not enabled, log on to each of your distributed engines where CredSSP is enabled.

6. Run Windows PowerShell as an administrator.

7. Enable client-side CredSSP by running:

   Enable-WSManCredSSP -Role Client -DelegateComputer <distributed engine fully qualified machine name>

   Enable-WSManCredSSP -Role Client -DelegateComputer <localhost>

   localhost is the actual string that the Distributed Engine is using to generate the run space. Some customers need to have both the localhost and FQDN entry. In theory, both entries above should be the same, thus not needing a second entry.

8. Enable server-side CredSSP by running:

   Enable-WSManCredSSP -Role Server

9. The distribute engine will always use a specified account to run the PowerShell scripts. Considerations:

   • Ensure that account is added to the "Remote Management Users" local group on each engine where CredSSP is enabled.
   • For RPCs with custom password changers, this would be "Change Password Using," and then select "Privileged Account".
   • For PowerShell password changers in the classic UI, this would be "Run PowerShell Using" and can alternatively be configured as the "Default Privileged Account" at the template level.
   • For custom dependencies using PowerShell scripts, this would be the "Run As" secret.
   • If you use any form of extensible discovery, this account needs to be the first secret that is linked to the scanner. Any additional secrets linked to the scanner are typically associated with authentication to the destination system.

10. Ensure that the "Allow Delegating Fresh Credentials" group policy setting is enabled and is not disabled by a domain policy.

    1. Open the gpedit.msc file on your Verify Privilege Vault machine or distributed engine, depending on where CredSSP is enabled

    2. Navigate to Computer Settings > Administrative Templates > System > Credentials Delegation.

    3. Edit the "Allow Delegating Fresh Credentials" setting.

    4. Verify that it is Enabled.

    5. Click "Show..."

    6. Verify that the list contains an entry that begins with "wsman/" and ends with the fully qualified machine name of the Verify Privilege Vault machine or distributed engine.

    7. If destination systems are non-domain joined or on another domain without a trust, it may be required for you to add in an entry for each destination system you wish to run the script or do discovery on (as examples). Consider collecting a list of all destination FQDNs for your specific use case and adding them all in one go.

11. Depending on where CredSSP is configured (Web server or distributed engine), run the following commands:

    • View existing entries: Get-Item WSMan:\localhost\Client\TrustedHosts
    • Adding computers if your TrustedHosts list is empty: Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]
    • Adding computers to your existing TrustedHosts list:

      $curList = (Get-Item WSMan:\localhost\Client\TrustedHosts).value

      Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$curList, Server01"

12. On the destination system, if it is on a separate domain without a trust or non-domain joined, add the reverse WSman entries so the destination system trusts either Verify Privilege Vault or your engines. Run one of the following commands:

    Web server:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Web Server 1 FQDN>,[<Web Server 2 FQDN>]

    Engine:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value <Distributed Engine 1 FQDN>, [<Distributed Engine 2 FQDN>]

13. Restart either Verify Privilege Vault or the engine you just trusted.

Enabling CredSSP on Verify Privilege Vault Agents for PowerShell Script Dependencies

Remote agents were upgraded to distributed engines in Verify Privilege Vault version 8.9. This section only applies to Verify Privilege Vault versions 8.8.000020 and earlier.

Remote Agents are only needed for networks that are not directly connected to the network that Verify Privilege Vault is installed on. If you are not using remote agents, disregard this section.

By default, Verify Privilege Vault agents inherit the "Enable CredSSP Authentication for WinRM" setting from Verify Privilege Vault; however, you can override this in the agent configuration file as follows:

1. On the machine running the agent, locate the agent program files. By default, they are at C:\Program Files (x86)\Thycotic Software Ltd\Verify Privilege Vault Agent.

2. Edit the SecretServerAgentService.exe.Config file in a text editor.

3. Locate the "UnencryptedSettings" section.

4. Add a new key to that section for EnableCredSSPForWinRM and set it to true. For example:

   <add key="EnableCredSSPForWinRM" value="true" />

5. Restart the "Verify Privilege Vault Agent" service to apply the setting.