Windows Remote Desktop (RDP)
Windows Remote Desktop allows to remotely get a Windows session on a Windows XP/2000/2003 machine on which it is enabled from any machine running the RDP client: the RDP client asks the name of the machine and the user and password and then the client opens a window showing the desktop of the server machine.
- Comparison between UltraVNC, Windows Remote Desktop and Citrix ICA connection
- How to enable Windows Remote Desktop in Windows XP SP2
- How to connect to a Windows Remote Desktop from Windows 98
- How to secure RDP
UltraVNC), after years using Citrix Metaframe (now called Presentation Server) through ICA client connections at work, and after using sometimes Windows Remote Desktop I think I can tell these are the main differences between the three solutions:
- Responsiveness: UltraVNC is fast, a lot faster than TightVNC, and it's totally usable over a 54 Mbps 802.11g WLAN; RDP is a lot faster, especially when showing large or numerous images in a web page: pressing PageDown to scroll a page displaying a 800x500 image with UltraVNC it takes nearly one second before the scroll is replicated to the client, while with RDP or ICA the scroll occurs with no detectable delay, assuming the client has decent performance ; thanks to a low performance terminal I can witness that ICA connections are faster than RDP connections.
- Image definition: Some colours with RDP may be altered, even using 24 bits as colour depth instead of the standard 16 bits, while I never noticed this problem neither with UltraVNC nor with ICA. Sometimes it occurs a colour alteration using UltraVNC but it's a temporary problem that lasts for a few seconds: when the display is refreshed the true colours come back.
- Video and sound: While UltraVNC is unable to replicate audio and video to the client, RDP and ICA can do it. I have no experience with ICA, but with RDP I experienced some sort of delay response to Winamp command, just like some sort of need for buffering.
- Alt-tab, Start key and other keyboard commands: I have never been able to use them with UltraVNC, so I got the habit of moving through applications clicking on the taskbar. At work I used a Wyse terminal connected through ICA to a Citrix Metaframe server and all the keys are exactly the same as if I was on the console: Start key opens the Start menu, Alt+Tab works regularly, etc, while opening an ICA connection inside another ICA connection or from a PC session there are different key combinations that don't overwrite the main session keys. In RDP these are the more useful key combinations:
Alt + Tab <---> Alt + PageUp Shift + Alt + Tab <---> Alt + PageDown Start key <---> Alt + Home Ctrl + Alt + Canc <---> Ctrl + Alt + Del Alt + Spacebar <---> Alt + DelThe shortcut keys are not overwritten, too. For instance, if I define a Ctrl+W shortcut for a program both on the server and on the client, pressing Ctrl+W the client program would be opened.
Other interesting key shortcuts here.
- Copy and paste between server and client: Impossible with UltraVNC, it works through RDP and ICA
- Connecting printers and disks: With RDP and ICA the client disks and printers can be connected to the server and accessed from there
- Control Panel | System | Remote: check Allow users to connect remotely to this computer
- Run services.msc | Terminal Services: start, if not already started (it can be started automatically or manually - obviously the latter is safer)
- Allow only some users, better not administrators, to access to the machine through RDP.
Creating a new user for this purpose and allowing only to him to connect remotely could add up some security if he has a long and strong password. Then:
Control Panel | System | Remote | Select Remote Desktop Users
If there is a "<user> has access" note, the next step should take care of it.
Control Panel | Administrative Tools | Local Security Policy | User Rights Assignment | Allow logon through Terminal Services
Remove all the groups and add the only users that should be allowed to use RDP.
- Lockout the account after an x number of failed logon attempts (this should defend from brute force attacks):
Control Panel | Administrative Tools | Local Security Policy | Account Lockout Policy
While lockout duration and lockout threshold are self explanatory, "Reset account lockout counter after x minutes" means how much time must pass since the first failed attempt before resetting the lockout counter: for instance, with a 30' lockout duration, a threshold of 5 and reset lockout counter after 8 hours, after the fifth failed logon the account is locked for 30 minutes but the user cannot logon before 8 hours since the last failed logon; in other terms, the user can mistype his password 5 times every 8 hours. Setting 0 as lockout duration means the account must be unlocked by the administrator, and after that with the counter still at 5 the account will be locked at the first failed logon.
To unlock the account, go to Control Panel | Administrative Tools | Computer Management | Local Users and Groups
- Encrypt RDP: run gpedit.msc and go to Computer Configuration | Administrative Templates | Terminal Services | Encryption and Security
- Change RDP port: run regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, then change the PortNumber from 3389 to something else
- Enable remote connections only when necessary
- If the client cannot connect whilst ping works and everything is set up, maybe in Network Connections there is a connection called Internet Gateway; in that case, either enable rdp connections from outside checking rdp in its properties, or uninstall it (in Control Panel, Add or Remove Programs, Add/Remove Windows Components, Networking Services, Details, uncheck Internet Gateway Device Discovery and Control Client)
- If the client and the server are on the same LAN and the client cannot connect to the server local IP (i.e. 192.168.x.x) but it can connect to the server public IP, and the client is using OpenDNS DNS's, try using your provider DNS's: it seems it's a matter of DNS priority over NetBIOS matched with OpenDNS not returning NXDOMAIN.
 I experienced slow response with a low performance Wyse linux terminal at work, especially with a web application that was making a lot of refresh.