Downloads
94360.zip

In his article “Setting Up Network Access Quarantine Control” (InstantDoc ID 44950), Mark Burnett discusses the basics of setting up a method of verifying a computer’s configuration before allowing it access to an internal network through a Windows Server 2003 Service Pack 1 (SP1)/Release 2 (R2) RRAS server. To follow up that article, I thought I’d provide a hands-on tutorial for implementing Network Access Quarantine Control (NAQC) for Windows XP SP2 VPN clients. My aim is to give you a strictly Microsoft-based solution that doesn’t require you to go out and seek third-party products. In the interest of simplicity, I address only a PPTP VPN solution using MS-CHAP v2 authentication, but you could use other methods, such as L2TP tunneling and smart card or digital certificate authentication.

What Is NAQC?
NAQC is a method of checking a remote-access client’s configuration prior to letting it contact hosts on a protected network. Checks that run against a client can include verification that virus definitions are current, that a screensaver password is configured, and that the XP firewall is active. This article uses a check of installed hotfixes as the gatekeeper criteria. It’s possible to add more checks to the gate-keeper criteria, but doing so is more complicated. This implementation of NAQC works as follows:

  1. The XP SP2 VPN client, using PPTP, connects to the RRAS server, and authentication occurs.
  2. The client is placed in quarantine. Quarantine is a set of IP- and protocol-based filters placed on client traffic. These filters can be placed on specific protocols and ports or can permit traffic on an address basis.
  3. The client downloads an administrator-generated list of required updates from a protected server accessible through the quarantine filters.
  4. The client runs a script against this list to determine whether all updates are installed. If all updates are installed, the client is granted access to the protected network. If updates are missing, the client’s connection times out in quarantine.

It’s possible to go further and configure NAQC to allow a quarantined client to gain access to the hotfixes that need to be installed. Later, I provide suggestions for how to do so.

Implementation Setup
This implementation uses three computers: a Windows 2003 SP1/ R2 domain controller (DC), a multi-homed Windows 2003 SP1/R2 RRAS server that will function as a Border Server, and an XP SP2 client. Table 1 shows the configured network interfaces. I’ve used the 10.0.0.0 network to simulate the public IP address space; in a real deployment, the XP client and the RRAS external interface would have public IP addresses. Traffic won’t pass from the XP client to the DC unless the client is released from quarantine.

The Windows 2003 DC requires no special configuration other than the creation of test users and groups. For the purposes of this article, the test user is named VPNTest and the group is named VPNUsers. I added the test user to the test group, and I configured the account properties to ensure that the Dial-in tab’s Remote Access Permission (Dial-in or VPN) check box would be set to Allow access, as Figure 1 shows.

So that authentication for the VPN connections can occur, the computer that will function as the RRAS server must be a member of the DC’s domain. To configure RRAS on the member server, perform the following steps:

  1. Log on to the member server with an account that is a member of the Domain Admins group. Doing so will simplify the process of authorizing the RRAS server after it’s configured.
  2. From the Administrative Tools menu, open the Routing and Remote Access console.
  3. Right-click the name of the server, and click Configure and Enable Routing and Remote Access to start the Routing and Remote Access Wizard.
  4. On the Configuration screen, leave the default settings—Remote access (dial-up or VPN)—and click Next.
  5. On the Remote Access page, ensure that the VPN check box is selected and click Next.
  6. On the VPN Connection page, select the network interface that faces the Internet and click Next.
  7. On the IP Address Assignment page, select From a specified range of addresses and click Next. You can use DHCP to assign IP addresses, but a specific range is suitable when testing.
  8. On the Address Range Assignment page, click New to add a range of IP addresses for remote-access clients. This range should be within a subnet on your protected network address range. Click Next.
  9. On the Managing Multiple Remote Access Servers page, click No, use Routing and Remote Access to authenticate connection requests and click Next. (You can set NAQC to work with RADIUS, but doing so would make for a slightly more complicated process.)
  10. Click Finish to close the wizard. You might receive a message about the relaying of DHCP messages. Because we’re not using DHCP, you can dismiss this message by clicking OK.

