Remote PowerShell Without “Second Hop” Problem

This document targets Windows Server 2022 and Windows Server 2025.

Table of Contents

• Table of Contents
• Overview
• Windows Server 2022/2025 Administration Host and PowerShell
• Remote PowerShell Using CredSSP
  • Reuse a Credential Across Multiple Sessions
• Remote PowerShell Using Resource-Based Kerberos Constrained Delegation
• Update Notes

Overview

Windows Server 2022 and Windows Server 2025 offer two server installation options:

• Server Core — This option is a minimal install. It removes the graphical shell and many nonessential components. You manage it from the command line, PowerShell, the Server Configuration tool (SConfig), or a remote tool.
• Server with Desktop Experience — This option installs the full graphical user interface and all client-experience features.

You choose one option during setup. You cannot switch to the other option after installation, without a reinstall.

If you manage a Server Core host, you see only a command prompt when you log in through Remote Desktop. This can be a surprise for a user who has not worked in a UNIX environment, where the command prompt is the primary interface.

Windows Server 2022/2025 Administration Host and PowerShell

Some SQL Server instances run on a Windows Server 2022 or 2025 host with Server Core. If yours does, build a separate administrative host, with Desktop Experience installed on it. This host lets you manage remote hosts through Management Studio, Failover Cluster Manager, or PowerShell. Identify the required firewall rules first. See the companion WSFC_SQLServer.md document for the firewall rules you need for remote administration.

Once you have an administrative host, open a remote PowerShell connection to a Windows Server 2022 or 2025 host with the following commands.

1. From the Start menu, run Windows PowerShell or PowerShell 7 as administrator.

2. Enter a remote PowerShell session to the host, with the fully qualified domain name (FQDN).

   Enter-PSSession <HOST>.<DOMAIN>
   

You then encounter the Second Hop problem. This happens when your credentials from the administrative host do not pass through to the host you connect to. This is true even if you belong to the correct security groups on both servers. A command that makes a second hop, for example an attempt to reach a remote SMB share on the remote host, fails.

Microsoft documents several ways to solve this problem. In order of preference: CredSSP, resource-based Kerberos constrained delegation, legacy Kerberos constrained delegation, Just Enough Administration (JEA), and a few narrower options. See Making the second hop in PowerShell Remoting for the full comparison. This document covers the two most common methods below.

Remote PowerShell Using CredSSP

Follow these steps to avoid the Second Hop problem with CredSSP.

Note: You must belong to the local Administrators group to run these commands.

Security note: CredSSP caches your credentials on the remote host. If that host is compromised, an attacker gets those credentials. Enable CredSSP only in a trusted environment, for example a dedicated administrative host used only for cluster and database administration. For a higher-security alternative that does not cache credentials, see Remote PowerShell Using Resource-Based Kerberos Constrained Delegation below.

1. From the Start menu, run Windows PowerShell as administrator.

2. Enter a remote PowerShell session to the host, with the FQDN.

   Enter-PSSession <HOST>.<DOMAIN>
   

3. Set the remote host to run in CredSSP server mode.

   Note: Run this once per host.

   Enable-WSManCredSSP -Role Server -Force
   

4. Set your administrative host to run in CredSSP client mode. You must specify the FQDN for each remote host you administer.

   Note: Run this once.

   Enable-WSManCredSSP -Role Client -DelegateComputer *.<DOMAIN> -Force
   

   Note: A single host can run in both CredSSP server mode and CredSSP client mode at the same time. The Server role and the Client role set separate WS-Management settings, so one role does not disable the other. This lets you build a chain of hosts, for example Host A to Host B to Host C. Host B then acts as a CredSSP server for the connection from Host A. Host B also acts as a CredSSP client for the connection it opens to Host C.

5. Enter a remote PowerShell session to the host, with CredSSP authentication. The system prompts you for the password for the <DOMAIN>\<USER> account you specify.

   Enter-PSSession -Authentication CredSSP -Credential "<DOMAIN>\<USER>" <HOST>.<DOMAIN>
   

Your commands that need a Second Hop now succeed.

Reuse a Credential Across Multiple Sessions

