Tales from the Office Vol. 1

You know your department is trying to use up its funding before the end of the fiscal year when you start seeing things like deliveries of 70-inch monitors.

I got an email concerning a company KB article I wrote which contained the phrase: "Also, the Status of “Kickin’ rad” is not acceptable, please put a more acceptable status in there..."

I was just making sure somebody actually read those things...

Finally, McAfee sucks.

Remote Desktop Services Tutorial #2 (RD Web Access)

For the first installment in this series, see RDS Tutorial #1 (RD Gateway).

Now that we've set up an RDS Gateway, let's try to add RD Web Access into the mix. RD Web Access is a pretty cool little role service of RDS that puts up a secured website that authorized users can access. From this website, the user can launch remote desktop sessions, and even better - RemoteApp programs. With RemoteApp programs, you can either launch applications from the RDS server by clicking on their icons on the RD Web Access website, or if you use Windows 7 or better, you can actually add them to your local Start Menu and launch them as though they were located on your own PC! It's pretty sweet. For this tutorial, I'm going to attempt to add the RD Web Access role service to the same server that is currently running my RD Gateway. Were this an enterprise environment, I probably wouldn't do that. For performance and scalability reasons, I'd probably break out the roles to different servers. But this is just a lab and a proof-of-concept. Let's start by going to Server Manager on our existing RD Gateway server and adding the RD Web Access role service:

It will ask to install some IIS dependencies just like it did with RD Gateway. Just take the defaults; there shouldn't be any problems with conflicts.

Alright so let's look at the settings we've chosen above. It's telling us that our new RD Web Access website will be at https://servername/RDWeb. So for me, if you wanted to access my RD Web site from the Internet, its address would be https://prarlrdgw01.arl.myotherpcisacloud.com/RDWeb. Note that you will still have a "default" website in the / directory. It will have the generic "Welcome to IIS" logo that us IIS users are so familiar with. You might consider adding an automatic redirect that goes to the RDWeb directory from the default site, unless you plan on using the default directory/site for something else. Also notice that the website's SSL certificate will already be trusted if you access it from the same workstation and if you've already followed my RD Gateway tutorial. (And you address it by the FQDN in your browser.) See where it mentions WSRM? Windows System Resource Manager. It's a nifty little tool that, in my opinion, is best used on servers that will have a lot of clients connected to them simultaneously. That's because with WSRM you can do things like create system rules that will enforce policies like an equal distribution of CPU power and/or memory to all the connected clients. That way one doofus won't have the power to adversely effect the experience of everyone else connected to your remote desktop server. But for now it's outside the scope of this tutorial. We'll cover it later.

Alright so that's pretty much all there is to installing the RD Web Access role service. The only thing of note in the above screenshot is that it's warning us that additional configuration is needed. That's because we haven't configured any RemoteApps for publication yet. It will continue warning you about this until you do. We'll get to that in a bit. So now you have an RD Web Access site running on the same server as your RD Gateway! Below is a screenshot showing you where to find the files if you want to personalize your own RD Web site. You'll at least want to add your company's logo and name.


So here I'm just specifying the name of the computer that will host the RemoteApp programs. You can also modify this setting in the web.config files. Since I'm putting all the role services on the same server, I'm pointing to myself. There's one other setting you can configure: The default port on which RemoteApps will be published. You can change this in the IIS console, or in the web.config for the site:

The interesting thing about this is that I believe this port only matters to internal clients. However, since we're using an RD Gateway, we don't have to open that port on our externally-facing firewall. We're already running an RD Gateway and the RD Web Access website on the same server and on port 443. And now we're about to be able to transport RemoteApps through 443 as well! That's pretty freaking amazing if you ask me. How many different services can you squeeze out of one port? Alright, so now we have one final problem. And that is that we don't have the required role service installed to host RemoteApp programs! That role service is RD Session Host. I'm just going to go and add it to this same server. Like I said before, I'd distribute the load more in an actual production scenario, but this is a lab so what the hell. If you do install RD Session Host on a separate server, be sure to specify it on the configuration page on RD Web Access, as was shown earlier.

