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


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.

Who’s NAPping on Your Network? – 802.1x as a NAP Foundation


How do you really know that the computers on your network are valid and legitimate? The flip-side of the coin asks how do those machines know that they’re connected to the proper network? Those are both good questions that we often look at in the course “Configuring and Troubleshooting Windows Server 2008 Network Infrastructure,” but have addressed in many other security courses as well over the past several years.

For many years, since the days of Windows XP and Windows Server 2003, Microsoft has included support for the network authentication mechanism 802.1x in recent versions of Windows. This built on the Remote Authentication Dial-In User Service (RADIUS) and Remote Access Policies which have been built in to Windows since Windows 2000 Server. Use of 802.1x in wired (e.g. Ethernet) and wireless (e.g. 802.11 WiFi) networks requires some prerequisites in your network infrastructure. With Windows Server 2003 Service Pack 1 (SP1), Microsoft added a virtual private networking (VPN) quarantine feature. Windows Server 2008 included a renaming and repackaging of many of these features, along with some more powerful enhancements built around this framework, namely Network Access Protection (NAP). Windows XP SP2 and later, Windows Vista, and Windows 7, as well as the server versions can be NAP clients. Windows Server 2008 R2 adds the ability to have a greater mix of distinctive NAP policies for checking system health without adding as many NAP servers into your infrastructure.

Security and networking can have a great synergistic relationship. Both are essential as lifeblood in today’s computer environments, like the white blood cells (security) and red blood cells (networking) help keep our bodies alive. The complexity of deploying 802.1x, or a more ambitious use of NAP depends on the size and diversity of your networks, however we can look at the building blocks in an elementary way. We will start with simple concepts and build up to the reality of such deployments.

Imagine that you have a user whose workstation is connected to your organization’s network via Ethernet. The workstation has an Ethernet interface, typically connected via appropriate cabling into a port on an Ethernet switch. This could be a legitimate workstation within your organization, or a rogue uninvited visitor. How can the Ethernet switch decide whether to allow this workstation on the network or not? This is where the use of classic point-to-point protocol (PPP) dial-up mechanisms meet local area networking (LAN) technologies, or in this case, Ethernet specifically. If the operating system on the workstation and the firmware in the Ethernet switch both support the industry standard 802.1x, the workstation can prove its identity or the identity of one of its users (i.e. authenticate) to the Ethernet switch by using what were originally PPP-based authentication protocols such as the extensible authentication protocol (EAP). Without getting into the details of EAP, let’s assume that the workstation proves its identity to the Ethernet switch, without getting into many of the details.

How does the Ethernet switch check and confirm the credentials, and decide to allow that workstation on the network? The Ethernet switch does not possess a local hard-disk-based nor FLASH-based database of computer accounts nor user accounts. Therefore the Ethernet switch asks another machine on the network if this computer should be allowed on the network. Rather than have the Ethernet switch speak either the Kerberos authentication protocol or the Lightweight Directory Access Protocol (LDAP), the switch uses another industry standard called RADIUS which originated in dial-up networks around 1991, and was first submitted for standardization circa 1992. Microsoft started using providing a RADIUS server implementation as their Internet Authentication Service (IAS) in Windows 2000 Server. This service was still called IAS in Windows Server 2003, and repackaged into the Network Policy Service (NPS) in Windows Server 2008 (and 2008 R2).

Imagine that you have implemented a NPS server in your environment. You could configure the Ethernet switch as a RADIUS client to speak to the NPS server. But the problem of authenticating the workstation is usually deferred again, as the NPS server may not have user accounts locally resident. Instead, the NPS (RADIUS) server translates or at least reencapsulates the authentication request to an Active Directory Domain Services (AD DS) domain controller. Hopefully the domain controllers have a valid computer account for the workstation in question.

In summary, the 802.1x authentication functions like a game of hot potato. The workstation authenticates using EAP over Ethernet as a part of the 802.1x scheme. The Ethernet switch conveys this authentication request over the RADIUS protocol to the NPS server, and the NPS server requests confirmation from AD DS that there is a valid computer account that is allowed to connect to the network. Policies on the NPS server can also allow or limit the ability for a machine to connect, and this is the foundation for the bigger NAP service with 802.1x enforcement. If the domain controller suggests to accept the workstations connection, and the NPS server agrees, then the Ethernet switch will receive confirmation and if successful, allow this workstation on the network, perhaps with packet filters, virtual LAN assignment, and the upper-layer address negotiation such as via DHCP.

NAP can use several different enforcement techniques, including 802.1x as one of the options. We shall revisit this topic with a focus on NAP itself shortly.

DirectAccess – a VPN but not a VPN (“to VPN or not to VPN”)

Windows NT 4.0 included an implementation of the Point to Point Tunneling Protocol (PPTP) for both the NT4 Workstation and NT4 Server products, with a client for Windows 95 OSR2, and PPTP is still supported in Windows and other operating systems. Virtual Private Networking (VPN) technologies have evolved since then. In fact, could they have perhaps evolved so much that they don’t exist any more?

While one of the great synergistic cofeatures of using Windows 7 in a Windows Server 2008 R2 network infrastructure is DirectAccess, which Microsoft claims is not a VPN technology, these operating systems still support PPTP, as well as VPN cousins L2TP (as of Windows 2000) and SSTP (as of Vista SP1 and Windows Server 2008). Just how does DirectAccess compare to those other technologies, and how can it be useful as an alternative to those older VPN technology choices?

Why does Microsoft claim that DirectAccess is not a VPN technology? To understand this, let us first look at what some of the other VPN technologies are, then the similarities and differences between these and DirectAccess, and the distinction should become clear.

