Details on secure port configuration for WS-Management in Windows 7 and Windows Server 2008 R2

Applies To: Windows Server 2008 R2

This article provides some important details on secure port configuration for WS-Management in WinRM 2.0, which is included in Windows 7 and Windows Server 2008 R2. WinRM can be downloaded separately as part of the Windows Management Framework for Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

Secure port configuration details

1. Summary

2. Functional behavior

   1. New default values

   2. Compatibility listeners

   3. Listener migration

   4. PowerShell-specific changes

   5. WinRM-specific changes

   6. Working in mixed environments

   7. Firewall rules

   8. Event forwarding

Summary

Servers connected to the internet are typically configured to allow traffic from many different users who warrant various levels of trust. Exposing a management interface over traditional ports potentially exposes important system-altering capabilities to malicious users. For this reason, it is more secure to expose a management interface through a port that does not handle web traffic.

In order to provide more secure default configuration, and in order to lessen the likelihood that a user will unknowingly create a WS-Management listener on these common ports, the default configuration was changed in WinRM 2.0 to a different set of ports. When upgrading to WinRM 2.0, any listener that exists on port 80 or 443 will automatically be migrated to the new default ports of 5985 for HTTP and 5986 for HTTPS.

Functional behavior

New default values

The default ports used when creating new WS-Management listeners will be changed from 80 for HTTP and 443 for HTTPS to 5985 for HTTP and 5986 for HTTPS.  Any listeners created manually without specifying a port, or listeners created using quick config, will listen on these new ports. Similarly, the default ports used when issuing requests from the client will also be changed to the new ports.  Any client requests sent out without specifying a port will be sent to these new ports.

Compatibility listeners

In order to aid interoperability with computers that have not been upgraded, new configuration settings have been introduced to create compatibility listeners on ports 80 and 443 for HTTP and HTTPS, respectively. These settings can be enabled directly through the WinRM configuration console command line call as follows.

• winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}

• winrm set winrm/config/service @{EnableCompatibilityHttpsListener="true"}

The compatibility listeners can also be enabled via Group Policy using the new settings under Computer Configuration/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service.

These compatibility listeners are not directly addressable, meaning they cannot be retrieved via winrm get and their settings cannot be modified. When enumerated, these listeners will be tagged with the string Source=”Compatibility” in order to identify them, as in the following example.

C:\Windows\system32>winrm e winrm/config/listener

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 157.59.85.27, ::1, 2001:4898:0:fff:200:5efe:157.59.85.27, 2001:4898:2b:3:594:e48f:e99a:de17, 2001:4898:2b:3:4c54:7d1e:a5f6:6ea, fe80::100:7f:fffe%11, fe80::200:5efe:157.59.85.27%13, fe80::4c54:7d1e:a5f6:6ea%12

Listener [Source="Compatibility"]
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 157.59.85.27, ::1, 2001:4898:0:fff:200:5efe:157.59.85.27, 2001:4898:2b:3:594:e48f:e99a:de17, 2001:4898:2b:3:4c54:7d1e:a5f6:6ea, fe80::100:7f:fffe%11, fe80::200:5efe:157.59.85.27%13, fe80::4c54:7d1e:a5f6:6ea%12

By default these settings are both set to Enabled = False for new installations of WinRM 2.0. For upgrades, the setting values will depend on the existing configuration. See the following section for more details.

Listener migration

The following table defines the listener settings that exist after upgrading to WinRM 2.0.

PowerShell-specific changes

The New-PSSession PowerShell cmdlet has been modified to take these changes into account.  New-PsSession now takes on two different parameter sets:  ComputerName and ConnectionURI.

• When the ComputerName parameter set is specified, then the default client port setting is used in the WinRM 2.0 configuration unless a port is explicitly specified.

• When the ConnectionUri parameter is passed, then the string will be interpreted using ports 80 for HTTP and 443 for HTTPS by default. 

The following WSMan cmdlets have also undergone the same change as described above for New-PSSession.

• Connect-WSMan

• Get-WSManInstance

• Invoke-WSManAction

• New-WSManInstance

• Remove-WSManInstance

• Set-WSManInstance

WinRM-specific changes

The WinRM cmd line tool will share the behavior of the New-PSSession cmdlet in the following scenarios.

• If a user passes a computer name to the winrm cmd line using the –r:<Computername> switch, then WinRM 2.0 will use the default client HTTP port, port 5985.

• If a user passes a computer name to the winrm cmd line using the –r:<Computername> switch, and the –UseSSL flag is passed in, then WinRM 2.0 will use the default client HTTPS port, port 5985.

• If a user passes a computer name to the winrm cmd line using the –r:<Computername> switch, and if a port is specified, then WinRM 2.0 will use the specified port.

• If a user passes the connection URI to the winrm cmd line, as in the example –r:https://Mycomputer/wsman, then WinRM 2.0 will interpret the URI using ports 80 for HTTP and 443 for HTTPS by default.

Working in mixed environments

If you have a mixed environment of computers, where a number of them have WinRM 2.0 installed and a number do not, then there are a few scenarios that will require administrative action in order to maintain proper functionality.

• If the client is updated so the default ports are 5985/5986 but the server is unchanged and it is still listening on ports 80/443, the client must either explicitly specify ports 80/443 when connecting or specify the remote machine using a ConnectionUri.

• If the client operating system has a new installation of Windows 7, and the default ports are 5985 for HTTP and 5986 for HTTPS, but the server is unchanged so that it is still listening on 80/443, then the situation is the same. The client must either explicitly specify ports 80/443 when connecting or specify the remote server using a ConnectionUri.

• If the server operating system has a new installation of Windows 7, and it is listening on ports 5985 for HTTP and 5986 for HTTPS, but the client is unchanged so that its default ports are still 80/443, the administrator must explicitly create listeners on ports 80/443.

Firewall rules

There are two firewall rules within the same group: one for port 80 and one for port 5985. The following table defines the status of these two rules in various upgrade scenarios.

Event forwarding

The tables below lay out the various situations that may occur with event forwarding, and what steps need to be taken to correct potential issues.

Collector-initiated PUSH/PULL subscriptions

Source-initiated PUSH subscriptions with existing subscriptions specifying collector as Server=<FQDN>

Source-initiated PUSH subscriptions with existing subscriptions specifying collector as Server=https://<FQDN>