How network access quarantine works
NAQC prevents unhindered, free access to a network from a remote location until after the destination computer has verified that the remote computer's configuration meets certain requirements and standards as outlined in a script.
To use NAQC, your remote-access computers must be running any of the following: Windows 98 Second Edition, Windows Millennium Edition, Windows 2000, or Windows XP Home or Professional. These versions of Windows support a connectoid that contains the connection information, the baseline script and a notifier component, which you can create using the Connection Manager Administration Kit (CMAK) in Server 2003. Additionally, you'll need at least one back-end Windows Server 2003 machine that's running an approved listening component; for the purpose of this chapter, I'll assume you're running the Remote Access Quarantine Agent service (called RQS.EXE) from the Windows Server 2003 Resource Kit. Finally, you'll need an NAQC-compliant RADIUS server, such as the Internet Authentication Service in Server 2003, so that you can restrict network access.
Under NAQC, when a connection is established, the destination computers give the remote, connecting computer an IP address, but a "quarantine mode" is established.
In quarantine mode, the following restrictions are in effect:
- A set of packet filters is enabled that restricts the traffic sent to and received from a remote-access client.
- A session timer is enabled that limits the duration of a remote client's connection in quarantine mode before being terminated.
Once the remote computer is in quarantine mode, the baseline script is run. If Windows runs the script and is satisfied with the result, it contacts the listening service running on the Server 2003 back-end machine and reports this result. Quarantine mode is then removed and normal network access is restored. Otherwise, the client is eventually disconnected when the session timer reaches the configured limit as described previously.
A step-by-step overview of Network Access Quarantine Control
Here is a detailed outline of how the connection and quarantining process works, assuming you're using RQC.EXE on the client end from the CMAK and RQS.EXE on the back end from the Resource Kit.
1. The remote user connects his computer, using the quarantined Connection Manager (CM) profile, to the quarantine-enabled connection point, which is usually a machine running the Routing and Remote Access Service (RRAS).
2. The remote user authenticates.
3. RRAS sends a RADIUS Access-Request message to the RADIUS server -- in this case, a Server 2003 machine running the Internet Authentication Service (IAS).
4. The IAS server verifies the remote user's credentials successfully and checks its remote-access policies. The connection attempt matches the configured quarantine policy.
5. The connection is accepted, but with quarantine restrictions in place. The IAS server sends a RADIUS Access-Accept message, including the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout attributes, to RRAS.
6. The remote user completes the remote-access connection with the RRAS server, which includes leasing an IP address and establishing other network settings.
7. RRAS configures the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout settings for the connection, now in quarantine mode. At this point, the remote user can only send traffic that matches the quarantine filters -- all other traffic is filtered. It can only remain connected for the value, in seconds, of the MS-Quarantine-Session-Timeout attribute before the quarantine baseline script must be run and the result reported back to RRAS.
8. The CMAK profile runs the quarantine script, currently defined as the "postconnect action."
9. The quarantine script runs and verifies that the remote-access client computer's configuration meets a baseline. If so, the script runs RQC.EXE with its command-line parameters, including a text string representing the version of the quarantine script being used.
10. RQC.EXE sends a notification to RRAS, indicating that the script ended successfully.
11. The notification is received by RQS.EXE on the back end.
12. The listener component on the RRAS server verifies the script version string in the notification message with those configured in the Registry of the RRAS, and returns a message indicating that the script version was either valid or invalid.
13. If the script version was acceptable, RQS.EXE calls the MprAdminConnectionRemoveQuarantine() API, which indicates to RRAS that it's time to remove the MS-Quarantine-IPFilter and MSQuarantine-Session-Timeout settings from the connection and reconfigure the session for normal network access.
14. Once this is done, the remote user has normal access to the resources on the network.
15. RQS.EXE creates an event describing the quarantined connection in the system event log.
Click for the next excerpt in this series: Six steps for deploying Network Access Quarantine Control
This was first published in November 2004