Many hardware and software vendors offer VPN implementations, yet from a Microsoft perspective, the PPTP, L2TP, and SSTP VPN solutions in Microsoft Windows are coupled with Routing and Remote Access Services (RRAS) on the server side, and dial-up networking (DUN) on the client side. The way most people use these VPN technologies in Windows, the end-user on the client machine either explicitly “dials” into the VPN server after they have logged on, or perhaps as a part of the logon process. The first real distinction between these technologies and DirectAccess is that this supposedly non-VPN DirectAccess technology is always on. In other words, DirectAccess clients connect into their DirectAccess server as soon as the client machine starts up and the underlying physical network connection(s) become available.

The ramifications of this, and if we merely focus on the benefits of this for a moment, are significant with respect to applying Active Directory Domain Services (AD DS) based Group Policies to such client machines, applying updates via Windows Update Automatic Updates (WUAU) and Windows Server Update Services (WSUS), and ability to perform other forms of remote administration of these client systems at any time. We do not have to wait for a user to log on and dial into the VPN in order to have centralized management ability and control over the constituent systems. To Microsoft, perhaps this is construed as a key distinction which casts DirectAccess as a non-VPN technology, however from my humble perspective, as it has always been possible to have a startup script dial into a VPN connection using particular user credentials, I’m not 100% clear why they would consider that a distinction other than a variation from the average end-user expectation of how VPNs are typically used. To me it doesn’t make DirectAccess a non-VPN technology, but that’s just my opinion.

Let’s look a bit deeper at DirectAccess to better understand what it is and is not. To quote Microsoft TechNet “DirectAccess, introduced in the Windows® 7 and WIndows Server® 2008 R2 operating systems, allows remote users to securely access enterprise shares, web sites, and applications without connecting to a virtual private network (VPN).” <http://technet.microsoft.com/en-us/network/dd420463.aspx> More specifically, the DirectAccess client is a feature of the Windows 7 Ultimate and Enterprise editions. Like PPTP, L2TP, and SSTP, DirectAccess also uses tunneling to carry Internet Protocol (IP) traffic encapsulated in the Point to Point Protocol (PPP), however the further tunneling details of these four technologies (PPTP, L2TP, SSTP, DirectAccess) are what makes them unique. There are two aspects to the tunneling distinctions, namely (a) tunnel negotiation, establishment, teardown, and administration, as well as (b) tunnel encapsulation and security for the content – the network traffic carried in IP/PPP across the tunnel.

One of the critical components of DirectAccess is the use of the Internet Protocol version six (IPv6) as the internetworking protocol carried by the tunnel, as well as in two of the three options for how DirectAccess implements the tunnel itself. Two IPv6 to IPv4 interoperability and coexistence technologies which can be used with DirectAccess are 6to4 and Teredo. With 6to4 tunneling, IPv4 traffic is tunneled over IPv4 networks such as the public Internet and private IPv4 networks. However, 6to4 tunneling does not work particularly well with IPv4 network address translation (NAT), luckily we have one of the other IPv6 interoperability technologies, Teredo, as another choice for DirectAccess tunnel foundations. Teredo, named after the “shipworm” mollusk that is known for boring holes into wooden ship hulls, is designed to provide IPv6 over IPv4 tunneling like 6to4, but with the advantage of boring through routers which do NAT. The third choice for the IPv6 over IPv4 tunneling of DirectAccess is use of IP-HTTPS, which utilizes the Hypertext Transfer Protocol (HTTP) over the Secure Sockets Layer or the standardized Transport Layer Security (SSL/TLS), and like regular https for web site access, uses TCP port 443 for the server side of the connection. Whether 6to4, Teredo, or IP-HTTPS is used for DirectAccess, the datagrams tunneled within such conduits is IPv6.

Like any typical VPN server, the DirectAccess server needs to have a publicly addressable network interface (the public or untrusted side) and a separate internal network interface (the private or trusted side). Again, the DirectAccess Server implementation is in Windows Server 2008 R2. An additional requirement which Microsoft specifies that is not universal to all VPN technologies is that the public side of the DirectAccess server have two consecutive public IPv4 addresses configured and accessible. Like many L2TP implementations which use IPsec with public/private key pair authentication, and SSTP which uses SSL/TLS with public/private key pair authentication, so too does DirectAccess require a public key infrastructure (PKI). The baseline requirement is merely to have public key certificates issued to the computers involved (client and server). A variation on the public key certificate for the computer is to issue a smart card which is used in the client. If Network Access Protection (NAP) is also required in your environment, then the public key certificates issued to the computer would be health certificates issued from your NAP authority.

Another Microsoft-specific requirement which is hopefully not too much of a surprise now that Active Directory is over ten years old, is that at least one AD DS domain controller and DNS server running on Windows Server 2008 SP2 or Windows Server 2008 R2 is required in the internal network on the trusted side of the DirectAccess server.

Although, like with many new technologies, there are requirements specific to DirectAccess that are not needed for other VPN technologies, establishing a DirectAccess Server based on Windows Server 2008 R2, the necessary infrastructure, and as many DirectAccess clients as you need, running Windows 7 Ultimate or Enterprise, is a fairly straightforward endeavor. The benefits are many for this always on VPN technology, primarily the ability to support always manageable systems in remote offices, home offices, and in mobile Windows 7 machines the field. DirectAccess allows private, controlled access, over tunneled virtual network interfaces of Windows 7 machines which need to be connected into their main office whenever they have public Internet access available. To VPN or not VPN, is not really a relevant question anymore. What’s in a name? Beside the fact that you might be used to dialing up your VPN connection after you log on, whereas DirectAccess is always on, does it really matter whether you call it a VPN technology or not?