Who’s NAPping on Your Network? – Network Access Protection (NAP)

object001

In a recent article, we 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) which support that feature, with the purpose of authenticating the devices (e.g. servers, workstations, tablets, phones, etc.) which are connected to them. Generically, we could refer to Ethernet switches, wireless (i.e. 802.11) APs, 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’ll discuss shortly, we’ll 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 optionally 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 that was somewhat supported in Windows 2000 Server, and as described above (with a couple of name changes) in Windows Server 2003.

Now we have a clear 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 which computer vendors such as 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 on the NPS on Windows Server 2008 or 2008 R2, and one default Microsoft Windows Security Health Agent (WSHA) that 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 enable, antispyware is up-to-date, and 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 which 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 (i.e. must be absent), 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 check and 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. While it’s minorly exciting that W2K8R2’s NAP supports having different update criticality requirements for hot fixes for different sets of machines with the WSHV, it can be majorly exciting if differentiated SHV configuration allows you to specify different sets of registry parameters or different sets of specific updates which must be a part of the compliance specification of sets of machines with unique security and compatibility requirements.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.