RD Gateway using NPS and NAP (Network Access Protection)

As you might know the Remote Desktop Gateway (RDGW), which is one of the components of Remote Desktop Services, uses two kinds of policies. Connection Authorization Policies (CAP’s) hold the configuration of who can access resources behind the RDGW. The Resource Authorization Policies (RAP’s) consist of the information of what resources (i.e. servers of farms) can be accessed by users that have an entry in the CAP.In a standard configuration a RDGW uses a local store for its CAP which is based on Network Protection System (NPS) and the configuration of the CAP is done by using the RDGW Manager.

In this scenario I wanted to test a Remote Desktop Gateway (RDGW) using a central server running NPS. Why would I want to do this? Most obviously because this way I could create a second RDGW server that would use the same central NPS server for its CAP’s with which I would be able to create a form of High Availability (HA) for my RDGW. But besides this reason, using a central server running NPS I am able to make use of Network Access Protection. With a combination of RDGW and NAP I would be able to set restrictions on the workstations before letting them be able to connect. In other words I can set rules that clients have to be compliant with before I let them through my RDGW. Why is this interesting? When using managed clients (i.e. clients that are members of your domain) you can, of course, create all kinds of policies to enable firewall, virus scanning etc. But what about those non-managed clients? The term bring your own device (BYOD) is becoming more and more popular. A good evolution because why would you still want to manage client machines if all they access is some kind of cloud service (in the broadest sense of the word, a RemoteApp that runs behind your RDGW)? Using RDGW and NAP together you can define a compliance policy so that you can enforce that only clients that are compliant may connect. These compliance policies can include i.e.

·         The Windows firewall must be enabled

·         Ant-virus application must be running

·         Anti-virus must be up to date

·         Anti-spyware must be running

·         Windows updates must be enabled

·         Windows updates must be up to date

How does this work? Without going into detail, the client reports a statement of health (SoH) to the RDGW. Based on this SoH the RDGW checks the CAP’s that are stored on NPS server. If the client is compliant it will let it through, if not an error is raised to the client that it is not compliant including the actual reason why.

So let’s take a look at the scenario in this lab. I have set up the following machines:

-          Windows Server 2008 R2 with RD Gateway role

-          Windows Server 2008 R2 with RD Session Host role

-          Windows 7 client machine

-          And of course a Domain Controller (also Windows Server 2008 R2)

Our goal: Set an environment in which the Windows 7 client can only connect to the RDSH via the RDGW when the Windows Firewall is running on the Windows 7 client. And, on top of that, perform an auto-remediation on the client by automatically enabling the Windows Firewall if it’s not running and inform the client that he’s now compliant. Sounds like a lot of work, but it will turn out to be surprisingly easy!

We are assuming that the RDSH server already has the RDSession Host role and that a group is created and configured to be allowed to connect to the RDSH server using RDP. (Preferable using a GPO).

We also assume that the RDGateway server already had the RD Gateway role installed without any CAP’s or RAP’s defined during the setup and that we selected local NPS storage during the setup.

After issuing a SSL certificate for our RD Gateway server to our local CA and selecting it on the SSL certificate tab on the properties of the RDGateway, we’re ready to configure the NPS and RDGW.

We start by creating a new RAP in the RD Gateway Manager.

Remember to only create the RAP, not the CAP. We enter the name “RDS RAP”, enter the security group that holds the user we want to allow to connect and use the RDSH server as the Network Resource to be allowed to connect to.

On the RDGW properties in the RDGW manager on the RD CAP Store tab we make sure that “Request clients to send a statement of health” is checked. Remember that we do this to have the clients send their SoH to the RDGW.

We now open up the Network Policy Server (can be found in the admin tools section of the start menu of the RDGW server). You can of course, have the NPS server running on a different machine, but for the sake of the demo we have it running locally on the RD Gateway server.

Right click the RADIUS Server Groups and click new.

Enter a name and add the central NPS server by clicking Add and use the FQDN of the NPS server. Enter a shared secret, and note it down.

Now right-click the Connection Request Policies and choose new

Enter a name and choose Remote Desktop Gateway as the type
Add the NAS Port Type and select Virtual (VPN).

Click next and select “Forward request to the following remote RADIUS server groups for authentication” and make sure that the group you created earlier is selected.

Open the properties of the Default Configuration in the settings of the Windows Security Health Validator

For this demo we’re only going to check the Windows Firewall, so make sure that this is the only one that is selected here

Now move all the way to the top, select NPS(local) and click Configure NAP

On the first screen select RD Gateway and leave the default name
Next add the RD Gateway server by using its FQDN, and enter the same shared secret as used earlier.
Leave the default redirection settings and timeout settings in place
Now add the user group that you used earlier (the one that you want to allow to connect)
Make sure the Windows Security Health Validator is select and hit next and finish

We now have the basic configuration running. We have created three network policies:

 And two health policies:

Let’s make sure that auto-remediation is turned on. Remember we run this auto-remediation when a client is not compliant, so the setting is in the properties of the NAP RD Gateway Noncompliant on the settings tab:

That’s it for the configuration on the server side. To have a fully operational client with NAP auto-remediation capabilities we need to configure the client. We can quickly do this by running Tsgqecclientconfig.cmd which can be downloaded here:

http://www.microsoft.com/downloads/en/details.aspx?familyid=cb986639-20e5-4f16-8e48-be68d23dc888&displaylang=en

Ok, we’re done! Let’s do some testing!

We open up our Windows 7 machine and make sure all Windows Firewalls are disabled on it:

We create a .rdp file that has the correct RDSH server as the destination and the correct RD Gateway server configured and hit connect.

The first error we get is:

Which is good, because we are in fact not compliant with the policy!

Now comes the good part, a balloon of the NAP client pops up, when we click it we get the following dialog:

Which again tells us that we’re not compliant, but on top of that it also tells us why, The Windows Firewall is not running. AND: it’s attempting to fix this as mean of remediation!

We hit close. The NAP dialog gets updates as shown below:

We try to connect again: no errors and we’re allowed to connect!
Why? Because the auto-remediation did it’s work and automatically enabled our Windows Firewall again and made our client compliant again:

And these are just the basics! The combination of the RD Gateway and NPS(with NAP) generates lots of possible scenarios and is very flexible! Especially the fact that you can also create your own System Health Validator (SHV) or make combinations! And I haven’t even talked about Remediation servers that you can add to your environment as well.

For now, these are the basics, hope it was useful! I might do a new blog on this and take this NAP configuration a little further by extending it with a custom SHV and doing some NAP troubleshooting as well!

Additional info:
http://technet.microsoft.com/en-us/network/bb545879
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8e47649e-962c-42f8-9e6f-21c5ccdcf490&displaylang=en
http://technet.microsoft.com/en-us/library/dd560672(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc742822.aspx