51Using Remoting

forth. A listener also is set up to use either HTTP or HTTPS; if you want to be able to use both protocols, then you must have two listeners set up.

10.2.1 Authentication

WinRM has two levels of authentication: machine-level and user-level. User-level authen- tication involves the delegation of your logon credentials to the remote machine that you’ve connected to. The remote machine can undertake any tasks you’ve specified using your identity, meaning you’ll be able to do whatever you have permission to do and no more. By default, the remote machine can’t delegate your credentials to any other machines—which can lead to a problem called “the second hop” where you attempt, and usually fail, to perform an action on a third machine from within your remote session. We’ll deal with that later in the chapter.

Remoting also supports machine-level authentication. In other words, when you connect to a remote machine, your computer must trust that machine. Trust normally comes through mutual membership in an Active Directory domain, although it can also be manually configured in a number of ways. The practical upshot is that your computer will refuse to connect to any remote machine that it doesn’t know and trust. That can create complications for some environments where the machines aren’t all in the same domain, requiring additional configuration to get Remoting to work. 10.2.2 Firewalls and security

One of the joys of Remoting is that it operates over a single port: 5985 for HTTP and 5986 for HTTPS, by default, although you can reconfigure them if you like. It’s there- fore easy to set up firewall exceptions that permit Remoting traffic.

Some organizations, mainly those with very tight network security, may have some trepidation about enabling Remoting and its firewall exceptions. Our only advice is to “get over it.” Remoting is now a foundational, mandatory technology in Windows. Not allowing it would be like not allowing Ethernet. Without Remoting, you’ll find that many of Windows’ administrative tools and features simply don’t work, especially in Windows Server 2012 and later.

Remoting is more secure than what we’ve used in the past for these tasks. It authenticates, by default, using the Kerberos protocol, which never transmits pass- words on the network (encrypted or otherwise). Remoting uses a single, customizable port, rather than the thousands required by older protocols like RPCs. WinRM and Remoting have a huge variety of configuration settings that let you control who can use it, how much they can use it, and soon.

10.3

Using Remoting

In the next few sections, we’re going to walk you through the complete process of set- ting up and using Remoting. This will specifically cover the “easy scenario,” meaning that both your computer and the remote computer are in the same Active Directory domain. After we go over these basics, we’ll dive into all of the other scenarios that you might have to configure.

10.3.1 Enabling Remoting

Remoting needs to be enabled on any machine that will receive connections, which can include computers running either the server or a client version of the Windows operating system. Windows Server 2012, and later versions of the server OS, has Remoting enabled by default though client version of Windows don’t. The easy way to set up Remoting is to run Enable-PSRemoting(you need to be running PowerShell with elevated privileges). You could perform all of the steps manually but we don’t rec- ommend it.

NOTE You have to set up PowerShell Remoting on the machine itself. You can’t do it remotely. Having it enabled by default is a good step forward—one less configuration step on new machines.

The Enable-PSRemoting command performs several tasks:

 Starts (or restarts, if it’s already started) the WinRM service.

 Sets the WinRM service to start automatically from now on.

 Creates a WinRM listener for HTTP traffic on port 5985 for all local IP addresses.

 Creates a Windows Firewall exception for the WinRM listener. Note that this will fail on client versions of Windows if any network cards are configured to have a type of “Public,” because the firewall will refuse to create new exceptions on those cards. If this happens, change the network card’s type to something else (like “Work” or “Private,” as appropriate—Windows 8/2012 provides the Set- NetConnectionProfile cmdlet for this task) and run Enable-PSRemoting again. Alternately, if you know you have some Public network cards, add the -SkipNetworkProfileCheck parameter to Enable-PSRemoting. Doing so will successfully create a Firewall exception that allows incoming Remoting traffic only from the computer’s local subnet.

The command will also set up one or more of these endpoints:

 Microsoft.PowerShell

 Microsoft.PowerShell32

 Microsoft.ServerManager (for Server Manager)

 Microsoft.Windows.ServerManagerWorkflows (for Server Manager workflows)

 Microsoft.PowerShell.Workflow (for PowerShell workflow)

You’ll be prompted several times as the command runs; be sure to reply “Y” for “Yes” so that each step can complete properly. You can avoid the prompts by using the –Force parameter.

53