After you’ve installed RRAS on the member server, you should install the Remote Access Quarantine Service and the Connection Manager Administration Kit (CMAK). To install these components, follow these steps:

  1. In Control Panel, open Add or Remove Programs and navigate to Add/Remove Windows Components.
  2. Under Management and Monitoring Tools, select Connection Manager Administration Kit.
  3. Under Networking Services, select Remote Access Quarantine Service, as Figure 2 shows. (The Remote Access Quarantine Service is available in Windows 2003 SP1 and is included with R2.)

After you finish this installation, set the startup status of the Remote Access Quarantine Service to automatic, then use the Services tool from the Administrative Tools menu to start the service.

The next NAQC-configuration step is to create and modify a remote-access policy. To create the basic remote-access policy, follow these steps:

  1. From the Administrative Tools menu, open Routing and Remote Access.
  2. Right-click Remote Access Policies, and select New Remote Access Policy to start the New Remote Access Policy wizard.
  3. Enter the policy name VPN Quarantine Policy, and click Next.
  4. On the Access Method page, select VPN. Click Next.
  5. On the User or Group Access page, select Group, click Add, and enter VPNUsers (or the group you created earlier) in the dialog box. Close the dialog box, and click Next.
  6. On the Authentication Methods page, ensure that only MS-CHAP v2 is selected. Click Next.
  7. On the Policy Encryption Level page, ensure that only the Strongest encryption option is selected. Click Next, then click Finish to close the wizard.

After you create the policy, perform the following steps to enable the remote-access quarantine features:

  1. Right-click the new policy, and click Properties.
  2. Click Edit Profile, go to the Advanced tab, and click Add.
  3. Scroll down to the MS-Quarantine-Session-Timeout attribute, and click Add.
  4. Enter a value of 45 seconds. This value determines how long a client can wait to be accepted. If the client hasn’t been released from quarantine before 45 seconds pass, the system automatically disconnects the client from the RRAS server. The 45-second interval provides enough time to perform the initial scan and, if necessary, to force approved updates to be downloaded from Microsoft’s Windows Update servers. I cover this process in more detail a bit later.
  5. Select the MS-Quarantine-IPFilter attribute, and click Add. The configuration of this filter determines what traffic can be sent to and received from clients in quarantine. In this example, the filter allows all traffic to hosts on IP addresses 192.168.10.1 and 192.168.10.2. An administrator could install an FTP server to host the updates at this address. The client in quarantine would be able to access that FTP site to download the latest list of required hotfixes. You can, of course, create more restrictive filters, allowing clients in quarantine to communicate only with specific IP addresses through specific protocols (e.g., TCP, UDP) and specific ports.

