Chapter 12 - Remote access
For several years, Mac OS X and Linux systems have had a significant advantage over Windows systems. Using a technology called SSH (SSH stands for Secure Shell), Mac OS X and Linux system administrators could remotely log into their systems via the command line. Once logged in, they could control their remote systems through the command line, operating the computer as if they were sitting in front of it.
Windows, of course, has had remote access technology for years, via the Remote Desktop or Terminal Services software. Using Remote Desktop, you could remotely log into a server computer, seeing an entire graphical desktop on your computer. This is useful, but Remote Desktop has a few disadvantages over the text-based SSH – it’s often quite slower, and on a slow connection with a lot of latency, Remote Desktop can become sluggish. And as with all GUIs, Remote Desktop is less efficient than the command line. To perform a task on a remote computer, you would have to fire up the Remote Desktop client, log in, and then execute the task via the mouse. Using SSH, it’s far quicker to execute tasks on a remote Mac OS X or Linux machine – you merely log in using the SSH shell, type the command, and the task is finished. Windows lacked a software feature that could perform a similar remote management function.
All this changed with the introduction of WinRM – Windows Remote Management.
WHAT IS WINRM?
WinRM stands for Windows Remote Management. It is a Microsoft implementation of the SOAP protocol that lets you manage and control remote Windows machines over a network connection. The "SOAP" in the SOAP protocol stands for Simple Object Access Protocol, a set of rules for exchanging information over an HTTP web connection. One weakness of SSH is that it runs over specific TCP/IP ports (traditionally port 22, though most SSH server software lets you change the port), and that specific ports needs to be unblocked to allow SSH connections. SOAP runs over HTTP, and many firewalls allow HTTP traffic. Therefore, it’s possible to run WinRM without opening up any additional firewall ports.
WinRM runs on Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2. (Though you’ll need to install some patches from Microsoft in order to use WinRM on Windows XP.) WinRM has some substantial limitations, but it is quite useful, and hopefully Microsoft will improve it with future versions of Windows.
In the next section we’ll walk you through doing a basic setup of WinRM.
ENABLING WINRM
Performing a basic setup of WinRM is extremely easy, and takes only one command. First, launch a Command Prompt as an administrator (the setup will not work if you run the Command Prompt as a normal user). After the Command Prompt window launches, type this command:
WINRM QUICKCONFIG
After you type this command, it will ask if you want to proceed. Hit Y to proceed, and WinRM will activate itself (though you may need to reboot before it functions). What exactly does this command do?
First, it starts the WinRM service, and sets it to delayed automatic start (this means the service will start automatically when your computer boots, but only after other, more important services have first launched). Second, it configures Windows to accept commands from remote computers, even commands that require administrative rights. Third, it tells the WinRM listener to accept requests from the HTTP port. Finally, it opens a firewall exception in the local Windows firewall, so that the HTTP traffic can actually reach the WinRM listener.
Now that WinRM is enabled, you can use it to launch commands from a remote computer.
USING WINRS
To actually send commands to a computer running WinRM, you need to use the WINRS command. WINRS is short for “Windows Remote Shell”, and allows you to send command from your local Command Prompt to a remote computer running WinRM. Note that you must have an administrative account (or a domain account with administrative rights) on the target computer for WINRS to execute your command.
In this example, we’ll assume you want to send remote commands to a computer named System1, and that the computer is a member of the Fake.com domain. The DIR command is a good one to test with WINRS. This command will produce a listing of the root directory of the C drive on System1:
WINRS –R:SYSTEM1.FAKE.COM DIR C:\
Let’s go through the options in this command step-by-step.
WINRS, of course, launches the WINRS shell for sending commands to a remote system. The -R switch tells WINRS which computer should receive the command. The -R switch is followed by the colon (:) character, and immediately after the colon is the name of the computer that should receive the command. For the basic set up of WinRM, you'll need to use the FQDN (fully qualified domain name) of the remote computer to receive the command. Finally, after the FQDN comes the command to send to the remote computer.
You can launch any command you want via WINRS, with one important exception. The command cannot require any user input. Basically, if a command needs user input - like if it asks you to press Y to continue or N to cancel - it will not work. This does limit what you can do with WINRS, but with careful planning, you can avoid the limitations. (Like by using /Y switch with the XCOPY and COPY commands to keep them from asking for confirmation when overwriting a file.) However, some commands, like DISKPART, simply cannot be used via WINRS.
USING WINRS AS A DIFFERENT USER
Sometimes, you may need to run a remote command as a different user than your current account. WINRS also gives you this ability. To run a command as a different user, use the -U switch with WINRS. For instance, if you wanted to view the root directory of the C drive on System1 using the camalas account, you would use the WINRS command with this syntax:
WINRS -R:SYSTEM1.FAKE.COM -U:CAMALAS DIR C:\
WINRS will ask you for camalas's password. Assuming you enter the password (and assuming that camalas has administrative rights on the target system), the command will list the files in the root directory of System1's C drive.
Comments