Step 5 prompts for a password every time you run it. Instead, use Get-Credential to store the credential in a variable once, then pass that variable to -Credential. This works for Enter-PSSession and any other cmdlet that accepts a -Credential parameter, for example Invoke-Command.

$cred = Get-Credential <DOMAIN>\<USER>
Enter-PSSession -Authentication CredSSP -Credential $cred <HOST>.<DOMAIN>

Get-Credential prompts once, and returns a PSCredential object into $cred. Reuse $cred for later commands in the same session, without a new password prompt each time.

A credential from Get-Credential has no fixed expiration. It stays valid for as long as it exists in memory, for example while its variable stays in scope in your PowerShell session. No Kerberos ticket lifetime or server-side session timeout limits its validity. Each time you pass $cred to a cmdlet, PowerShell submits the stored user name and password again.

Security note: PowerShell stores the password in $cred as a SecureString. A SecureString blocks casual exposure, for example on screen or in a log file. It does not fully protect the password from an attacker who already has deep access to your PowerShell process memory. When you finish your work, close the session, to remove the credential from memory.

Remote PowerShell Using Resource-Based Kerberos Constrained Delegation

Resource-based Kerberos constrained delegation (RBCD) solves the Second Hop problem. It does not cache credentials on any server. It needs Windows Server 2012 or later, so it works on Windows Server 2022 and 2025. It does not require Domain Administrator rights, only rights to update the target computer object in Active Directory.

In this example, ServerA is your administrative host. ServerB is the remote host you connect to. ServerC is the resource that ServerB needs to reach on your behalf.

1. If the Active Directory PowerShell module is not already present, install it on your administrative host.

   Add-WindowsFeature RSAT-AD-PowerShell
   Import-Module ActiveDirectory
   

2. Grant ServerB permission to delegate credentials to ServerC.

   $ServerB = Get-ADComputer -Identity <ServerB>
   $ServerC = Get-ADComputer -Identity <ServerC>
   Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB
   

3. Wait up to 15 minutes for the Kerberos ticket cache to clear, or clear it directly on ServerB.

   Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
       klist purge -li 0x3e7
   }
   

4. Connect to ServerB as usual. Commands that make a second hop to ServerC now succeed, with no CredSSP configuration needed.

See Making the second hop in PowerShell Remoting for the full walkthrough, cross-domain delegation, and how to remove delegation later.

Update Notes

This section lists what changed when this document moved from its original Windows Server 2012 version to Windows Server 2022/2025.

Item	Original	Updated	Reason
Server interface options	Three switchable interfaces: Server Core, Minimal Server Interface, and Server Graphical Shell	Two install-time options: Server Core and Server with Desktop Experience	The Minimal Server Interface existed only on Windows Server 2012 and 2012 R2. Windows Server 2016 and later removed it. Current versions also do not let you switch between Server Core and Desktop Experience after setup, without a reinstall.
Resource-Based Kerberos Constrained Delegation	Not present	Added as a higher-security alternative to CredSSP	Microsoft's current guidance ranks this option ahead of CredSSP for most scenarios, since it does not cache credentials on the remote host. This option needs Windows Server 2012 or later, so it applies to this document's target versions.
CredSSP security note	Not present	Added a note on CredSSP's credential-caching risk, and when to use it	Microsoft's current documentation states CredSSP caches credentials on the remote server. If that server is compromised, the attacker gets those credentials.
Credential reuse and lifetime	Not present	Added the Get-Credential reuse pattern, and a note on credential lifetime and SecureString limits	Confirmed against the current Get-Credential reference: the credential object has no built-in expiration, and stays valid as long as it exists in memory.
Server and client roles on one host	Not present	Added a note that a single host can run CredSSP server mode and client mode at the same time, for a multi-hop chain	Confirmed against the current Enable-WSManCredSSP reference: the Server and Client roles set separate WS-Management settings, so one role does not disable the other.
Firewall reference link	A blog post URL for firewall rules	The companion WSFC_SQLServer.md document in this folder	The verified, current firewall document already in this folder supersedes the original blog post.
Version framing	"Windows Server 2012" throughout	"Windows Server 2022 and 2025"	This document now targets currently supported Windows Server versions.