Remote Desktop Protocol (RDP) in Windows Small Business Server 2003

Top of the morinng to ya! I am up and at 'em here in Seattle on the 520AM ferry enroute to the airport and some time in the San Francisco area...really starting to spend more time down there what with the hot technology sector (can u say SOMA?). So a quick post from Chapter 8 of my Windows Small Business Server 2003 Best Practices book - as u might know - I am posting up several pages per day from this book into the WILD for your reading pleasure. Why do I do this? Because I am a nice person! I will keep posting until SBS 2008 ships!

Today we explore the Remote desktop Protocol (RDP) in the mobility realm of SBS 2003.

cheers...harrybbbb

harry brelsford, smb nation's ceo www.smbnation.com

Microsoft Small Business Specialist (SBSC), MBA MCSE MCT CNE CLSE CNP

Did u know I host my big annual conference in early OCtober in Seattle!

###

Exploring RDP


Oops! I almost forgot some more stuff on RDP that I wanted to share (this has an advanced tone to it). RDP allows for separate virtual channels for carrying device communication and presentation data from the server, as well as encrypted client mouse and keyboard data. RDP uses its own video driver on the server-side to render display output by construction rendering information in network packets using the RDP protocol and sending them over the network to the client. On the client-side, it receives the rendering data and interprets them into the corresponding Win32 Graphic Display Interface (GDI) application programming interface (API) calls. On the input path, client mouse and keyboard messages are redirected from the client to the server. On the server-side, RDP uses its own virtual keyboard and mouse driver to receive these keyboard and mouse events.


Without encrypting the display protocol, it would be very easy to “sniff” the wire to discover the user’s passwords as they log on to the system. Allowing an administrator to log on using a non-encrypted protocol exposes the entire domain resources that are now vulnerable to hackers, especially if connecting over a public network without a VPN. It is both darn interesting and important to note


that protocols using “scrambling” to protect data are just as vulnerable to this


sort of attack as protocols that send data using clear text. The activity involved in sending and receiving data through the RDP stack is essentially the same as the seven-layer Open Standards Interconnection (OSI) model for the LANs on this planet. Data from an application or service to be transmitted is passed down through the protocol stacks, sectioned (sounds like a Ginsu knife commercial with slicing and dicing, eh?), directed to the channel (through MCS), encrypted, wrapped, framed, packaged onto the network protocol, and finally (really and truly) addressed and sent over the wire to the client. The returned data works the same way only in reverse, with the packet being stripped of its address, then unwrapped, decrypted, and so on (and on and on) until the data is presented to the application for use (Whew!). Key portions of the protocol stack modifications occur between the fourth and seventh layer, where the data is encrypted, wrapped and framed, directed to a channel and prioritized.


Lastly, every version of RDP uses RSA Security’s RC4 cipher, a stream cipher


designed to efficiently encrypt small amounts of varying data size. RC4 is designed for secure communications over networks and is also used in protocols such as SSL, which encrypts traffic to and from secure Web sites. By default, Windows XP Remote Desktop and Windows Server 2003 Remote Desktop and Terminal Services use high (128-bit) encryption to encrypt most data transmissions in both the client-to-server direction and the server-to-client direction.


BEST PRACTICE: Don’t forget the 128-bit encryption point raised here.


It is frequently brought up in technology conversations about SBS.