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.

Figure A

MS-NAP includes different roles.

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.