Mobile Tech Guy

First thing to do is edit the Group Policy Object: Run gpedit.msc (Figure A)

Figure A

Navigate to Computer Configuration | Administrative Templates | Windows Components | Terminal Services | Security (Figure B)

Figure B

Set the Encryption Level to High Level (Figure C)

Figure C

Set Require Secure RPC Communication to Enabled (Figure D)

Figure D

Set Require Use Of Specific Security Layer For Remote (RDP) Connections to SSL (TLS 1.0) (Figure E)

Figure E

Move to a different GPO section, Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options (Figure F)

Figure F

Enable FIPS mode (Figure G)

Figure G

Enable Remote Desktop from the System Properties Window (Figure H)

Figure H

Do a forced GPUpdate ( Figure I) to refresh the Group Policy

Figure I

Figure J shows a successful update.

Figure J

Secure RDP 6.0 client configuration

Launch the RDP client using the MSTSC command (Figure K).
Note: Windows 2003 and XP users must download and install RDP 6.0 clients, whereas Vista comes with the correct client.

Figure K

Enter the name of the server, noting that this initial process should happen on the LAN first. For this example, we’re going to an RDP host machine called “msi-p965,” (Figure L). This is not a fully qualified name, and it will work only on the same subnet LAN for now. It’s possible to enter a redirect entry into the local host file pointing to an IP or dynamic DNS address so that you can access “msi-p965″ or whatever you call your machine from the public Internet. However, we’ll leave that for a follow-up article. For now, we’re talking about just the immediate LAN.

Figure L

Expand out Options (Figure M)

Figure M

Set the display to your liking using the options (Figure N)

Figure N

Specify whether you want sound, printers, or the Clipboard to work on the Local Resources tab (Figure O)

Figure O

Specify any programs you want to launch upon connection on the Programs tab (Figure P)

Figure P

Specify how you want the remote desktop to look using the settings (Figure Q).

Figure Q

On the Advanced tab (Figure R), set the RDP client to warn you if the RDP server fails to prove its authenticity.

Figure R

Click Settings and configure the options (Figure S).

Figure S

Go back to the General tab and click Save As to save your entire profile. You can save it to the desktop for easy access.

Click Connect and enter username and password (Figure T)

Figure T

The first time you connect, you’ll see the authentication warning (Figure U) telling you that the server’s certificate is not trusted (yet). To force it to be trusted in the future, click the View Certificate button.

Figure U

As you can see in Figure V, this self-signed cert generated by the Vista RDP host machine is valid for the next six months. Click on the Install Certificate button to add it to the CTL (Certificate Trust List).

Figure V

The Certificate Import Wizard will launch (Figure W). Click Next to proceed.

Figure W

Choose Place All Certificates In The Following Store and click the Browse button (Figure X)

Figure X

Select Show Physical Stores and highlight Local Computer (Figure Y)

Figure Y

Back in the Certificate Store screen (Figure Z) click Next.

Figure Z

Click the Finish button (Figure AA)

Figure AA

Click OK.

Figure AB

At this point, you’ll be securely connected to the Vista RDP host, but more important, future connections to the remote machine won’t result in any warning signs or even password prompts. It will simply connect in a secure manner, and any warning signs must be viewed with a critical eye.

What happens when you try to connect to this host via IP address or a dynamic DNS entry from the public Internet? If you try to connect by any name other than the one you used to originally generate the certificate, you will see a warning like the one (Figure AC). You can tell it to connect anyway and choose Don’t Prompt Me Again For Connections To This Computer.

Figure AC

You’ll then get another warning (Figure AD), that tells you there’s a name mismatch and that the server name on the certificate is incorrect. This isn’t a bad thing. You can view the certificate and it will say it’s for your machine and that it’s trusted. You’re just seeing this warning because the RDP client is comparing the name on the certificate with the name of the computer you’re connecting to. For this example, I was trying to connect to “192.168.1.2″ and not the remote machine name, so the computer warned me that they didn’t match. Since I intended to connect to that IP address or some other publicly resolvable DNS name on the public Internet, and since the certificate was valid, I knew I wasn’t being deceived. So I was comfortable clicking Yes to connect anyway.

Figure AD

But what if a hacker poses as your server with a made-up certificate? In that case, you’ll see the warning (Figure AE) telling you that not only does the name not match, the certificate isn’t even from a trusted certifying authority. If you see this kind of error when you’ve already gone through the certificate installation procedure from Figure U to Figure AB, you know someone is trying to dupe you. You should click No and not connect to the server. If you attempt to make the connection anyway, you’ll reveal enough of your credentials for the hacker to quickly run a dictionary attack to find your password.

Figure AE

If this seems like a rather complex process just to get no warning signs for an RDP connection, it is–but it’s the only practical way to establish a secure and trusted connection. Fortunately, you have to do it only once, and all subsequent connections are secure and hassle free. Believe it or not, you’ve essentially created your own PKI certificate on the RDP host and installed a Certificate Authority on the client computer. This level of security using a Public Key Exchange is used to secure e-commerce transactions. On an enterprise level, this entire procedure with GPO settings and digital certificates can actually be automated on both the server and the client side using Active Directory Group Policies, but now you know how it all works.

In a future article, I’ll show you how to set up a free dynamic DNS entry that’s publicly resolvable and that points to your home dynamic IP broadband service. When everything is secure, we’ll trick the client machine into not generating any more warning messages at all.

Reference: http://articles.techrepublic.com.com/5100-10878_11-6166676.html