Remote Desktop Services is the new name for Terminal Services. When you hear someone say "TS", they probably mean "Terminal Services," which is now known as "Remote Desktop Services." You might hear someone say, "RDP to that server!" or "TS to that server!" . . . the terms are interchangable. RDP stands for Remote Desktop Protocol. Even on the most recent versions of Windows, you can go to the Start Menu -> Run... and type "mstsc," which stands for Microsoft Terminal Services Client... but it's all the same thing as Remote Desktop Client or Remote Desktop Protocol Client. The catch is that you can only have two users logged in "administratively" at once, but you can have a whole mess of users connected simultaneously to a proper Terminal Server/Remote Desktop Server that has the proper licenses. Just remember that RDS is the new hotness.
Well today I'm going to show you about a very neat feature of Windows 2008 R2 known as the Remote Desktop Gateway role service of Remote Desktop Services, formerly known as Terminal Services. I'm not just talking about the same thing as the RD protocol on port 3389 that allows one computer to connect to another's remote desktop. RD Gateway is a service that allows an administrator to create a gateway to the Internet that will allow Internet users a portal to your "internal" computers over SSL on port 443!
The RD protocol by itself is pretty damn secure really, especially with the newest version with NLA (Network Level Authentication,) but maybe you work in a big corporate environment. Maybe the network administrators of that big corporate environment have a really hard time swallowing the idea of opening port 3389 to the Internet. "Alright, fine," you say. What if I only expose port 443 to the Internet? Secure Sockets Layer is PCI (Payment Card Industry) complant; it's good enough for financial institutions and almost anyone. It's secure enough that as far as we know, it's as hack-resistant as it gets.
When I open port 3389 here at myotherpcisacloud.com, (which is not open now that I have RDS to replace it,) I get anywhere up to thousands of logon failure audits a day - just kids all around the world that have nothing better to do than try to log in to my remote desktop with random usernames like "joe," "owner," and "administrator."
Keep trying, baby birds.
Alright, so let's start with building a new server. A Windows 2008 R2 SP1 virtual server in Hyper-V. Go ahead and get that puppy fully updated.
(Some of these images are click-to-enlarge. Some images have thumbnails while some do not.)
PRARLRDGW01. My naming scheme is thus: PR = Production. ARL = Arlington. RDGW01 = It's the first RD Gateway server. Be careful not to let your server names get too long. (15 characters is the max for NetBIOS, with the 16th character being an archaic "extension" character. Add cluster node notations, etc., and I've seen large corporations reach that limit and run into problems, believe it or not.) Notice that this is a separate server than my primary web server. Maybe you could configure it to be the same as your regular web server. But I like to maintain a segregation of roles with my servers. I like to have a server doing as few things as possible. Plus my web server is running on the Web Edition of Windows Server, to which I couldn't add the RDS role. :P
Yeah so go ahead and add the Remote Desktop Services role to your server. You'll notice that there are many different parts of RDS. But the part that we're interested in for this tutorial is the RD Gateway. It's the first piece of the puzzle you need to concentrate on if you want to open a portal for Internet users to connect to your internal infrastructure via the Internet. So add that, and at this point you'll notice that it requires some other bits and pieces be installed as dependencies. Most notably IIS. There's an interesting mechanism used by RD Gateway called RPC over HTTP, which is really where the magic happens.
Above it's asking us about those dependencies we need to install. IIS, Network Policy and Access Services, and some RSAT tools for the role we're about to install. And that RPC over HTTP Proxy thing. Whatever the hell that is! (Remote Procedure Call over HTTP. Remote Procedure Call is a network protocol that allows one machine to call for another remote machine to execute some code on its behest.) At this point during the installation, as pictured below, it's going to ask us about a certificate.
If you're doing this for a company's production environment, this is the point where you need to actually go and buy a certificate from a "trusted 3rd party" cert company like Verisign. Which is such a sham, by the way. $700 for a basic certificate? Brings a new meaning to 'buying someone's trust!' Or you could get one from your company's Certificate Authority. That should at least satisfy internal users. But you can also opt to just use a self-signed certificate, which is what I did for now. It's free, but it also results in certificate errors being seen by the end-user, because no one trusts someone who has no one to vouch for them but themselves. That's not acceptable if this deployment is for a company that needs to maintain a professional image. (I'm looking at you, companies with public websites that still don't use proper certs, and also companies that have intranet websites that give their employees certificate errors because they don't bother with an ECA...)
The picture above is simply the next step asking us if we want to create authorization policies now or later. Considering that RD Gateway is completely useless wihout those policies, I'm gonna' go ahead and say we create them now.
The first thing we need to do (pictured above) is decide which Active Directory groups are going to have access to this system. Administrators was in there by default. I decided that just for good measure I would go ahead and create a custom "RDS Users" group and put people in there that I wanted to have remote access through this RD Gateway.
Alright so those users that we just defined in the last step, those are going in to a policy called an "RD Connection Access Policy." Pretty self-explanatory, right? Now it's just asking us to name that policy. It's also important to note that here it's asking us if we want them to be able to connect with a password, with a smart card, or be able to connect with either. Smart cards are becoming increasingly common in corporate environments as security requirements tighten, hacking attempts increase, and people keep writing their passwords down on sticky-notes and sticking them on their monitors or putting them under their mousepads.
The next step is your RD RAP, or RD Resource Access Policy. Now that you've already defined who can connect with your RD CAP, define what they can connect to with your RD RAP. If you had an important test or exam coming up that had anything to do with this stuff, it'd do you well to remember that you need at least one RD CAP and RD RAP each before RD Gateway can really be used at all.
The next step will ask you what role services you'd like to install for your new Network Policy Server. What? You didn't mean to install the Network Policy Server? Well, surprise! It's required for RD Gateway. It's actually pretty cool if you give it a chance. You can do stuff like only allow people to connect to your network if they have the latest security patches installed, or if they have current antivirus enabled, or if they have their Windows Firewall enabled, or only allow certain people to connect to certain IP subnets, etc. But for now, let's just leave all the settings at their defaults.
The above screenshot is simply the next step in the installation. It's asking you to configure IIS. Remember, you need IIS for this. If you're reading this tutorial, just take the defaults.