In a recent post, I described a high-level overview of 802.1x authentication. Now, let’s dive a bit deeper into the use of 802.1x as a foundation for Network Access Protection (NAP) enforcement of health policies in a Windows Server 2008 network infrastructure.
Recall that 802.1x can be used with Ethernet switches and Wireless Access Points (WAPs) that support the feature, with the purpose of authenticating the devices connected to them (e.g., servers, workstations, tablets, phones, etc.). Generically, we could refer to Ethernet switches, wireless APs (i.e., 802.11), VPN servers, and dial-in servers as Network Access Points (NAPs) or Network Access Servers (NASs). Yet, because Microsoft uses the term NAP for their access protection mechanism, which we will discuss shortly, let’s use the term “NAS” when referring to an Ethernet switch, WAP, VPN server, or dial-up host.
Whether the NAS supports 802.1x or some other authentication scheme, it can be configured to relay such authentication using the RADIUS protocol. There are actually RADIUS authentication and accounting protocols! Thus, each NAS could be configured as a RADIUS client, whereas a Windows Server running Microsoft’s Network Policy Services (NPS) performs the role of RADIUS server. Several NPS servers could be used for redundancy and load distribution. Additionally, in larger environments, NPS servers could act as RADIUS proxy servers as a front-end from regional NAS points of presence to more centralized NPS RADIUS servers.
Network Connection Policies can be checked on the NPS servers to determine if the end-station client devices ought to be allowed on the network via the NAS to which they are connecting. Thus, centralized, policy-based access control of Ethernet, wireless, VPN, and dial-in clients is supported by proper integration of these elements. But, what we just described was somewhat supported in Windows Server 2000 and, with a couple of name changes, in Windows Server 2003.
Now we have an established foundation that Network Access Protection (NAP) can build upon. Beyond mere authentication checks to determine whether to allow a client on the network, NAP’s advantage is its support of health policies. With respect to health policies, NAP offers an elaborate, extensible framework that computer vendors, like HP or Dell, and security vendors such as Symantec or McAfee (Intel) could leverage to provide NAP system health agents (SHAs) and system health validators (SHVs).
Included with NAP is one, default Microsoft Security Health Validator (WSHV), which runs via the NPS on Windows Server 2008 or 2008 R2, and one, default Microsoft Windows Security Health Agent (WSHA), which runs in NAP clients on systems such as Windows XP ≥SP2, Vista, and Windows 7. This built-in SHV/SHA pair can be configured to check if the clients’ firewall is enabled, antivirus is enabled, antivirus is up-to-date, antispyware is enabled, and antispyware is up-to-date. It can also check to see if critical (or other level) of updates have been applied (i.e., from WSUS).
Microsoft also offers a System Center Configuration Manager SHA (SCCM SHA) and a ForeFront Client Security SHA (FCS SHA). Other vendors such as Avenda Systems, Computer Associates, McAfee, and Symantec offer their own extensions including SHA/SHV pairs that can extend NAP health-checking capabilities beyond the built-in WSHA/WSHV pair. For example, the Avenda Windows Universal System Health Validator can scan for specific registry values that you configure. You can configure this validator to check for particular registry values that must be present, and if they are not, the Avenda Universal SHV will command the corresponding Universal SHA to create or update the proper registry values you have indicated.
Additionally, this Universal SHV can confirm that another list of registry values are not present (” must be absent,” for example) and request the Universal SHA to delete such keys from the offending client if they are present. In other words, third-party, Microsoft (second-party), and your own, custom (first-party) extensions to NAP can offer remediation to enforce particular client configuration as a part of authorizing such client machines to be allowed on the network–or not.
One of the great benefits of the Windows Server 2008 R2 version of NAP, beyond the first version in Windows Server 2008, is that multiple configurations of a SHV can be configured as a part of the health policies. It’s not super exciting that W2K8R2’s NAP supports having different update criticality requirements for hot fixes of different sets of machines with the WSHV. But it can be very exciting if differentiated SHV configuration allows you to specify different sets of registry parameters or updates that must be a part of the compliance specification of sets of machines with unique security and compatibility requirements.