Scripts and Hotfixes
To help administrators deploy NAQC, Microsoft has provided several sample scripts, one of which scans the registry to determine whether certain hotfixes in a list are installed on the local computer. To obtain this file, see “VPN Quarantine Sample Scripts for Verifying Client Health Configurations” (http://www.microsoft.com/down loads/details.aspx?FamilyID=a290f2e e-0b55-491e-bc4c-8161671b2462 &DisplayLang=en). The file that this article’s example requires is checkhot-fixes.vbs. After you obtain the file, edit it to change

dim sInstalledQFE(40),
  sReqdQFE(40)

to

dim sInstalledQFE(100),
  sReqdQFE(100)

Doing so will let the script deal with a larger number of hotfixes. Without this change, the script won’t function on an XP SP2 computer. Rather than use the included hotfixidlist.txt file, create your own file with the same name and enter the IDs KB911564, KB911565, and KB87 3339.

You’ll need to modify the file to include all required hotfixes prior to deployment and update it as new updates become available, but these three IDs will work as a test for an XP SP2 computer. A full list of approved hotfixes will be quite lengthy. (If you want to test whether the script holds noncompliant clients in quarantine, create a fictional Knowledge Base or Quickfix ID and add it to the list. When it’s downloaded to the client and the check runs, the client won’t be released from quarantine because the fictional hotfix isn’t present.)

You’ll need to create a core script to call the hotfix-check script and to appraise its results. The core script doesn’t need to be complex; in Listing 1, I provide one that works. Using your favorite text editor, create a file named hotquar.cmd and enter Listing 1’s code. This script performs the following:

  • Changes the directory in which the CMAK profile resides
  • Downloads the latest list of hot-fixes from an FTP server on the protected network
  • Calls Microsoft’s CheckHotFixes .vbs script to check whether the latest list of hotfixes is installed

The error codes from the execution of the script determine what happens next. ERRORLEVEL 1 or 2 indicates that not all the required hotfixes are installed; ERRORLEVEL 0 indicates that they are. If ERRORLEVEL 0 is found, the system calls the remote-access quarantine’s listener component, allowing the client out of quarantine. If ERRORLEVEL 1 or 2 is found, the system attempts a forced WSUS update. I explain the basics of this process at the end of the article.

Understanding RQC.exe
RCQ.exe is the client component of
the Remote Access Quarantine Service. RQS is the server component. Once you’ve enabled the Remote Access Quarantine Service, clients will be restricted to quarantine for the duration of time that you specify in the remote-access policy. Clients are permitted out of quarantine only if RCQ.exe forwards a certain string to the RQS listener on the RRAS server. This string is stored in the RRAS server’s registry, in the HKEY_LOCAL _MACHINE\SYSTEM\CurrentCon trolSet\Services\rqs\AllowedSet subkey. The default value is RASQuarantine ConfigPassed.

This string is passed to RCQ.exe from the Connection Manager Profile. You can enter multiple strings into the registry and hence have multiple Connection Manager Profiles and scripts. Each string is tied to a Connection Manager Profile, so to prevent users with obsolete profiles getting released from quarantine, you can remove obsolete strings from the registry. The line

CALL RCQ.EXE /CONN %2 /DOMAIN
  %4 /USER %5 /SIG %3

uses variables passed to it by the Connection Manager Profile. These variables are the connection name (%2), the domain name (%4), the username (%5) and the quarantine exit string (%3). Later in the article, I talk about configuring the Connection Manager Profile.

To release a client from quarantine, you need only provide the connection name and the exit string. The reason you should also use the other fields is so that you can work out which users aren’t being released from quarantine by viewing the RRAS server’s system log. If user and domain information isn’t provided, you’ll know that someone’s computer isn’t being released from quarantine—but not who that someone is.

FTP and Hotfix List Distribution
Because Microsoft releases new hot-fixes at least once per month, administrators will need to update the hotfix list and distribute it to clients. Listing 1’s script allows for this task by using a fixed set of FTP commands to retrieve the file HotFixIDList.txt from an FTP server accessible to the quarantined client. In this case, the FTP server is installed on the RRAS server’s internal interface. Limiting FTP to the protected network means that only clients on the protected network— and those in quarantine—can access the FTP server. The script line

CALL FTP A s:gethotfixlist.txt <br>192.168.10.1

uses a list of commands in the file gethotfixlist.txt. A typical gethofix-list.txt file will contain commands such as ascii, gethotfixidlist.txt, and bye. You might need to vary this list of commands if the hotfixidlist.txt file is located in a folder of the FTP server’s root directory.

Creating the Connection Manager Profile
Configuring the client requires setting up a Connection Manager Profile on the RRAS server, then installing that profile on the client.

  1. On the RRAS server (with CMAK installed), in Administrative Tools, click Connection Manager Administration Kit to start the CMAK wizard. Click Next.
  2. On the Service Profile Selection page, select New Profile, then click Next.
  3. On the Service and File Names dialog box, enter the service name VPNTest and the filename VPNTest. Click Next.
  4. Select Do not add a realm name to the user name, and click Next.
  5. On the Merging Profile Information page, click Next.
  6. On the VPN Support page, select the Phone book from this profile option. Select the Always use the same VPN server check box, and enter the IP address of the Border Server’s external interface. Click Next.
  7. On the VPN Entries page, click Next.
  8. On the Phone Book page, clear the Automatically download phone book updates check box. Click Next.
  9. On the Dial-Up Networking Entries page, click Next.
  10. On the Routing Table Update page, click Next.
  11. On the Automatic Proxy Configuration page, click Next.
  12. On the Custom Actions page, click New. In the New Custom Action dialog box, which Figure 3 shows, enter the following settings:
    • Description: QUARANTINE
    • Program to run: hotquar.cmd
    • Parameters: %ServiceDir% %Tunnel RasEntry% RASQuarantineConfig-Passed %Domain% %UserName%
    • Action type: Post-connect
    • Run this custom action for: All connections
  13. Ensure that the Include the custom action program with this service profile and Program interacts with the user check boxes are selected. Click OK, then click Next.
  14. On the Logon Bitmap page, click Next.
  15. On the Phone Book Bitmap page, click Next.
  16. On the Icons page, click Next.
  17. On the Notification Area Menu Shortcut page, click Next.
  18. On the Help File page, click Next.
  19. On the Support Information page, click Next.
  20. On the Connection Manager Software page, click Next.
  21. On the License Agreement page, click Next.
  22. On the Additional Files page, add the CheckHotFixes.vbs, get hotfixlist.txt, hotfixidlist.txt, hotquar.cmd, and rqc.exe files. You’ll find rqc.exe in the \Program Files\Cmak\Support folder on the RRAS server that has CMAK installed. Click Next.
  23. On the Ready to Build the Service Profile page, click Next.
  24. Click Finish.

The system distributes Connection Manager Profiles as self-installing executable files. After a profile is installed, the client will be able to use it to connect. After the user authenticates, the system will download an updated list of hotfixes to the client and use Check-Hotfixes.vbs to check the list. If the client passes the test, the system will release it from quarantine. Administrators update the list of hotfixes by editing the text file located in the appropriate FTP directory.

Debugging NAQC
If something doesn’t seem to be working properly, you can debug NAQC by enabling the rqc.log file on the client by using the command

netsh ras set tracing * enabled

After you enable this log, you should attempt to reestablish a VPN connection on the client and check the \windows\tracing directory for the rqc.log file. Checking this log file can help you debug quarantine problems on the client. To debug NAQC on the server, check the system event log for events from the RQS source.

Getting Clients Hotfixes
One way to make non-compliant clients compliant is to use a forced WSUS update. You can force WSUS updates by calling the command wuauclt.exe /detectnow (included in Listing 1). When you run this command, all updates on the WSUS server’s approved list are downloaded and installed.

Because clients are granted only a short time in quarantine, it makes little sense to download updates over the VPN connection. You can configure quarantined VPN clients to get their approved update list from the protected network, and you can configure the WSUS server to force the remote clients to download these updates from the Internet.

Longhorn NAP
Longhorn Server introduces Network Access Protection (NAP), a technology that appears similar to NAQC but that enforces system health requirements differently. NAP is policy-based rather than script-based and applies to all network connections—not just those mediated by a remote-access server. NAP will replace NAQC in the next version of Windows. It isn’t reliant on the deployment of scripts to clients, so Longhorn’s NAP is also likely to be simpler to implement than Windows 2003’s NAQC.

Remote Challenge
Remote-access clients have always challenged administrators. Although NAQC reduces the chance that an infected remote-access client will get access to a protected network, it won’t eliminate the possibility. At this stage, the technology is complicated to implement; most organizations won’t implement it until it becomes simpler.