5.2 PowerShell Remoting, WinRM & the Kerberos Double-Hop Problem

PowerShell Remoting, WinRM & the Kerberos Double-Hop Problem

PowerShell Remoting is the bedrock of modern Windows Server systems management and automation. It allows systems administrators to execute commands, automate deployments, query inventory, and manage state across thousands of on-premises physical nodes, hypervisors, and cloud virtual machines simultaneously.

This section covers the transport itself: the WS-Management and WinRM protocols, interactive versus fan-out remoting, and the notorious Kerberos Double-Hop authentication problem together with its secure mitigations. The two least-privilege and cross-platform layers that build on this transport have their own sections — Just Enough Administration (JEA) in section 5.3, and OpenSSH with PowerShell remoting over SSH in section 5.4.

---

1. PowerShell Remoting Architecture: WinRM & WS-Management

PowerShell Remoting relies on the Windows Remote Management (WinRM) service, Microsoft's implementation of the industry-standard WS-Management (WS-Man) protocol—a SOAP-based, firewall-friendly protocol running over standard HTTP and HTTPS transports.

+-----------------------------------------------------------------------------------------+
|                         POWERSHELL REMOTING TRANSPORT ARCHITECTURE                      |
|                                                                                         |
|  [Admin Workstation]                                       [Target Windows Server]      |
|  +---------------------+                                   +-------------------------+  |
|  | PowerShell Console  |                                   | WinRM Listener          |  |
|  | Enter-PSSession /   |                                   | - Port 5985 (HTTP)      |  |
|  | Invoke-Command      |                                   | - Port 5986 (HTTPS)     |  |
|  +---------------------+                                   +-------------------------+  |
|             |                                                           |               |
|             |========== WS-Management / SOAP XML Encapsulated ==========|               |
|             |           (Payload Encrypted via Kerberos/SPNEGO)         |               |
|             v                                                           v               |
|  +---------------------+                                   +-------------------------+  |
|  | Windows Defender    |                                   | WsmSvc (WinRM Service)  |  |
|  | Firewall Outbound   | ===== (TCP 5985 / 5986 Across LAN) =====> | - Spawns wsmprovhost.exe|  |
|  +---------------------+                                   | - Executes in Runspace  |  |
|                                                            +-------------------------+  |
+-----------------------------------------------------------------------------------------+

Listener Ports and Default Cryptographic Protections:

• TCP Port 5985 (HTTP Listener): The default port for standard PowerShell Remoting. Although the URI prefix uses http://, in an Active Directory domain environment, the entire payload is encrypted at the application layer using SPNEGO/Kerberos cryptographic session keys (AES-256). No plaintext passwords or commands cross the wire.
• TCP Port 5986 (HTTPS Listener): The secure transport port requiring an SSL/TLS certificate bound to the WinRM listener. Mandatory when authenticating across non-domain boundaries or untrusted perimeter networks where Kerberos mutual authentication is unavailable.

Enabling and Configuring WinRM:

Executing Enable-PSRemoting -Force performs all necessary configuration steps:

1. Starts and sets the WinRM (wsmsvc) service startup type to Automatic.
2. Creates a WinRM listener on 0.0.0.0 (IPv4) and :: (IPv6) on port 5985.
3. Enables the Windows Defender Firewall inbound rule group: Windows Remote Management (HTTP-In).
4. Configures the default session configurations (microsoft.powershell, microsoft.powershell32, microsoft.powershell.workflow).

# Initialize Remoting and configure maximum envelope size
Enable-PSRemoting -Force -SkipNetworkProfileCheck

# Configure WinRM Listener for HTTPS on Port 5986 with a CA-issued certificate
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like '*server01*' } | Select-Object -First 1
New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $cert.Thumbprint -Force

