Besides letting you remotely manage Windows computers, it performs well and it's free
Making remote connections to servers for management and administration is a core requirement for every systems administrator. As long as Windows remains a predominately GUI-focused interface, we remain reliant on remote control software that provides access to the entire Windows interface. During the past few years, Remote Desktop Connection has become the de facto standard for remotely managing Windows computers for three primary reasons: performance is good, multiple people can connect to the same computer at the same time, and it’s free and included by default with every version of Windows since Windows 2000.
Remote Desktop Connection 6.0, the latest version of Microsoft's free RDP client, is included with Windows Vista and can be downloaded for Windows Server 2003 and Windows XP. Microsoft did a good job maintaining backward compatibility, so you can upgrade to the new client and still connect to Windows Server 2003, Windows XP, and Win2K computers. Microsoft added many new features in anticipation of Windows Vista and Longhorn, but you can take advantage of other new features now. Some new features enhance Remote Desktop Connection's security and performance.
You can download Remote Desktop Connection 6.0 for XP and Windows 2003 from the Microsoft Download Center. (For more information about what downloading entails, see the Microsoft article "Remote Desktop Connection 6.0 client update is available for download in the Microsoft Download Center," (http://support.microsoft.com/kb/925876 ). This is the client only, meaning that you install it on the computer you want to use to connect to and manage other computers. You don't need to install anything on the computers you want to manage. After you've installed the program, you can run it quickly by clicking Start, Run and typing mstsc. (Alternatively you can click Start, Programs, Accessories, Communications, Remote Desktop Connection.)
If you run the program from the command line, you can take advantage of some useful options. For example, typing
mstsc /console /span
instructs Remote Desktop Connection to connect to the console (which gives you the same logon session used by the interactive session at the keyboard instead of starting a new Terminal Services session) and to span the client display across two monitors. The /span parameter is new to Remote Desktop Connection 6.0, and it’s one of my favorite new features. Now when I remote into my servers, I can really take advantage of the screen real estate attached to my workstation.
From the new RDP client dialog box, click on the Advanced tab to configure the new Server Authentication feature, which adds a layer of security to the connection setup process. When connecting to a Vista or Longhorn computer, Remote Desktop Connection will attempt to validate that the server you wish to connect to is really that server. Until you upgrade all your systems to Vista or Longhorn, I recommend the Warn the user if the connection cannot be authenticated setting, which results in the warning that Figure 1 shows. After you’ve fully deployed Vista and Longhorn, you can enable the Do not connect if the server cannot be authenticated option.
The server authentication used here is different from the Transport Layer Security (TLS) certificate–based server authentication used by Windows 2003 Service Pack 1 (SP1) and Remote Desktop Connection 5.2. You don't need a public key infrastructure (PKI) environment to utilize Remote Desktop Connection 6.0–based server authentication, but you do need to connect to a computer running either Vista or Longhorn.
Network Level Authentication
The Remote Desktop Connection client supports a new authentication mechanism called Network Level Authentication (NLA), which asks for your credentials before you connect and attempts to complete the authentication process before establishing the remote session. Figure 2 shows the message you see when authentication isn't successful. In contrast, when making a new connection using earlier versions of the RDP client and when not connecting to Vista or Longhorn computers, the client establishes a full RDP session first, then users enter their credentials at a typical Windows GUI logon screen.
By authenticating a client before establishing the RDP session, NLA saves resources and bandwidth and reduces the chance for an attacker to repeatedly enter passwords at a logon prompt. This is because only the authentication network information is exchanged instead of a full RDP session, at which point the computer is already possibly vulnerable to a potential attack. Both the client and server must be NLA aware, so this feature is supported only when connecting from the new client to computers running Vista or Longhorn. Due to the new authentication procedures the Remote Desktop Connection client performs, you'll likely encounter additional prompts throughout the connection process. Most of these prompts are essential to maintain backward compatibility yet still support new features.
No More Saved Passwords in RDP Files
Aside from NLA, the RDP client changes a bit where you enter your credentials and how it stores them. When entering your credentials into the RDP client, you no longer type a username, password, and domain on the General tab of the RDP client. Instead, when you first try to connect to a remote machine, a separate Windows security dialog box asks for your credentials then offers to remember those credentials.
The new client doesn't store the credentials in a saved RDP profile (a text file), as do previous versions; instead, it stores credentials in the new Credential Manager. This lack of portable, saved credentials increases the security of your system but could affect how you manage your servers. For example, with the new client you can’t create an RDP session with saved credentials and email it to a colleague to execute and connect as another user specified in the RDP file. However, you can still save and distribute RDP files, such as the name of the server and specific connection settings, but not the credentials of the user. Users will be required to authenticate the first time (at which time, they can direct Remote Desktop Connection to remember their credentials).
Multiple Confirmation Dialog Boxes
Some of the additional prompts encountered throughout the connection process can be managed through client or server settings or through Group Policy. For example, Always prompt client for password upon connection is a popular Group Policy Object (GPO) setting. If this policy is set, you’ll need to enter your credentials twice: once for NLA and again at the RDP screen. Of course, after Longhorn and Vista are deployed everywhere, you can require just NLA and it will log you on and you won’t see the second, traditional RDP authentication logon prompt. In the meantime, if your company requires that users always be prompted, users can simply click OK in the NLA credential dialog box, then enter their credentials when they're asked a second time after the RDP session is established.
The Remote Desktop Connection client supports mapping local resources to redirect sound, keyboard, and local devices from the host to the client computer. For example, if you’ve enabled audio redirection and the host computer at work gets an email message while your client computer at home is remotely connected, then your home computer's mail client will actually ding if the mail client you're using supports that audible notice.
The XP Remote Desktop Connection client limits you to redirecting disk drives, printers, and serial ports; however, with the Remote Desktop Connection 6.0 client running on Vista or Longhorn, you can also redirect the host computer’s clipboard and specify individual hard drives you wish to make available. Plus, you can redirect plug-and-play devices and Smart Cards. For example, I plugged my digital camera into my home computer running Vista and accessed photos from the camera directly from my work computer, which was also running Vista. I was accessing the camera directly, not as a result of some sort of an auto-mounted and mapped drive.
The mapping of local drives to the remote computer has security implications. For example, if you’ve enabled drive redirection from a remote computer to your work computer and you navigate to My Computer on your work computer in an RDP session, then you’ll see not only your work computer’s hard drives but also links to your home computer’s local hard drives. This visual makes it easy to copy files between the two computers. If your company’s security policy prohibits copying work data to and from non-company computers, you can prohibit this mapping by using a GPO.
Remote Desktop Connection lets you tweak the appearance of the remote session depending on the available bandwidth so that you can disable features if you have limited bandwidth. For example, to maximize performance, you can disable the desktop background, hide the contents of a window while dragging, disable menu and window animations and themes, and enable bitmap caching.
Remote Desktop Connection 6.0 includes these options, plus it lets you do font smoothing (coloring the edges of letters varying shades of gray so that characters appear less jagged) and desktop composition. The font smoothing looks pretty good—it resembles the ClearType option introduced in XP. But it’s the desktop composition feature that really makes a difference. Desktop composition enables not only visually cool features such as Vista's Aero translucent UI but also dramatically improves the performance when moving a window around on the screen. On a 100Mbps network, I enabled everything—including 32-bit color and the full “experience”—and it was remarkable: This is the best-looking Remote Desktop Connection client interface to date. Even with a video playing, I could move the window around and the video continued to play without a lot of stuttering and lag.
Preparing for the Future
Remote Desktop Connection 6.0's Connect from anywhere option anticipates the Longhorn feature TS Gateway, which provides RDP over Secure Sockets Layer (SSL). RDP uses TCP port 3389 and requires firewalls to pass that protocol to an internal server if a remote Internet-based connection is allowed. TS Gateway uses industry standard SSL (which uses TCP port 443) to encapsulate (and encrypt) the entire RDP session. (For more information about providing RDP over SSL with today’s RDP releases, see "Use SSH for Secure RDP Connections," InstantDoc ID 94669.) Also, you can put TS Gateway on your perimeter and allow external access only to it. Remote clients connect to the gateway, and it in turn, connects to internal computers. For this reason and many more, Remote Desktop Connection 6.0 is a worthwhile upgrade as part of an eventual migration to Vista and Longhorn.