Network Access Control (NAC) is a hot topic these days. NAC’s primary purpose is to ensure that a client has passed a health check or integrity validation before allowing it access to the corporate network. It is not a security solution per se, but rather a system to prevent potentially unsafe computers from connecting to the network.
A NAC broker/trust agent/supplicant is required to run inside each PC or laptop. In the absence of such an agent, the user can be placed on the quarantine VLAN until the problem is remedied and the user switched to the unrestricted VLAN. The latter is also sometimes called the protected VLAN.
This is a great idea. I’ve been inside paranoid Enterprises that prohibited me from attaching to their internal network. One allowed it only after technicians could boot and inspect my laptop, ensuring that I had the correct OS, patches, an up-to-date anti-virus, and so on. I passed the inspection but I still could have disabled or changed things afterwards.
NAC can also be combined with authentication, requiring user credentials on top of a clean and updated machine. NAC agents are smart in that any attempt to disable an antivirus after booting results in the user going back to the quarantine VLAN for remediation.
To complicate things there are three competing NAC implementations: Microsoft Network Access Protocol (NAP), Cisco CNAC (Cisco NAC), and TCG-TNC (Trusted Computing Group-Trusted Network Connect, an open standard) using a variety of protocols including HTTPS and EAP tunneling. Currently NAP is native only to Vista and Longhorn which begs the question, “Was Microsoft caught napping?” :-)
Worse, all use different nomenclature. Regardless of terminology, all implementations basically have the NAC agent at the client (or requestor), a server (often in conjunction with RADIUS) to handle policy/posture validation, and an enforcer to grant or deny access. The enforcer (or network enforcement point) can be a layer 2 switch that handles VLAN assignments on a port-by-port basis for each client or a firewall that allows/disallows VPN access.
Common to all three schemes is the NAC agent at the client who must perform a DHCP renew as the last step in the process. An example is to obtain an IP address that will work properly on the assigned VLAN. Typically a DHCP server will be dual-homed to receive requests from both the good and bad VLANs which, of course, are on different subnets.
Typically the NAC agent will request an IP address as if the PC was just booted. In the event that the previously used address is requested and a DHCP NACK is received due to a user’s switch port assigned to a new VLAN/subnet, a new address must be requested. These NACKs are a good thing to monitor since they are a good indicator that a client was on a Quarantine VLAN either past or present.
Sound complicated? Unravel the mystery by visiting the iLabs pavilion next month (September 19-21) at Interop in New York City and play with all of the various NAC authentication schemes and clients, not to mention look at the various NAC protocols using OmniPeek. OmniPeek is the official analyzer for iLabs and is set to capture all traffic on the NAC backbone, including all Cisco, Microsoft, and TCG traffic. It will also be monitoring and graphing occurrences of DHCP NACKs.
Prior to deployment in New York, a colleague and I worked with the good folks at the iLabs hot staging facility using OmniPeek to troubleshoot a problem with Windows Vista and NAP. The problem occurred when operating over 802.11 wireless – the client did not force a DHCP renew if NAP found a problem and thus the client was switched to the quarantine VLAN.
A previously good IP address on the wrong subnet (i.e. VLAN) does you no good if you need to get updated. One solution is to set the address lease at the DHCP server time to a very short period, say 20 seconds forcing the client to frequently renew– generally not a best practice! Meanwhile, the information is being taken back to Microsoft. Hopefully we’ll see the fix by the time Vista is officially released.