Hey there. My name’s Ryan. Yes, I know this is not my blog, but Ninjuh
made the mistake gave me the honor of letting me contribute to his blog. He actually conducted a technical interview on me for my last job, and it was pretty clear from the onset that we were both really enthusiastic about technology and so became fast friends. And we’re also both passionate about carnitas and tomatillo sauce. But staying on track, this blog is about technology!
Remote Desktop Services is the new name for Terminal Services. When you hear “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 Services. The difference 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 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, 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-
proof-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 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. 😛
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. In my opinion 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 is IIS. There’s an interesting mechanism used by RD Gateway called RPC over HTTP, which is outside the scope of this article (which means I don’t fully understand it. . . But anyway, onward!)
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 big company, 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 satisfy internal users only. But you can also opt to just use a self-signed certificate, which is what I did. 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.)
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.
(This is one of those thumbnailed images I told you about. Damn, if only I could give them a border or something to make them easy to identify…)
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. Go ahead, try to ping it right now!
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 should still be possible to 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.
Now go to RD Gateway Manager on your RD Gateway, either by Administive Tools on your Start Menu or in Server Manager, and right click on your server and go to properties. (Pictured above.) What you want to do is import your new certificate – the one issued by your ECA – for use by your RD Gateway. Instead of the self-signed one.
!!! (If you skipped the ECA part, resume here.)
Our final problem is that even now that we have a certificate issued by our Enterprise CA and should therefore be implicitly trusted by all our fellow domain members. . . well, our Enterprise CA doesn’t mean jack out on the Internet. Internet users still won’t trust us. Myotherpcisacloud.com? Who the hell is that? Sounds like a scam to me. . .
So your last recourse is to, on the client from which you wish to connect to the RD Gateway, import the certificate of the issuer whom you want to trust – be it a self-signed cert, a CA-signed cert, or a third-party cert. . . into your workstation’s personal store. I suppose you could either see this as a hassle, or as an extra measure of security. But one way or the other, unless you’ve figured out some way to circumvent that RDC 7 requirement to trust the RD Gateway vis a vis certification. . . you’re going to need his certificate. You either need to import the self-signed certificate from the RD Gateway, or you need to import the certificate of the issuing CA, if the RD Gateway’s certificate was issued by a separate CA. If your RD Gateway was issued a certificate by another CA, and you import the certificate of the RD Gateway instead, the client connection attempt will let you know that “more information is needed before Windows can trust this computer.” Don’t ask me how I know.
The picture above is me exporting the certificate from my issuing CA. Go to Start -> Run… and type “mmc”. Add the Certificates Snap-In. Choose Computer account. Go to the Personal Certificate Store. Right click the one that was issued to and issued by your CA, and Export it. (My ECA is also a domain controller, so that’s why you see that other cert in there.)
Now you need to share this certificate with everyone that you want to be able to connect to your RD Gateway. You could do it manually by sharing a URL with the users that points to the certificate so that they could download it and import it themselves. You could assign it to all your users via Group Policy if this were some case of business-to-business federation. (AD Trust relationships are going out of fashion.) Or maybe you could come up with something else creative that I haven’t thought about yet. I’m thinking about providing a download link to
mine on my upcoming RD Web Access website. See, that’s the difference between self-signed certificates or your company’s Enterprise CA issued certificates, and “Trusted 3rd Party” certificates that you can buy online for hundreds of dollars. Those expensive 3rd party certificates from companies like Verisign are trusted automatically by almost everyone, whether they’re in your own domain or on the other side of the planet. . . and not in your domain.
So now you’re back on your client machine that is not on your internal network or in your domain. On this machine, you want to import the certificate of the issuing CA that issued the certificate to the RD Gateway server to which you want to connect. . .
You need to install this certificate in the “Trusted Root Certification Authorities” store. Don’t let Windows automatically select where to put it. There’s no telling where it will go. Best to specifiy it yourself.
I can’t really explain it any better than the above picture. From henceforth after installing this cert, you will trust any computer that was issued a cert by the issuing authority whose certificate you’re about to install. Also I figured I’d blur out that thumprint part. I don’t know if it matters or not. . . from what I understand, certificates are pretty difficult to forge. But blurring things out makes me feel more important.
And now, finally, here is the culmination of all this effort. Go back to your RDC client on your external machine and try to connect again. Remember to configure the RD Gateway settings in the advanced tab like we did before. . .
And magic! It dropped me right on to the desktop of one of my internal PCs, regardless of the fact that its name wasn’t even resolvable by my client! I am now on the remote desktop of PRARLPC01, via port 443 to my RD Gateway, which then turns around and contacts the internal machine with 3389. Port 443 is the only port exposed to the Internet, and my remote desktop connection is SSL encrypted. Pretty awesome, right?
That’s all I’ve got. Thanks for sticking it out through this really long tutorial. Hopefully it helps you. Next time, I think I’ll set up RD Web Access, so stay tuned!