Export (0) Print
Expand All

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

Updated: December 30, 2009

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.

  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

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.

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.

ImportantImportant
If the default client ports are set to something other than 80/443, they will not be modified.

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.

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

 

Existing Listener

Settings After Upgrade

Transport = HTTP

Port = 80

New listener with same settings created on port 5985

winrm/config/service/EnableCompatibilityHttpListener = True

Group Policy setting “Turn On Compatibility HTTP Listener” = Enabled

Transport = HTTP

Port not set to 80

Listener remains unchanged

winrm/config/service/EnableCompatibilityHttpListener = False

Group Policy setting “Turn On Compatibility HTTP Listener” = Not Configured

Transport = HTTPS

Port = 443

New listener with same settings created on port 5986

winrm/config/service/EnableCompatibilityHttpsListener = True

Group Policy setting “Turn On Compatibility HTTPS Listener” = Enabled

Transport = HTTPS

Port not set to 443

Listener remains unchanged

winrm/config/service/EnableCompatibilityHttpsListener = False

Group Policy setting “Turn On Compatibility HTTPS Listener” = Not Configured

ImportantImportant
If the Group Policy settings are enabled through migration/upgrade, then the HTTP.sys reservations and SSL certificates are automatically set up. If an administrator enables the Group Policy settings directly these additional settings must also be configured through Group Policy.

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

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:http://Mycomputer/wsman, then WinRM 2.0 will interpret the URI using ports 80 for HTTP and 443 for HTTPS by default.

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.

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.

 

Port 80 firewall rule

Port 5985 rule

Upgrade: port 80 rule enabled

Enabled

Enabled

Upgrade: port 80 rule disabled

Disabled

Disabled

New installation of WinRM 2.0

Disabled

Disabled

noteNote
When the compatibility listener is enabled, the firewall rule for port 80 will be enabled.

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

Collector

Source

Existing subscriptions

New subscriptions

New installation of Windows 7

New installation of Windows 7

Not Applicable

The event forwarding works correctly.

New installation of Windows 7

WinRM 1.1 installed

Not Applicable

Need to specify port 80 for HTTP explicitly.

New installation of Windows 7

Upgraded to WinRM 2.0

Not Applicable

The event forwarding works correctly.

WinRM 1.1 installed

New installation of Windows 7

Update subscriptions on the collector to add the port 5985 for HTTPS.

Need to specify port 5985 explicitly.

WinRM 1.1 installed

WinRM 1.1 installed

The event forwarding works correctly.

The event forwarding works correctly.

WinRM 1.1 installed

Upgraded to WinRM 2.0

The event forwarding works correctly.

The event forwarding works correctly.

Upgraded to WinRM 2.0

New installation of Windows 7

Update subscriptions on the collector to add the port 5985 for HTTPS.

The event forwarding works correctly.

Upgraded to WinRM 2.0

WinRM 1.1 installed

The event forwarding works correctly.

Need to specify port 80 for HTTP explicitly.

Upgraded to WinRM 2.0

Upgraded to WinRM 2.0

The event forwarding works correctly.

The event forwarding works correctly.

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

Collector

Source

Existing subscriptions

New subscriptions

New installation of Windows 7

New installation of Windows 7

Not Applicable

Can specify the collector as Server=http://<FQDN>:5985 or Server=<FQDN>

New installation of Windows 7

WinRM 1.1 installed

Not Applicable

Need to specify the collector as Server=http://<FQDN>:5985

New installation of Windows 7

Upgraded to WinRM 2.0

Not Applicable

Can specify the collector as Server=http://<FQDN>:5985 or Server=<FQDN>

WinRM 1.1 installed

New installation of Windows 7

Update collector info on the source to Server=http://<FQDN>

Need to specify the collector as Server=http://<FQDN>

WinRM 1.1 installed

WinRM 1.1 installed

The event forwarding works correctly.

The event forwarding works correctly.

WinRM 1.1 installed

Upgraded to WinRM 2.0

Update collector info on the source to Server=http://<FQDN>

Need to specify the collector as Server=http://<FQDN>

Upgraded to WinRM 2.0

New installation of Windows 7

The event forwarding works correctly.

The event forwarding works correctly.

Upgraded to WinRM 2.0

WinRM 1.1 installed

The event forwarding works correctly.

The event forwarding works correctly.

Upgraded to WinRM 2.0

Upgraded to WinRM 2.0

The event forwarding works correctly.

The event forwarding works correctly.

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

Collector

Source

Existing subscriptions

New subscriptions

New installation of Windows 7

New installation of Windows 7

Not Available

Can specify the collector as Server=http://<FQDN>:5985 or Server=<FQDN>

New installation of Windows 7

WinRM 1.1 installed

Not Applicable

Need to specify the collector as Server=http://<FQDN>:5985

New installation of Windows 7

Upgraded to WinRM 2.0

Not Applicable

Can specify the collector as Server=http://<FQDN>:5985 or Server=<FQDN>

WinRM 1.1 installed

New installation of Windows 7

Update collector info on the source to Server=http://<FQDN>

Need to specify the collector as Server=http://<FQDN>

WinRM 1.1 installed

WinRM 1.1 installed

The event forwarding works correctly.

The event forwarding works correctly.

WinRM 1.1 installed

Upgraded to WinRM 2.0

Update collector info on the source to Server=http://<FQDN>

Need to specify the collector as Server=http://<FQDN>

Upgraded to WinRM 2.0

New installation of Windows 7

The event forwarding works correctly.

Can specify the collector as Server=http://<FQDN>:5985 or Server=<FQDN>

Upgraded to WinRM 2.0

WinRM 1.1 installed

The event forwarding works correctly.

Need to specify the collector as Server=http://<FQDN>:5985

Upgraded to WinRM 2.0

Upgraded to WinRM 2.0

The event forwarding works correctly.

Can specify the collector as Server=http://<FQDN>:5985 or Server=<FQDN>

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft