User:Mjb/Setting up Remote Desktop
It's easy to set up Remote Desktop so that you can control your Windows computer from another computer.
The server is called Remote Desktop Services, or (prior to XP), Terminal Services. Other names for it include Remote Desktop Server and RDP Server. RDP stands for Remote Desktop Protocol.
|These OSes cannot accept incoming Remote Desktop connections:
||These OSes can accept incoming Remote Desktop connections, if it is enabled:
Windows 7 Home Premium can accept incoming Remote Desktop connections as a side effect of applying an unofficial patch to modify Remote Desktop functionality, but there will be no GUI for configuring the service; configuration has to be done through the registry. The unofficial patch, which I have not tried, is called Concurrent RDP Patcher. It has two main features: 1. It can make it so that if someone is already logged on via Remote Desktop, a second incoming Remote Desktop connection can bump them off (normally the second connection isn't allowed); and 2. It can allow Remote Desktop login with a blank password, which sounds like a really dumb idea.
The client is called Remote Desktop Connection (RDC), or (prior to XP), Microsoft Terminal Services Client. Most people call it Remote Desktop Client.
Most versions of Windows (95 and newer, except Windows Phone) either come with a client, or one can be downloaded from Microsoft. An official client is available for Mac OS X as well.
Client features vary by version and by the server version being connected to. Newer servers can be configured to require Network Level Authentication, which locks out older clients.
Basic server setup
- Go to Remote Settings (it's in the System Properties, e.g. right-click on My Computer and go to Properties).
- Choose one of the "Allow connections..." settings for Remote Desktop. If you choose Network Level Authentication, it will probably lock out non-Win7 clients (see below).
- Click Apply or OK.
That's all you need to get it going. Try logging in from a Remote Desktop client elsewhere.
Client setup and certificate madness
It's all pretty straightforward, except for certificates. The client may warn you that the server's certificate is not from a trusted certifying authority.
You could choose to ignore the error, and check the box saying not to remind you again, but that's the "I give up" route that most people take.
You really should only get the prompt when the cert has changed, every however-many days, a number configured who-knows-where. The server takes care of generating its own self-signed cert when needed. You also have the option of making them yourself (expiring as far into the future as you want), signing them with your own CA, and pushing them out to all your machines. This is what Windows LAN administrators sometimes do, but it seems like an awful lot of work to me, so I just rely on the automatically generated self-signed certs.
There's no way to know for sure that the cert you're being asked about is authentic, which is why you're being asked about it. The question you have to answer is "do you trust who this cert was signed by?"—not just "do you trust the machine the cert represents?"
If the answer to both questions is "yes", then you should go ahead and accept the cert. To avoid being prompted about it every time, you're supposed to be able to follow the prompts to view and then install the certificate in your OS's certificate store.
Unfortunately, it doesn't give you the option of putting it in the right place! The current user has one set of stores, and the system has another set; the wizard only lets you put things in the current user's stores, whereas Remote Desktop Connection looks in the system's stores.
So, install it into the wrong place (the current user's store) with the wizard. Then you can move it via the management console.
Starting from the warning dialog in Remote Desktop Connection, on Windows 7, this is the procedure:
- Click "View certificate...".
- Click "Install Certificate..." (this starts the Certificate Import Wizard).
- Click "Next".
- Select "Place all certificates in the following store".
- Click "Browse...", choose "Trusted Root Certification Authorities", and click "OK".
- Click "Next" and "Finish". At this point, it may tell you that it cannot validate that the certificate is actually from the remote computer it claims to be from, and that you should confirm by checking its SHA1 thumbprint with the one on the remote computer. This is important! On the remote computer, run regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\Remote Desktop\Certificates. Only install the certificate if you see a registry key whose name is the same as the thumbprint, without spaces. The wizard should tell you the import was successful.
- Click "OK" and "OK" so you are back to the warning dialog.
- Click "No" to get rid of the dialog.
- Run mmc.
- Add a snap-in (Ctrl+M): select "Certificates", click "Add", select "My user account", click "Next".
- Add another snap-in: select "Certificates" again, click "Add", select "Computer account", click "Next" and "Finish".
- Click "OK".
- Go into "Certificates - Current User" and find the certificate under "Trusted Root Certification Authorities" > "Certificates".
- Cut (Ctrl+X) or Copy (Ctrl+C) the cert.
- Go back to the "Console Root" and find the same location in "Certifiactes (Local Computer)"
- Paste (Ctrl+V) the cert. If you cut instead of copied, then you'll also be asked to confirm the deletion from the current user's store.
Now try connecting again. You should no longer get the prompt, at least not until the certificate expires. If the certificate expires, the remote system will generate and send a new cert, and you will have to do this all over again.
(Import procedure gleaned from Ronald Blaschke's very helpful post on ServerFault.)
Require Network Level Authentication
In the Remote Settings configuration, you choose whether only allow connections from computers running Remote Desktop with Network Level Authentication, which is a feature of Remote Desktop Client 6.0 and up. It generally means that the client must be running on Windows 7 and up. However, Microsoft makes updated clients available for Vista and XP, so you can still connect from those OSes as long as you use the updated client. To get Network Level Authentication working in the client on XP, you have to enable the CredSSP service.
After applying the April 2013 update KB2813347 (Remote Desktop cleint update for vulnerability MS13-029), I could no longer connect a client from Windows 7 Starter to a server on Windows 7 Professional without reconfiguring the server to not require Network Level Authentication. I had installed the update on both systems. I haven't yet investigated further.
Change the listening port
For extra security, I suggest changing the listening port. Details are in a Microsoft Knowledge Base article, but basically you just run Regedit, go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber and enter the port number. The change will take effect after the next reboot. Don't forget to create a custom rule in Windows Firewall to allow TCP traffic inbound on that port. You can disable all the other Remote Desktop rules; they are for the default port. Of course, you will need to make sure that you include the port number after the computer hostname in the client's logon settings, like the.remote.host:12345.
Temporarily prevent login after too many failed attempts
I also suggest setting an account lockout threshold in the Local Group Policy Editor > Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy. When you enter a threshold, it will suggest 30 minutes for the other values; this is good. This will make brute-force attacks difficult. I set mine to 5, which should be enough retries for a real person who just can't remember or is fat-fingering their password.
Login session management
When you end or get disconnected during a remote desktop session, things can get crazy.
- You might be logged out immediately, and all your processes terminate, including the ones that were already running when you logged in, causing you to lose unsaved work.
- You might remain logged in, and some or all of your processes might run for a while, but then you get logged out after some time has passed.
- Some processes keep running, but are now using credentials from a disconnected session, causing "login failures" as they try to reconnect to resources they no longer have access to, and this results in account lockout.
- Other combinations of the above.
I have not yet figured out a reliable way to ensure that processes keep running without also risking account lockout. There are settings you can change that affect this, but everything I've tried just does not work reliably.
What I want is tolerance for flaky connections... give me ~5 minutes to reconnect and don't log me out or do anything crazy in the meantime... let me pick up where I left off, regardless of whether I am seated at my computer or connecting via RDP. Suggestions appreciated! Email me at root at skew dot org.