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.
Oh my god it's over! I mean . . . success!
The picture above is simply showing you my externally-facing firewall configuration. I'm only allowing two ports in - port 80 going to my web server, over which you are right now reading this webpage, and port 443, which is being directed to the new RD Gateway server. See? No port 3389 allowed through at all. Are you getting excited yet? I hope so. I spent a lot of damn time making all these screenshots.
So I was thinking about certificates. You know . . . strategizin'. When it comes to certificates, when the hostname of the server who is making a claim about its identity doesn't match the name with which the prospective client addressed them, well, that's pretty much the number one error when it comes to certificates. So with this in mind, I went ahead and added a host record to my public DNS. prarlrdgw01.arl. That way when an Internet user attempts to address my RD Gateway server, they can do so by the name of prarlrdgw01.arl.myotherpcisacloud.com. And my RD Gateway server will agree that that is indeed its name. Hostname = prarlrdgw01. Subdomain = arl. Parent domain = myotherpcisacloud.com.
Alright so let's switch gears now! Your RD Gateway server is pretty much done! Now we move on to your client configuration. To connect to an RD Gateway server, your workstation needs to be using RD Client 7.0 or greater. Which is like saying you need to be running Windows 7 or 2008 R2 or greater. So in the picture above, here I am on my PC out on the Internet, far away from my internal network. I'm configuring my client to get ready to connect to my RD Gateway back home. Start up the client by doing a Start -> Run... "mstsc". Then hit the options dropdown and go to the advanced tab. Then hit that "Connect from Anywhere" Settings button. (Pictured above.)
Alright, now that I've configured my RD Gateway settings, I'm going to try to connect to the internal host PRARLPC01! Never mind the fact that I cannot resolve the name PRARLPC01 from the Internet! Throw caution to the wind! I'm so excited!
ARGH!!1 It didn't work! All that preparation, for naught! Alright, let's compose ourselves. I don't see any way around that message. I told the RDC client to ignore authentication errors and connect anyway, but it doesn't matter. I don't care that "it's not safe!" Let me connect anyway! Meh . . . maybe it's for the best that it won't let me connect anyway without proper authentication. Let's go ahead and view the certificate with which we were presented when we tried to connect. It's got the correct hostname on it from the perspective of both the client and the server, but see how it was both issued to and issued by the same server? That's a self-signed certificate. And it's worth a whole-lotta-nothin'. If you closely read the description of the certificate message pictured above, you will notice that it says it doesn't trust the CA Root. The Certificate Authority is the entity that issued the certificate. Well . . . my RD Gateway server is no sort of authority on anything, but I know of someone who is. . .
So this little speed-bump gives me time to go ahead and make use of something I already had handy - An Enterprise Root CA. Now keep in mind that the next couple of steps are not completely necessary - I'm just doing it to exercise my already existing ECA. It might still be possible to still proceed with a self-signed cert. To skip this part, just scroll down until you see the big !!! An Enterprise CA is a server role; it is integrated with Active Directory and its purpose is to provide your "Enterprise" with certs, be it certs for smart-card login, or certs for EFS encryption, or certs for Network Device Enrollment, or certs for a formerly useless RD Gateway server. So what I'm doing in the picture above is, from my RD Gateway server, open up an MMC, and add the Certificates snap-in. Specify that you want to see Computer certificates for the local computer. Then right click on the Personal certificate store, and Request a New Certificate . . .
Now since you already have a properly configured Enterprise CA (uhmmm. . . that's for a future tutorial I guess,) you will now get the dialog box pictured above. This is the sign that you as a client have properly detected your domain's Certificate Authority and the enrollment policies that it has to offer you. So go with the flow. . .
And here, pictured above, it's simply telling you that yes, because of the aforementioned awesomeness in the way you have set up your domain, that you are indeed eligible to enroll for your very own Computer certificate, courtesy of your friendly neighborhood Enterprise Certificate Authority!
Now on your RD Gateway server, check out your Personal Certificate Store, via the Certificates MMC snap-in. (Pictured above.) See how you now show two certificates? That first one is your crummy old good for nothing self-signed certificate that you made earlier. The next one as you can see was issued by your ECA, and should allow every client in your domain to implicitly trust you! Implicit trust is a hard thing to come by, both in life and in Remote Desktop Services.