Microsoft's implementation of Network Access Protection (MS-NAP) is a compliance tool; used as designed for Microsoft systems, it will allow access to networks based on status of established health requirements for network communication. The most important component is the service pack and hot fix level being up to a predetermined level enforcement to permit access to a network. MS-NAP is not designed to protect from malicious users, however. The MS-NAP implementation provides for select clients to be protected upon making their network connection. This article is the first of an exclusive TechRepublic series to showcase the MS-NAP implementation.
Why is Network Access Protection important?
The main benefit of NAP, generally speaking, is to prevent the introduction of clients of an obsolete level to the network. This can be based on service pack level, anti-virus configuration, or other criteria. In the case of mobile systems, NAP is especially important. Consider a notebook user who works out of their home and accesses the network via a VPN connection while out of the office; a NAP implementation would protect that computer from entering the network if it had not been able to access the management tools you may have in place on your network.
NAP is also important for home computers connected to your network. Allowing network access for systems that your organization does not provide and manage is generally considered poor practice, but it does happen occasionally. In this scenario, NAP would be incredibly important; without it, you cannot even ensure that an anti-virus package would be installed, much less service pack and hot fix currency.
NAP can also be used to manage the health of standard desktop systems (and other Windows Server 2008 servers) to determine if access to the network should be permitted. This could protect against risks that may be relevant if a system was offline for a long period of time, and then was powered on with vulnerability — effectively posing the same risk as the notebook system described in the scenario earlier.
Planning an MS-NAP implementation scenario
MS-NAP can be configured with Windows Server 2008 for the server side and Windows Vista, Windows Server 2008, and Windows XP with Service Pack 3 for the supported clients. Windows XP Service Pack 3 is not yet available, but will include the NAP client for Windows XP, which, at the time of this series, is in beta testing by Microsoft.
The landscape of the MS-NAP implementation has roles that enforce the policy, store the health policy, provide the current health state, and isolate out of compliance devices all based on the enforcement method(s) selected in your configuration. There also is an isolation zone, or remediation network, for devices that are out of compliance to correct their configuration before being allowed onto the enterprise network. Figure A shows a general schematic of the MS-NAP implementation with the different roles identified.
Microsoft server products have long been able to do network functions such as DNS, DHCP, routing, and WINS; MS-NAP does not change that offering. While enterprise IT may not adopt many core networking services usually provided by network hardware, the MS-NAP implementation uses Windows server roles for the authentication and administration of the health policies. MS-NAP uses traditional network hardware to perform the implementation; so, from a networking perspective, it isn't an entire Microsoft solution.
Taking a closer look at MS-NAP
The basic premise of MS-NAP is easy enough to understand, but how does it work? MS-NAP uses a complex set of server roles and communication patterns to execute the network protection. Here, we'll take a closer look at the traffic flow of MS-NAP. From the server side, the MS-NAP implementation includes the following components:
- Health Registry Authority (HRA): This Windows Server 2008 computer with IIS role receives the health certificates from a certificate authority system.
- NAP Health Policy Server (NPS): This Windows Server 2008 computer with the NPS service role performs the functions of validating the health state and containing the health requirement policies.
- Remediation Server: This computer has resources to which NAP clients that are out of policy can connect to resolve their condition. This may include updated antivirus definitions and software updates.
- Health Requirement Server: This role provides the current health state for the MS-NAP servers.
- NAP client: This client is a managed computer that is subject to the policy enforcement of the MS-NAP implementation (Windows XP SP3, Vista)
- VPN server: This role may be an existing system, but is the entry point from clients for an outside network (not limited to the Internet).
- Networking equipment: Switches or WAP (Wireless Access Points) devices that support IEEE 802.1X authentication.
- DHCP server: In the MS-NAP implementation, the DHCP server uses RADIUS to communicate to the NPS server with the health state of the NAP client. This is the key element of MS-NAP in that if the system is compliant, it will be provisioned unlimited access; whereas, if there is a deficiency, it will be directed to the remediation network to gain compliance.
Usage scenarios for MS-NAP
Now that we have a big-picture concept of the MS-NAP implementation, let's start to identify where it can be a benefit for common networks. Security is a priority for every organization and new implementations should be made security-focused from the concept phases. MS-NAP can prohibit authenticated users on unprotected systems from being introduced to the enterprise network. In the Windows space, one of the best tools we as IT professionals have to manage systems is the Active Directory (AD) domain.
Within AD, we can manage many elements of systems and branch out to other management packages, like Systems Management Server (SMS), push out anti-virus management, and manage Windows updates. The MS-NAP implementation can bridge a gap where your normal management strategies may not apply.
Consider a scenario where a vendor or other business partner may need to connect directly to a resource on your network. This vendor may connect on machines joined to another domain or management mechanism, and are thus outside of your control. Lastly, these systems may be members of a different Active Directory forest, so you have little recourse to correct any configuration issues once the systems connect to your enterprise network. Using MS-NAP, the specified health metrics would be enforced before the system would be allowed access to your network.
There is an entirely different discussion about who has ownership of updating systems not controlled by your organization, much less whether they should be allowed on the network directly. But, should that requirement exist, using MS-NAP would enforce the rules of your network before a system is granted access to the network. This can bridge the gap of standards between your network and the technology group that issues this equipment.
Of course, the prime implementation scenario for MS-NAP is for an organization's remote users (either notebooks or home computers) to avoid the risk that may exist from a lapse in connectivity. On the rare occasion of home users on systems with potentially zero management connecting to a network, a broad-reaching risk is introduced. Having the MS-NAP implementation in place for all systems connecting remotely will extend the management to systems that are harder to manage due to limited connectivity intervals. The MS-NAP client does not have to be a member of your organization's AD domain (from a computer account perspective). Authentication can be managed in AD directly, however.
Microsoft resources for MS-NAP
There is good information available on preliminary MS-NAP planning and test implementation for beta Windows Server 2008 systems. However, Microsoft provides a good architecture white paper on the implementation from a holistic perspective. This whitepaper can be found at Microsoft's Web site.
Cross-platform NAP support
The MS-NAP implementation is based on the broadly supported IEEE 802.1X authentication protocol. This will provide compatibility among various devices and the Windows Server 2008, Vista, and XP clients with NAP support. In summary, IEEE 802.1X authentication enables secure access to standard Ethernet and Wireless networks. This is done through RADIUS per the standard for IEEE 802.1X.
The main benefit of selecting this authentication protocol is that it doesn't require an authentication server in a backend role. This means that the networking equipment that is compliant with this authentication protocol can pass the requests to the MS-NAP roles identified by the configuration. The MS-NAP implementation can then allow you to manage the authorization, accounting, and authentication centrally with the health metrics. There are many equipment vendors on board with this protocol, and it was developed by HP, Microsoft, Cisco, Trapeze networks, and Enterasys.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.