Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Hands-On NAQC
Walk step-by-step through a NAQC implementation for XP SP2 VPN clients
Orin Thomas
December 17, 2006
14 Min Read
In his article “Setting Up Network Access QuarantineControl” (InstantDoc ID 44950), Mark Burnett discussesthe basics of setting up a methodof verifying a computer’s configuration before allowing it accessto an internal network through aWindows Server 2003 ServicePack 1 (SP1)/Release 2 (R2)RRAS server. To follow up thatarticle, I thought I’d provide ahands-on tutorial for implementing Network Access Quarantine Control (NAQC) forWindows XP SP2 VPN clients.My aim is to give you a strictlyMicrosoft-based solution thatdoesn’t require you to go out andseek third-party products. In theinterest of simplicity, I addressonly a PPTP VPN solution usingMS-CHAP v2 authentication,but you could use other methods, such as L2TP tunneling andsmart card or digital certificateauthentication.
What Is NAQC?
NAQC is a method of checkinga remote-access client’s configuration prior to letting it contacthosts on a protected network.Checks that run against a clientcan include verification thatvirus definitions are current,that a screensaver password isconfigured, and that the XP firewall is active. This article uses a check of installed hotfixes as thegatekeeper criteria. It’s possibleto add more checks to the gate-keeper criteria, but doing so ismore complicated. This implementation of NAQC works asfollows:
The XP SP2 VPN client, using PPTP, connects to the RRAS server, and authentication occurs.
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.
The client downloads an administrator-generated list of required updates from a protected server accessible through the quarantine filters.
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 andconfigure NAQC to allow aquarantined client to gainaccess to the hotfixes that needto be installed. Later, I providesuggestions 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 RRASserver that will function as a BorderServer, and an XP SP2 client. Table 1 shows the configured network interfaces. I’ve used the 10.0.0.0network to simulate the public IPaddress space; in a real deployment,the XP client and the RRAS externalinterface would have public IPaddresses. Traffic won’t pass from theXP client to the DC unless the client isreleased from quarantine.
The Windows 2003 DC requires nospecial configuration other than thecreation of test users and groups. Forthe purposes of this article, the testuser is named VPNTest and the group is named VPNUsers. I added the testuser to the test group, and I configured the account properties to ensurethat the Dial-in tab’s Remote AccessPermission (Dial-in or VPN) checkbox would be set to Allow access, asFigure 1 shows.
So that authentication for the VPNconnections can occur, the computerthat will function as the RRAS servermust be a member of the DC’s domain.To configure RRAS on the memberserver, perform the following steps:
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.
From the Administrative Tools menu, open the Routing and Remote Access console.
Right-click the name of the server, and click Configure and Enable Routing and Remote Access to start the Routing and Remote Access Wizard.
On the Configuration screen, leave the default settings—Remote access (dial-up or VPN)—and click Next.
On the Remote Access page, ensure that the VPN check box is selected and click Next.
On the VPN Connection page, select the network interface that faces the Internet and click Next.
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.
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.
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.)
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 themember server, you should install theRemote Access Quarantine Serviceand the Connection Manager Administration Kit (CMAK). To install thesecomponents, follow these steps:
In Control Panel, open Add or Remove Programs and navigate to Add/Remove Windows Components.
Under Management and Monitoring Tools, select Connection Manager Administration Kit.
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, setthe startup status of the RemoteAccess Quarantine Service to automatic, then use the Services tool fromthe Administrative Tools menu to startthe 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:
From the Administrative Tools menu, open Routing and Remote Access.
Right-click Remote Access Policies, and select New Remote Access Policy to start the New Remote Access Policy wizard.
Enter the policy name VPN Quarantine Policy, and click Next.
On the Access Method page, select VPN. Click Next.
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.
On the Authentication Methods page, ensure that only MS-CHAP v2 is selected. Click Next.
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:
Right-click the new policy, and click Properties.
Click Edit Profile, go to the Advanced tab, and click Add.
Scroll down to the MS-Quarantine-Session-Timeout attribute, and click Add.
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.
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 _MACHINESYSTEMCurrentCon trolSetServicesrqsAllowedSet 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 %3uses 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
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.
On the RRAS server (with CMAK installed), in Administrative Tools, click Connection Manager Administration Kit to start the CMAK wizard. Click Next.
On the Service Profile Selection page, select New Profile, then click Next.
On the Service and File Names dialog box, enter the service name VPNTest and the filename VPNTest. Click Next.
Select Do not add a realm name to the user name, and click Next.
On the Merging Profile Information page, click Next.
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.
On the VPN Entries page, click Next.
On the Phone Book page, clear the Automatically download phone book updates check box. Click Next.
On the Dial-Up Networking Entries page, click Next.
On the Routing Table Update page, click Next.
On the Automatic Proxy Configuration page, click Next.
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 connectionsEnsure 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.
On the Logon Bitmap page, click Next.
On the Phone Book Bitmap page, click Next.
On the Icons page, click Next.
On the Notification Area Menu Shortcut page, click Next.
On the Help File page, click Next.
On the Support Information page, click Next.
On the Connection Manager Software page, click Next.
On the License Agreement page, click Next.
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 FilesCmakSupport folder on the RRAS server that has CMAK installed. Click Next.
On the Ready to Build the Service Profile page, click Next.
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 windowstracing 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.
About the Author
You May Also Like
.png?width=700&auto=webp&quality=80&disable=upscale)