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.

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.