# Open Inbound Port 5986 in Windows Defender Firewall
New-NetFirewallRule -Name "WinRM-HTTPS-In" -DisplayName "Windows Remote Management (HTTPS-In)" `
    -Profile Any -LocalPort 5986 -Protocol TCP -Direction Inbound -Action Allow

Cross-Domain and Workgroup Remoting (TrustedHosts Configuration):

When connecting to a server in an untrusted domain or a workgroup, Kerberos mutual authentication cannot take place. The client refuses connection unless HTTPS is used or the target is added to the client's WSMan:\localhost\Client\TrustedHosts list.

# Add specific target servers or IP subnets to TrustedHosts on the client
Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "192.168.10.*,web01.contoso.local" -Concatenate -Force

[!WARNING] Security Implications of TrustedHosts *: Setting TrustedHosts to * forces the client to bypass target server identity verification. This exposes credentials to man-in-the-middle (MITM) impersonation attacks if NTLM authentication is negotiated over unencrypted HTTP (Port 5985). Always prefer WinRM HTTPS (Port 5986) with explicit certificate validation for cross-domain and perimeter nodes.

---

2. Interactive (1:1) vs Fan-Out (1:Many) Remoting

PowerShell provides two primary execution paradigms: interactive single-system troubleshooting and scalable distributed fan-out automation.

+-----------------------------------------------------------------------------------------+
|                        1:1 INTERACTIVE VS 1:MANY FAN-OUT REMOTING                       |
|                                                                                         |
|   [1:1 INTERACTIVE - Enter-PSSession]          [1:MANY FAN-OUT - Invoke-Command]        |
|   +---------------------------------+          +------------------------------------+   |
|   | Admin Workstation               |          | Admin Workstation                  |   |
|   |  Enter-PSSession -Computer Srv1 |          |  Invoke-Command -Computer Srv1..100|   |
|   +---------------------------------+          +------------------------------------+   |
|                   |                                     /         |         \           |
|                   v (Single Pipe)                      v          v          v          |
|           +---------------+                     +------+   +------+   +------+          |
|           | Server 1      |                     | Srv1 |   | Srv2 |   |Srv100|          |
|           | Interactive   |                     +------+   +------+   +------+          |
|           | Session Prompt|                     (Executes Scriptblock concurrently      |
|           +---------------+                      in parallel; throttle limit: 32)       |
+-----------------------------------------------------------------------------------------+

Comparing Remoting Cmdlets

Advanced Distributed Execution Syntax

# Mass inventory query across 50 servers in parallel with custom throttling
$ServerList = Get-Content -Path 'C:\Inventory\servers.txt'
$DiskReport = Invoke-Command -ComputerName $ServerList -ThrottleLimit 50 -ScriptBlock {
    Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
        Select-Object SystemName, DeviceID, `
            @{Name="SizeGB"; Expression={[math]::Round($_.Size / 1GB, 2)}}, `
            @{Name="FreeGB"; Expression={[math]::Round($_.FreeSpace / 1GB, 2)}}
}

# Disconnected session orchestration across maintenance cycles
$Session = New-PSSession -ComputerName 'SQL-PROD-01' -Name 'MaintenanceRun'
Invoke-Command -Session $Session -ScriptBlock { Start-ServiceMaintenanceTask } -InDisconnectedSession
# ... (Hours later, reconnect from any admin workstation) ...
$ReconnectedSession = Connect-PSSession -ComputerName 'SQL-PROD-01' -Name 'MaintenanceRun'
Receive-PSSession -Session $ReconnectedSession

---

3. The Kerberos Double-Hop Problem & Secure Mitigations

When an administrator establishes a remote PowerShell session to Server A (Hop 1) and then attempts to execute a command from Server A that reaches out to Server B or a network share (Hop 2), the second operation fails with an Access Denied error. This is the classic Kerberos Double-Hop (Second-Hop) Problem.

Double-Hop Resolution Strategies Comparison

Why the Double-Hop Occurs:

During standard Kerberos authentication in Hop 1, the client sends a Kerberos service ticket to Server A. Server A validates the ticket and creates an impersonation token for the user. However, by default design in Active Directory Kerberos security, Server A does not possess the user's password or TGT key. Consequently, Server A cannot generate a new Kerberos service ticket to present to Server B. The second-hop connection is downgraded to NT AUTHORITY\ANONYMOUS LOGON, causing immediate access denial.

Configuring Resource-Based Constrained Delegation (RBCD) via PowerShell:

# Allow Server A (Hop 1) to delegate Kerberos credentials to Server B (Target File Server / Hop 2)
$ServerA = Get-ADComputer -Identity "SRV-MGMT-01"
Set-ADComputer -Identity "SRV-FILE-02" -PrincipalsAllowedToDelegateToAccount $ServerA

[!CAUTION] The CredSSP Exam Trap: While running Enable-WSManCredSSP -Role Server and Enable-WSManCredSSP -Role Client technically solves the multi-hop problem, CredSSP is strictly discouraged by Microsoft in production enterprise environments. CredSSP sends plaintext user credentials to the intermediate server and stores them in memory, allowing a local administrator on Server A to steal domain credentials. On the AZ-800 exam, choose Kerberos Constrained Delegation (KCD), Resource-Based Constrained Delegation (RBCD), or JEA, not CredSSP.

---

Double-Hop Resolution Strategies Comparison