Pictured above is just me adding the RD Session Host role service. It's asking me if I want to enforce NLA. I like security. And I like enforcing. The next step will ask you about CALs. Client Access Licenses. This is that part where I was telling you about how you can only have two users logged in to a device "administratively" at once, but you can have bunches of users simultaneously connected to a proper RDS server. The downside is that you have to pay for that. At least you get to choose how you wanna pay. Per device or per user. I would go with per user, so that I can connect from any number of devices. However if you have several users that share the same workstations (like shift workers in an office) from which they connect to the RD session host, it might make more sense for you to do it per device. If you choose "configure later," it will at least let you try it out for a few months before it stops working.

The next step asks about which AD groups I want to allow to connect again, just like it did for the RD Gateway. And again, I added the "RDS Users" group to that list. On the next step, pictured above, we configure which parts of the "Client Experience" we want to enable for our remote users. Each of these options will require more bandwidth and will demand more performance from your RD Session Host. And what the hell, why not... let's drive this poor VM into the ground! I'll probably be the only person connecting anyway. Except for that kid in China that finally hacks in. After the installation is complete, you'll need to restart, and it'll take a couple minutes extra to reboot as there is a lot of new configuring being done. Your server is now a full Remote Desktop Server. The important thing to remember is that from here on out you need to put that server in "RDS install mode" to install applications, unless the installation is a modern .msi package. You can research and find out exactly what it does, but basically it's an old mechanism that just ensures that the application is installed in such a way that is friendly to being used by multiple users. You now also have a RemoteApp Manager added to your Server Manager console. Now let's go and try to publish some RemoteApp programs. . .

The first thing I noticed was that it wanted to use a certificate for RemoteApp programs. So I gave it one. The same one that I was already using for the RD Gateway, and was issued by my enterprise CA.

Next I'm going to specify that the client should connect using my RD Gateway, bypassing the gateway when internal. Perfect. This part is crucial if you want to be able to access RemoteApp programs from the Internet, as remember you can't get through on ports 3389 or 5504 from the Internet. Next I'm going to go to the local Users and Groups. Notice the two new local groups at the bottom, TS Web Access Admins and TS Web Access Computers. Domain Administrators are administrators by default, whether they are in that TS Web Access Admins group or not. Now even though the other group says "computers," I went ahead and put my custom RDS Users group in there anyway.

Finally we're ready to add a RemoteApp program. In your RemoteApp Manager, just right-click and add a RemoteApp program. I don't have anything interesting installed, so I guess we'll just add Powershell just to test if it works. At this point, you're ready to connect to your fully-functional RD Web Access website from the Internet!

There's your RemoteApp program! Also notice down in your taskbar, an interesting little icon popped up that you only see when accessing RemoteApp. It's a part of the Windows 7 system that allows you to add programs to your Start Menu as if they were local, but are in fact running over that connection through our RD Gateway. Clicking on the Powershell icon will prompt you if you're sure you want to run this program over a remote connection. Make sure that it correctly specifies both a remote computer name and a gateway server name, which in my case are one and the same. It will then attempt to connect, and you might get prompted for credentials to the RD Gateway server. One oddity that I noticed was that I got my default domain policy greeting message like you would get when normally logging on to any domain server, but it was in an odd resolution, and I had to click OK. My first thought is that it would be easy to wiggle around that with some group policy work, but it doesn't bother me that badly.

Alright so your remote application launched! Check it out! It looks and feels like it's running on your own local workstation. Notice down in your taskbar that the application's icon has a little "remote" symbol on it. The neat thing I tried to convey with the Powershell command I typed in is that it is retrieving information about the remote system, not your local system. And all of this is taking place over an SSL tunnel on port 443. Alright, so that's all I have for today. Feel free to contact me if you have any feedback or to tell me that something I did could have been done better. 'Till next time!

Remote Desktop Services Tutorial #1 (RD Gateway)

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.