WinRM/WSMan Remoting on Windows: Configuration and Trust

1. WSMan remoting is the Windows-to-Windows path in current PowerShell

WS-Management (WSMan) is a management protocol. Microsoft’s Windows implementation is Windows Remote Management (WinRM). Current PowerShell 7.6 documentation states that supported WSMan remoting is between Windows systems; cross-platform remoting should use SSH.

This lesson therefore treats WinRM configuration as Windows administration and a security boundary, not as a portable PowerShell feature.

2. Enable-PSRemoting changes machine configuration

On Windows, running Enable-PSRemoting from an elevated PowerShell session configures WinRM and PowerShell remoting endpoints for the PowerShell installation you are running. It can start/configure the WinRM service, create a listener/firewall exception, enable session configurations, and set endpoint access descriptors.

That is why this command is not a harmless “turn on a shell” toggle. It deliberately changes remote-management exposure.

# Inspect first. Windows only.
Get-Command Enable-PSRemoting,Test-WSMan -ErrorAction SilentlyContinue
Get-Service WinRM -ErrorAction SilentlyContinue

# Configuration change -- run only on a disposable/authorized Windows lab host,
# from an elevated PowerShell session:
# Enable-PSRemoting -Force

3. Listener and endpoint are different layers

A TCP connection to a WinRM port can succeed while the PowerShell endpoint still rejects the user. Troubleshoot one layer at a time.

4. Inspect-only path for a real Windows workstation

These commands read the local remoting state. They do not enable remoting or edit TrustedHosts.

if ($IsWindows) {
    Get-Service WinRM -ErrorAction SilentlyContinue |
        Select-Object Name,Status,StartType

    Get-ChildItem WSMan:\localhost\Listener -ErrorAction SilentlyContinue
    Get-PSSessionConfiguration -ErrorAction SilentlyContinue |
        Select-Object Name,PSVersion,Permission

    Test-WSMan -ComputerName localhost -ErrorAction SilentlyContinue
} else {
    'WSMan inspection in this lesson is Windows-only; use SSH remoting cross-platform.'
}

5. Authentication answers identity; authorization answers permission

In an Active Directory domain, Kerberos normally gives Windows remoting a strong mutual-authentication model when names, domain membership, and service configuration are correct. Negotiate can select an available mechanism. In workgroup or other non-domain scenarios, identity validation is harder because Kerberos trust is not automatically available.

Do not solve that difficulty by copying a wildcard TrustedHosts command from a blog. TrustedHosts weakens the client-side identity-assurance model and affects all users of the computer.

6. TrustedHosts is a trust exception, not a connectivity fix

The TrustedHosts list tells a WSMan client which remote names it is willing to trust when normal mutual authentication cannot establish identity. Microsoft explicitly warns that changing it affects all users on the machine. Broad wildcards increase impersonation risk.

# Read-only inspection; Windows and administrator rights may be needed for changes.
Get-Item WSMan:\localhost\Client\TrustedHosts -ErrorAction SilentlyContinue

# Deliberately NOT recommended as a default:
# Set-Item WSMan:\localhost\Client\TrustedHosts -Value '*' 

Prefer domain/Kerberos where available, or an appropriately validated HTTPS/certificate design for environments that require WSMan outside that trust model.

7. HTTPS protects the transport and can strengthen server identity

WSMan encrypts PowerShell content through its security mechanisms, and HTTPS adds TLS transport protection plus certificate-based server identity when configured correctly. HTTPS is not “secure” merely because port 5986 is open: certificate hostname, validity, private-key access, listener configuration, and trust all matter.

Certificate/listener creation is environment-specific and privileged, so this course keeps the default lab inspect-only. Build it in a disposable Windows VM if you need hands-on configuration practice.

# Connection shape only -- requires a correctly configured HTTPS WSMan listener.
$sessionOptions = @{
    ComputerName = 'server01.example.test'
    UseSSL       = $true
    ErrorAction  = 'Stop'
}
# $s = New-PSSession @sessionOptions
# try { Invoke-Command -Session $s -ScriptBlock { Get-Date } }
# finally { Remove-PSSession $s }

-UseSSL selects the HTTPS WSMan transport; it does not make an invalid or untrusted certificate acceptable.

8. The double-hop problem is delegated identity, not a PowerShell syntax bug

Suppose your laptop connects to ServerB, then code on ServerB tries to access ServerC using your identity. Your original credentials are not automatically delegated for that second network hop. That is the double-hop problem.

Solutions involve security architecture—such as constrained delegation, JEA/run-as designs, or carefully scoped credential delegation. CredSSP can make fresh credentials available on the intermediate host but increases credential-theft risk if that host is compromised. Do not enable it merely to make an error disappear.

# Inspect CredSSP state only; Windows-only when this module is available.
if (Get-Command Get-WSManCredSSP -ErrorAction SilentlyContinue) {
    Get-WSManCredSSP
}

# Enabling CredSSP is intentionally not part of the default lab.

Inspection is safer than changing delegation during a beginner lab. If a workflow needs a second hop, choose the delegation design deliberately with security requirements.

9. Remoting configuration defines who may execute code

A remoting endpoint is effectively a remote code-execution surface. Treat its listener, authentication, endpoint ACL, language mode, available commands, account privileges, and logging as part of your security design. “It works” is not a sufficient acceptance criterion.

Chapter 16 will go deeper into JEA, constrained language, signing, secrets, and least privilege. Here, the operational rule is to expose only what is necessary and test authorization separately from network reachability.

10. Troubleshoot from transport toward PowerShell

11. Lab: produce a local remoting readiness record

This lab remains read-only and can run on any platform. On Windows it inspects WinRM/WSMan capability; elsewhere it records that the Windows transport is unavailable and points forward to SSH.

$record = [ordered]@{
    Platform               = if ($IsWindows) {'Windows'} elseif ($IsLinux) {'Linux'} else {'macOS/Other'}
    EnablePSRemotingExists = [bool](Get-Command Enable-PSRemoting -ErrorAction SilentlyContinue)
    TestWSManExists         = [bool](Get-Command Test-WSMan -ErrorAction SilentlyContinue)
    WinRMService           = $null
    LocalWSTest            = $null
}

if ($IsWindows) {
    $svc = Get-Service WinRM -ErrorAction SilentlyContinue
    if ($svc) { $record.WinRMService = $svc.Status.ToString() }
    try {
        Test-WSMan -ComputerName localhost -ErrorAction Stop | Out-Null
        $record.LocalWSTest = $true
    } catch {
        $record.LocalWSTest = $false
    }
}

[pscustomobject]$record

12. Verification checklist

• You can distinguish WinRM, WSMan, a listener, and a PowerShell endpoint.
• You know Enable-PSRemoting is a privileged configuration change.
• You treat TrustedHosts as a trust exception with security impact.
• You can explain Kerberos/domain versus workgroup identity concerns conceptually.
• You understand why HTTPS certificate validation matters.
• You recognize the double-hop problem as credential delegation.
• You troubleshoot connectivity, authentication, authorization, and endpoint state separately.

13. Knowledge check

14. Summary and next bridge

Windows WSMan remoting is a configured remote-management surface, not merely a command parameter. Listeners, authentication, endpoint permissions, and delegation define trust. Lesson 3 assumes you have either an authorized Windows remoting target or a prepared lab and focuses on day-to-day PSSession lifecycle, remote state, file transfer, and structured output.

15. Authoritative references

• Microsoft Learn — WSMan remoting in PowerShell
• Microsoft Learn — about_Remote_Requirements
• Microsoft Learn — about_Remote_Troubleshooting
• Microsoft Learn — Making the second hop