Network Access Protection (NAP) Deployment Planning

  • Article

The following blog post has been extracted from the "Network Access Protection Deployment Planning Guide", by Susie Bernard (March 2007).

 

Introduction

Whether your organization is small, medium, or large, deploying an enterprise software solution like Network Access Protection (NAP) requires careful planning. Deploying NAP involves network infrastructure design evaluation, how clients connect to that network, and what criteria those clients need to meet to be considered compliant.  Detailed planning increases the probability that your NAP deployment will be a success.  

Deploying NAP involves configuring NAP settings on both the servers and the client computers. The server components are responsible for validating the health of client computers and specifying which network resources are available to them.

NAP client components are responsible for compiling health status statements on NAP client computers, maintaining client computers' health state, and communicating that health state to the server components.

Phases of deployment

The stages of any enterprise software deployment project are generally categorized according to phases, as follows:

  • Planning
  • Lab testing
  • Pilot deployment
  • Production deployment
Planning

This deployment planning guide can help administrators with the planning deployment phase of a NAP implementation.

Lab testing

For assistance with the lab testing phase of a NAP implementation, consult the step-by-step guides that are available for download on the NAP home page on TechNet.

Pilot deployment

Follow up your lab testing with a pilot deployment. For the pilot, deploy NAP to a select group of computers and/or users. Begin by enabling NAP in reporting mode only. In other words, configure NAP to implement Network Policy Validation where the health state of computers that request network access is validated against the network access policies you've defined, but network access is not restricted -- regardless of the client's state of health. This allows administrators to assess and analyze the health of the computers attaching to the network prior to enabling any enforcement methods that can potentially restrict network access.

As you gather data and determine the level of compliance in your pilot group, phase in an enforced health policy to computers in the pilot group by restricting network access to noncompliant client computers. While running NAP in reporting mode, ensure that you take the necessary actions to bring noncompliant NAP clients into compliance before enabling enforcement.

Production deployment

Carefully planning your deployment, performing lab testing, and completing a pilot deployment can help ensure a successful production deployment.

Decision Areas

Planning a NAP deployment requires making decisions surrounding health policy, enforcement, and remediation. This guide contains the following topics to aid you in planning your NAP implementation:

  • Defining NAP Policy
  • Choosing Enforcement Methods
  • Choosing Remediation Techniques

In order to proceed with these decisions, administrators should be familiar with how users and computers are grouped and managed within the network. This can help define how to control network health evaluation and enforcement. Administrators should also understand the requirements and components of NAP. Decisions must be made regarding the system health agents (SHAs) that are installed on the client computers and system health validators (SHVs) that are installed on the server running Network Policy Service (NPS [1] ). Administrators will have to deploy these NAP components before they can configure and enable a network policy that enforces a client health policy. Therefore, a good understanding of these concepts is necessary to the planning process. Although NAP concepts are not described in this deployment planning guide, more information about NAP requirements can be found in the Windows Server 2008 online Help and in various articles linked to on the NAP home page on TechNet.

[1] The acronym NPS is used interchangeably in this document to refer to both the Network Policy Service and the computer running Network Policy Service (informally, Network Policy Server).

Defining NAP Policy

NAP policies are made up of Network Policy Server (NPS) authorization settings and define how NPS enforces client computer compliance with network health requirements.

In order to define a NAP policy, an administrator must answer the question, "What is compliant and what is noncompliant?" The answer to this question is based on a number of factors, most importantly your IT organization's security policies and other computer requirements dictated by IT management.

This section helps administrators address the most common NAP policy decisions surrounding the following computer health concerns:

  • Virus protection
  • Windows updates
  • Firewall protection
  • Spyware protection

Note: Although there might be other concerns, these four decisions are addressed here because they are the most common and because each of these areas is addressed by a system health agent (and its corresponding system health validator) in the first release of NAP in Windows Server 2008 and Windows VistaTM.

Anti-virus Protection

Health policies surrounding anti-virus solutions can vary from one organization to the next. There are a number of questions to be addressed in defining anti-virus health policy. For example, your organization's IT security team requires an anti-virus solution in the environment. Essentially, this would mean that computers connecting to the network must have some type of anti-virus software installed. The NAP administrator must then answer the questions:

  • Is a particular manufacturer of anti-virus software required by security policy?
  • If so, is specific versioning of the product required at all times?
  • Or, is the requirement simply that the most updated version of the anti-virus software is necessary?
  • Does policy require that the most recent anti-virus updates are installed on each computer?
  • If so, how does your organization define "most recent" for health policy? Should the computer have all updates that are more than ten days old? Seven days? Two days?
  • Does policy require that full anti-virus computer scans are performed on a specified schedule?
  • If so, what is the maximum allowable timeframe for the most recent scan? Should the scan have occurred in the past two weeks in order for the computer to be deemed compliant? The past seven days?

The NAP administrator can build an anti-virus health policy based on the answers to these questions. Many of the features needed to do this are built into NAP already. It operates in conjunction with the Windows Security Health Agent included in Windows Vista (and available for download for Windows® XP Service Pack 3) and in the Windows Security Health Validator included in Windows Server 2008. Other capabilities might be provided by NAP anti-virus partners. For a current list of partners and descriptions of how their products integrate with NAP, see Network Access Protection Partners.

Windows Updates

Another common security requirement is that computers have the latest Windows updates installed. Questions surrounding this type of health policy might include:

  • Are important updates which can improve Windows security and reliability required by computers connecting to the network?
  • If so, with what frequency should the client computer check for updates? Should the client have checked within the past week? Within the last 24 hours?
  • Should Windows Updates be enabled on the client and if so, with what frequency should update checks be performed in order for the computer to be considered compliant? Should updates be installed automatically or at the user's discretion?
  • Are recommended updates which address non-critical system problems required?
  • Are optional updates such as updated device drivers required?

Generally the NAP administrator should coordinate Windows Update policy with the IT staff members who are responsible for patch management on the secure network. This might include an SMS administrator, a Windows Server Update Services (WSUS) administrator, Active Directory group policy administrator, or other patch management solution administrator.

Firewall protection

Decisions regarding firewall policies are generally straightforward. Windows Firewall is a component of the Windows client operating systems that are supported by NAP. In defining Windows firewall health policy, the administrator should ask the following questions:

  • Does health policy dictate that a firewall is turned on?
  • If so is Microsoft Windows Firewall required, or are other third-party firewall solutions sufficient?
  • Is it necessary to configure the firewall to block all unsolicited attempts to connect to the computer?
Spyware Protection

Another health policy decision for administrators to address is whether or not to define a health policy for spyware protection and if so, whether or not to require a specific anti-spyware software solution for compliance. For example, a spyware protection health policy might require that Windows Defender is installed and enabled for real-time protection. Windows Defender is included in the Windows Vista operating system and can be downloaded from Microsoft.com for installation on the Windows XP platform.

Other Configuration Settings

Your organization might have health policy needs beyond those provided out-of-the-box with NAP as described here. In that case, plan to evaluate what these additional needs are and consult the Network Access Protection Partners to determine which NAP partners can provide an SHA and an SHV that fits your organization's additional needs.

Other NAP Policy Decisions

As you create a checklist of the health policies that are required for your organization, you must make decisions about which system health agents to deploy, what to do with noncompliant computers, and what to do with computers connecting to your network that are not NAP-capable--such as computers running a UNIX operating system.

For example, you might choose to provide exceptions to certain computers in your organization that are not NAP-capable, or you might choose to restrict network access to all clients that are not NAP-capable. The decisions will depend upon the needs of your organization and its security policy. For more information, see Unsupported platforms later in this section.

System health agents and system health validators

Administrators must decide which system health validator (or combination thereof) will be part of the health check. When you define a network health policy on the NPS server, you must decide which system health validators will apply to that particular policy.  Each system health validator that is enabled on the NPS as part of a health policy requires that a corresponding system health agent is installed on the client computers that are being evaluated against that policy when they attempt to connect to the secure network. An important factor to note is that your network might have more than one type of system health validator. If so, the NPS must coordinate the output from all of the SHVs and determine whether (and how) to limit the access of a noncompliant computer. This requires careful planning when defining health policies and evaluating how different SHVs interact.

Example: You are applying three different SHVs: A, B, and C. In this example scenario, SHV "A" deems the client computer to be compliant with its policy; SHV "B" also determines the same result; however, SHV "C" deems the computer to be noncompliant. It is the administrator's responsibility to configure NPS to react appropriately based on those mixed results. The administrator needs to define whether a compliant machine is required to pass one, all, or a specific combination of the SHV checks.  

Windows Security Health Agent and Windows Security Health Validator

Administrators might choose to use the built-in system health validator and system health agent that ship with Windows Server 2008 and Windows Vista.  Windows Vista includes a system health agent as part of the operating system called the Windows Security Health Agent. It can provide health statements based on Windows Security Center reporting features including the status of firewall software, antivirus software, anti-spyware software, and Automatic Updates. Windows Server 2008 includes the Windows Security Health Validator that corresponds to the Vista health agent.

Note: At the time of this guide's publication, Microsoft is developing the Network Access Protection Client for Windows XP (now in beta testing) that will be released at the same time as Windows Server 2008. For more information, see Down-level OS Support on the NAP Blog.

The Windows Security Health Agent and Windows Security Health Validator provide the following functionality for NAP-capable computers:

  • The client computer has firewall software installed and enabled.
  • The client computer has antivirus software installed and running.
  • The client computer has current antivirus updates installed.
  • The client computer has anti-spyware software installed and running.
  • The client computer has current anti-spyware updates installed.
  • Microsoft Update Services are enabled on the client computer.
  • In addition, if NAP-capable client computers are running Windows Update Agent and are registered with a Windows Server Update Service (WSUS) server, NAP can verify that the most recent software security updates are installed based on one of four possible values that match security severity ratings from the Microsoft Security Response Center (MSRC). Note that with the release of Windows VistaSP1 and Windows Server 2008, patch management will also be able to validate against Windows Update and Microsoft Update (WU/MU), in addition to WSUS.

Note: Windows Security Center depends on status notification from the anti-virus software, firewall software, and anti-spyware software in order to recognize it. For example, if the anti-virus software in use does not have the ability to report to Windows Security Center that it is up-to-date, then the Windows Security Center might not report that. So, keep in mind that there is some dependency on the anti-virus software, anti-spyware software, and firewall software to integrate with Windows Security Center.

Noncompliant computers

For noncompliant computers, you must decide what level of network access (if any) you are going to allow those computers. The type of restricted access that can be enforced on noncompliant computers is dependent upon which enforcement method is applied when the computer attempts a network connection. For more information about making this decision, see Choosing Enforcement Methods later in this guide.

Unsupported platforms

Administrators must also decide how to deal with non-supported platforms and network traffic that may attempt network access. These types of devices cannot submit a statement of health and therefore cannot participate in the NAP health evaluation. The network administrator must decide how to deal with these devices.

The administrator might decide that any device that cannot be evaluated for health using NAP will be kept on a restricted access network, then configure that restricted access so it provides the necessary support for those devices.  On the other hand, the administrator might choose to allow all devices not capable of doing NAP to be given full access to the secure network. There are obvious risks involved in doing this. One risk is that a computer that is capable of doing NAP (i.e., a computer running Windows Vista) could appear as being not NAP-capable by disabling the NAP client software. If the number of devices that are not NAP-capable is manageably small, the administrator might consider managing their access by exception. For example, if you know the MAC address of the device that is not NAP-capable, you can explicitly grant full access to that device without allowing all non-NAP capable devices full access. Another option is using a third-party offering for doing health evaluations of these devices.

Choosing Enforcement Methods

After outlining health policy, administrators need to determine how (or if) the organization should enforce Network Access Protection (NAP) in the organization. Read this section to determine which questions to ask when choosing enforcement methods during the deployment planning phase and to understand the advantages of choosing one enforcement method over another.

Note: After creating an initial list of health policies, it's a good idea to determine the extent to which the computers connecting to your network are compliant. This is easily done with NAP by enabling NAP in reporting mode only. In reporting mode the NAP client's health is evaluated but access restrictions are not imposed on computers that do not pass the health check. All computers, regardless of health compliance, are given full access to the secured network. However, because the health evaluation results are recorded in the logs on the NPS, the administrator can generate reports regarding the overall health status of the network. Doing this gives administrators an idea of the percentage of computers that are noncompliant, which can also help in determining which enforcement method(s), if any, to use.

Ensure that you understand the enforcement methods that are available in NAP. NAP enforcement methods are any-of-four network access technologies that work in conjunction with NAP to enforce health policies. Table 1 briefly describes the four built-in NAP enforcement methods (known as "enforcement clients") and their corresponding network access mechanisms.

Keep in mind that NAP enforcement methods are not mutually exclusive. Administrators might choose to use multiple-supported enforcement methods in different combinations.

Table 1. NAP enforcement clients

Enforcement client

Description

Dynamic Host Configuration Protocol (DHCP)

Enforces health policies when a client computer attempts to obtain an IP address from a DHCP server.

Extensible Authentication Protocol (EAP) for IEEE 802.1X connections

Enforces health policies when a client computer attempts to access a network using EAP through an 802.1X wireless connection or an authenticating switch connection.

Remote access for VPN connections

Enforces health policies when a client computer attempts to gain access to the network through a virtual private network (VPN) connection.

Internet Protocol security (IPsec) communications

Enforces health policies when a client computer attempts to communicate with another computer using IPsec.

 

In addition to the built-in enforcement clients, administrators might use additional third-party enforcement clients. For more information about these, see Network Access Protection Partners and consult with the appropriate vendor.

Questions to Help Administrators Choose Enforcement Methods

This section describes some fundamental questions that administrators need to ask when determining which enforcement methods to use with NAP.

Are any computers connecting to the network remotely?

The most fundamental question is whether or not client computers are connecting to the protected network remotely. If clients are connecting from locations that are outside of the protected network by way of a virtual private network (VPN) and you need to check them for health policy compliance before allowing them unrestricted network access, then administrators should consider using the VPN enforcement method.

VPN enforcement works by using a set of remote access IP packet filters to limit the traffic of the VPN client so that it can only reach the resources on the restricted network. The VPN server applies the IP packet filters to the IP traffic that is received from the VPN client and silently discards all packets that do not correspond to a configured packet filter. If the VPN client is noncompliant, the VPN connection has the packet filters applied and the VPN client can only reach resources on the restricted network.

Essentially with VPN enforcement, you can restrict the client to a logical network that can only access remediation servers. These client computers would remain restricted from broader connectivity to resources in the protected network until they are brought into a compliant state.

Note: The VPN server component must be NAP-enabled. At this time, only the Microsoft Routing and Remote Access service in Windows Server 2008 support NAP, although NAP partners might provide integrated NAP-enabled VPN server software at a later time.

Are computers using DHCP to obtain an IP address on your network?

The second most fundamental question surrounds the IP addressing scheme your organization uses. If your organization uses Dynamic Host Configuration Protocol (DHCP) to distribute IP addresses to computers connecting to the network, consider using DHCP enforcement to provide network access protection.

DHCP enforcement works by limiting network access for the DHCP client through its IP routing table. DHCP enforcement sets the DHCP Router option value to 0.0.0.0 so that the noncompliant computer is not configured to use a default gateway. DHCP enforcement also sets the subnet mask for the allocated IP address to 255.255.255.255 so that there is no route to the attached subnet.

As with VPN enforcement, using DHCP enforcement can restrict the client to a logical network that can only access remediation servers.

To allow noncompliant computers to access the remediation servers on the restricted network, the DHCP server assigns the Classless Static Routes DHCP option which contains a set of host routes to the computers on the restricted network, such as the DNS and remediation servers. The end result of DHCP limited network access is a configuration and routing table that allows connectivity only to specific destination addresses. Therefore, when an application attempts to send to a unicast IPv4 address other than those supplied via the Classless Static Routes option, the TCP/IP protocol returns a routing error.

Note: At this time, DHCP enforcement is for IP version 4 (IPv4) and does not support IP version 6 (IPv6)-based DHCP clients. However, IPv6 support might come at a later date either for Microsoft DHCP for IPv6, or for a third-party DHCP provider. DHCP enforcement requires a NAP-enabled DHCP server, which at the present time is only supported by the Microsoft DHCP Server component that is included in the Windows Server 2008.

Do network users have administrative privileges on their computers?

If you are considering using DHCP enforcement, keep in mind that one of the weaknesses of DHCP enforcement is that it can be overridden by assigning a static IP address to the client computer. Because DHCP enforcement is based on entries in the IPv4 routing table, it cannot prevent a malicious user who is a local administrator from manually changing the IPv4 routing table and gaining access to the protected network, thus bypassing NAP policy enforcement.

Are you using Microsoft's DHCP Service?

Microsoft's DHCP Service is currently the only DHCP provider that is NAP-enabled. If you are using a third-party DCHP provider, check with your DHCP software vendor to determine if that vendor has plans to support NAP. You may consider implementing a different NAP enforcement method in the meantime.

The next section summarizes the differences between VPN and DHCP enforcement methods.

VPN vs. DHCP

VPN enforcement limits the access of noncompliant VPN clients that are attempting to access the protected network through a VPN connection by restricting their IP connections through a packet filtering technique. DHCP enforcement limits the access of noncompliant DHCP clients that are attempting to obtain a valid IP address configuration by granting an IP address to the client, yet removing routing capability from it. In both of these cases the access to a restricted network is based on a client-server relationship and implemented at the server through which the client is requesting network access or configuration.

Keep in mind that you can configure NAP to employ more than one enforcement method. The NAP administrator can configure NAP to perform health checks only on clients connecting via VPN, or only on computers connecting directly via DHCP, or on both.

Does your wired network employ the IEEE 802.1X protocol?

If your wired or wireless network currently uses the IEEE 802.1X standard, which defines port-based user authentication methods used when accessing the network, then you should consider using 802.1X enforcement. It is a more secure way of providing network access protection for your intranet than DHCP or VPN enforcement. If you are not currently using wire 802.1X for network connectivity, you should investigate the expense and complexity of implementing 802.1X authentication on your network prior to choosing it as a NAP enforcement method. It is not uncommon for a wired 802.1X implementation to require a fairly hefty hardware investment. Wireless 802.1X implementations are typically less cost-intensive than wired 802.1X implementations.

IEEE 802.1X enforcement works by instructing the 802.1X-capable access point (for wireless) or the 802.1X-capable switch (wired) to use a limited-access profile--either a set of IP packet filters or a virtual LAN identifier (VLAN ID)--to limit the traffic of the 802.1X-based noncompliant client, so it can only reach resources on the restricted network. For IP packet filtering, the 802.1X-capable access point applies the IP packet filters to the IP traffic that is exchanged with the 802.1X client and silently discards all packets that do not correspond to a configured packet filter. For VLAN IDs, the 802.1X-capable access point applies the VLAN ID to all of the packets exchanged with the 802.1X client and the traffic does not leave the VLAN corresponding to the restricted network.

Have you implemented or are you considering implementing a Public Key Infrastructure (PKI) in your organization?

If you are already using a Certification Authority (CA) and digital certificates in your environment for authentication, then you already have the infrastructure in place to use IPsec as a NAP enforcement method. Like 802.1X enforcement, IPsec enforcement provides better security than DHCP enforcement.

Unlike VPN and DHCP enforcement, IPsec is enforced at each individual computer rather than at the point of entry into the network. The determination of client health is performed by way of a health registration authority (HRA). The NAP client submits a request to the HRA asking for a health certificate. This health certificate is an X.509 certificate containing a specific object identifier (OID) identifying it as a health certificate. If the requesting client is compliant, the HRA responds to the request by obtaining a health certificate from the Certification Authority (CA) and giving it to the client. That client is then able to present the health certificate to prove that it has passed a health check.

IPsec enforcement in NAP works by limiting the access of noncompliant clients that are attempting to communicate to servers in the secured network. When a noncompliant client attempts to connect to a protected resource, the resource requests that the client present its health certificate to prove that it has passed a health check. Because the noncompliant client does not have a health certificate, IPsec enforcement limits the client's network connectivity by causing the server to drop connection attempts coming from it (and from any computers without health certificates).

Administrators should configure the CA to distribute health certificates that are only valid for a short period of time, e.g. 24 or 48 hours. This forces the client to request a new health certificate when the current certificate expires. That client must then undergo another health check. The validity period for the health certificates is configured at the HRA and is a decision that the administrator must make.

The following are some of the benefits of IPsec enforcement.

Tamper-resistant. IPsec enforcement cannot be bypassed by reconfiguring a NAP client. A NAP client cannot receive a health certificate or initiate communication with a compliant computer without a health certificate by manipulating settings on their local computer, even for a user with local administrator privileges. Additionally, IPsec enforcement cannot be bypassed through the use of hubs or virtual computer technologies.

No infrastructure upgrade needed. IPsec enforcement works at the network layer of the Open System Interconnection (OSI) model rather than the data link layer; therefore, it is independent of physical network infrastructure components such as hubs, switches, and routers.

Flexible limitations. With IPsec enforcement, administrators can configure IPsec enforcement so that compliant computers can initiate communications with noncompliant computers, but noncompliant computers cannot initiate communications with compliant computers. The administrator defines the type of traffic that must be authenticated with a health certificate and protected with IPsec through IPsec policy settings. IPsec policy allows for the creation of IP filters that can define traffic by source IP address, destination IP address, IP protocol number, source and destination TCP port, and source and destination UDP port. With IPsec policy and IP filter definition, it is possible to limit network access on a per-computer or per-application basis.

Compared to other NAP enforcement mechanisms (IEEE 802.1X, VPN, and DHCP), IPsec provides the strongest and most flexible form of NAP enforcement. IPsec enforcement is strong because it confines the communication with protected resources to compliant clients. IPsec enforcement helps protect the communication that occurs between two computers, regardless of their role.

By using IPsec as a NAP enforcement mechanism, administrators can help protect network traffic end-to-end and not just at the point of network access.

802.1X vs. IPsec

When determining how to protect your intranet and its assets, you do not have to choose between 802.1X for wired networks and IPsec. Because they operate at different layers and perform different functions, the use of one does not exclude the use of the other. From a security standpoint, it is better to deploy security technologies that create a series of barriers against an attacker. Deploying 802.1X for wired networks helps prevent unknown hosts from gaining access to your intranet. Deploying IPsec helps prevent unknown hosts from communicating with IPsec-protected hosts on your intranet.

An 802.1X communication requires network hardware that can be expensive if your organization has not already invested in it. However, a benefit of providing 802.1X NAP enforcement is that you are enforcing protection at the network port. If the computer is not compliant, you can restrict its access so that it can only send IP packets on a predefined VLAN, that is separate from the full-access VLAN, where compliant clients and servers are accessible to compliant clients. 

IPsec, on the other hand, does not require additional hardware. One of the differences of IPsec NAP enforcement is that the enforcement occurs at the host. The client can connect and send IP packets wherever it wants. Health policy decides which computers can receive packets from the noncompliant client.

Example:  A client computer that is attempting a network connection does not have antivirus software installed. If NAP is configured with 802.1X enforcement, the port can be shut down entirely for that client--or you can restrict the client computer to a virtual network that restricts its impact to the rest of the nodes on the protected network. IPsec enforcement on the other hand, determines through a health check that the client computer is not compliant, but the client still has the ability to connect to the protected network. IPsec policy instructs the protected nodes not to receive packets from the noncompliant computer. Thus, the noncompliant computer can in effect remain isolated from other computers on the protected network, but it is still connected to the network and can consume network bandwidth.

Security-wise, IPsec offers the option of end-to-end encryption. If encryption is a security requirement in your organization, by optionally specifying IPsec policy settings you can encrypt IP traffic between IPsec peers for highly sensitive traffic. Unlike IEEE 802.1X wireless LANs which only encrypt frames from the wireless client to the wireless access point, IPsec encryption is between IPsec peer computers.

Table 2 provides a high-level summary of the security provided by 802.1X and IPsec for wired networks.

Table 2. IPsec vs. 802.1X (for wired networks) security overview

Security property

802.1X for wired networks

IPsec

Authentication

X

X

Tampering and spoofing protection

X

X

Encryption

 

X

Protection for roaming clients

 

X

 

Table 3 provides a more granular comparison of 802.1X for wired networks and IPsec based on the 802.1X and IPsec standards.

Table 3. IPsec vs. 802.1X (for wired networks) in greater detail

802.1X for wired networks

IPsec

Authenticates and authorizes connections to a network.

With 802.1X, the enforcement of the requirement of valid credentials is performed at the network edge by the switch. Wired 802.1X is a Data Link layer security barrier. A computer cannot plug into an available network port and begin communicating on the network.

Authenticates communications between endpoints.

With IPsec, each end of the communication performs the enforcement of IPsec authentication. IPsec is a Network-layer security barrier. A computer cannot initiate communications with IPsec-protected intranet resources after obtaining a connection to the network.

Enforces security protection at the switch.

IEEE 802.1X for wired networks is only applied at the switch port. Other methods of accessing the intranet might not be protected with 802.1X.

Enforces security protection at the host.

IPsec policies are enforced by the host and apply regardless of the way that the host connects to the intranet or whether the host is connected to the intranet.

Does not provide cryptographic protection of traffic between the supplicant and the switch.

After authentication and authorization, there are no facilities within the 802.1X standard that protect the traffic on the 802.1X-authenticated link.

Optionally provides cryptographic protection of traffic between endpoints.

After authentication and negotiation of security options, IPsec protects packets with tamper-proofing and optional encryption.

Does not provide protection against attackers with physical access to a switch port.

After obtaining physical access to a switch port, an attacker that spoofs the MAC address of a valid host can gain access to the intranet.

Provides protection against unknown hosts.

An IPsec-protected host will discard spoofed packets sent by an unknown host.

Can provide protection against denial of service attacks that consume bandwidth.

Protection against denial of service (DoS) attacks, in which an attacker tries to overwhelm the network with packets, is not an inherent function of 802.1X, but a capability of many switches that support 802.1X authentication.

Can provide protection against denial of service (DoS) attacks launched against hosts.

IPsec is not designed to prevent a malicious host from transmitting packets. However, IPsec can prevent received packets from being processed. IPsec can silently discard unprotected packets upon receipt.

Works for all networking protocols.

IEEE 802.1X operates at the Data Link layer before a connecting host sends any network protocol frames or packets.

Works only for IP-based traffic.

IPsec can only protect packets that have an IP (IPv4 or IPv6) header.

Requires that your switches support 802.1X.

The switches in your switching fabric must support 802.1X authentication and the use of RADIUS tunnel attributes to control VLAN ID or IP filtering.

Requires no additional support from the network infrastructure.

IPsec operates at the network layer and works over any IP-based network.

Requires that your network hosts support 802.1X.

The connecting network hosts must support 802.1X authentication for LAN connections and the EAP methods required by the RADIUS server.

Requires that your network hosts support IPsec.

The network hosts must support IPsec, common authentication methods, and common cryptographic algorithms for key determination, Hash-based Message Authentication Codes (HMACs), and encryption (optional).

Requires an authentication infrastructure consisting of RADIUS servers and account databases.

To perform authentication and authorization you must deploy account databases to store computer and user accounts and their credentials, and RADIUS servers to evaluate the connection attempt.

Requires an authentication infrastructure (depends on the IPsec authentication method).

To perform IPsec authentication, you must deploy an authentication infrastructure that can authenticate the credentials of IPsec peers.

Simple or group-based network access.

IEEE 802.1X provides a simple allowed/denied access to intranets. Whether the access is simple or group-based, 802.1X allows all traffic from an authenticated host. Many switches also support the use of virtual LANs (VLANs) to group ports together or to specify the types of traffic allowed on the switch port.

Isolated or granular network access.

You can use IPsec policy and authentication methods to isolate portions of your network. IPsec settings can specify different levels of protection for network traffic to the granularity of IP addresses and TCP or UDP ports.

Requires no changes to applications.

Because it operates at the Data Link layer, 802.1X does not require application support.

Requires no changes to applications.

Because it operates at the Network layer, IPsec does not require application support.

Cannot protect against a trusted attacker.

If a host has the proper credentials for 802.1X authentication, the switch cannot prevent the host from attacking the network.

Cannot protect against a trusted attacker.

If a host has the proper credentials for IPsec authentication and the correct policy settings for IPsec protection of traffic, IPsec cannot prevent the host from attacking other hosts.

 

In summary, this section presents fundamental questions to consider when choosing an enforcement method. Consider the following:

After determining the enforcement methods to use with NAP, you should whether or not there will be exceptions to the enforcement rules--for example, computers in your organization that are running Linux. Devise a plan for dealing with those and other computers that are not NAP-capable. Essentially, if NAP asks a client computer for a statement of health but the client does not provide it, that computer is not a NAP-capable computer and administrators must determine whether to restrict network access for that computer or grant it full access to the secured network. When granting limited access, the administrator must understand which network resources the computer must be able to access in order to perform day-to-day operations and make these resources available in the restricted network. 

Choosing Remediation Techniques

The remediation techniques that your organization uses to bring noncompliant computers into compliance with network health policy are dependent upon the health policies that are in effect. Many organizations are already running server applications in their environment that provide ongoing updates to computer nodes that are connected to the network, some of which are NAP-aware. If the remediation technique in use provides the ability for clients to receive notification from NAP health agents and to pull updates from the remediation server, then most organizations will continue to use their existing patch management system for remediation in a NAP environment.

Basically these remediation servers contain health update resources such as the necessary security updates, configurations, and applications that client computers can access to remediate their noncompliant state. Examples include antivirus signature distribution servers, computer management servers (e.g. Microsoft Systems Management Server), and software update servers (such as Microsoft Windows Software Update Services). Various remediation methods exist. Some remediation servers push content out to client computers, other remediation techniques are configured to allow the client to pull content from the remediation servers.

If you already have remediation servers on your network, part of the NAP deployment planning process is determining if your existing remediation techniques are NAP-aware and how to use them in conjunction with NAP network access restrictions being enforced on noncompliant computers. If you have not yet deployed remediation servers on your network, you should begin planning the type of remediation servers that you will need (based on health policies), and the locations of these servers on your network (based on enforcement methods). For example, administrators might choose to put some of their remediation servers in a restricted network to which the noncompliant NAP clients can connect. The NAP clients can then communicate with remediation servers to become compliant, based on instructions from the NPS server.

Example deployment of a network policy that enforces NAP

The following scenario included in the NAP Components topic in the online Help for Network Policy Service, is an example of creating a network policy that enforces NAP. At the end of the example is a high-level summary of the steps required to create the policy.

In this example, a network administrator creates a network policy that is enabled, grants access, and enforces NAP for NAP-capable 802.1X wireless client computers running either Microsoft®Windows XP with Service Pack 3 or Windows Vista. 

In this example "A. Datum" and "A. Datum Antivirus" are the fictional names used. Configuration of the A. Datum Antivirus SHV shows how third-party SHVs can be incorporated into a NAP deployment. A. Datum has designed A. Datum Antivirus to be compatible with NAP, and provides its customers with the A. Datum Antivirus SHA and SHV components to allow them to implement a NAP solution with A. Datum Antivirus.

For this example, the following assumptions exist:

  • 1. The administrator has already configured Group Policy configuration for NAP clients, and all NAP clients are domain member computers.
  • 2. The administrator has already installed NAP upgrades for client computers running Microsoft Windows XP with Service Pack 3.
  • 3. The administrator has already deployed NAP remediation servers that can provide client computers with antivirus signature updates. In NPS, the administrator has created a Remediation Server Group named A. Datum Antivirus Remediation Servers.
  • 4. The administrator has already deployed wireless access points that support 802.1X and RADIUS, and the wireless infrastructure is functioning properly before NAP is configured and enforced by NPS.
  • 5. The administrator has already deployed a Web server on the remediation network that contains help for NAP users at the Uniform Resource Locator (URL) address https://naphelp.
  • 6. The administrator has already created a group in Active Directory named WirelessNAPUsers and has added user accounts to the group for users that have NAP-capable client computers. In addition, the administrator has already created a group in Active Directory named WirelessUsers for users that do not have NAP-capable client computers.
  • 7. The NPS server is configured as a RADIUS server and wireless access points are configured in NPS as RADIUS clients.
  • 8. The example third party SHV and SHA are not installed yet. The network administrator uses antivirus software created by a company named A. Datum, and the product is named A. Datum Antivirus.
Network administrator goals for NAP

In this example, the network administrator has the following goals for NAP:

  • 1. Using the A. Datum Antivirus SHV and SHA, the administrator wants to ensure that client health checks include verification that A. Datum Antivirus with the most recent antivirus signatures are installed on client computers. The administrator also wants to configure NAP autoremediation so that the most recent signatures are automatically downloaded and installed on client computers.
  • 2. Using the Windows Security SHV and SHA, which are included in the WindowsServer 2008 and WindowsVista operating systems respectively, the administrator wants to ensure that client health checks include verification that Windows Firewall is enabled and that Microsoft Update is enabled so that client computers have all of the most recent Windows security updates installed. The administrator also wants to configure NAP autoremediation so that the most recent security updates are automatically downloaded and installed on client computers if they do not already have the most recent security updates.
Example deployment steps

For this example deployment the following steps are required:

  • Install NAP SHA components on NAP clients.
  • Install SHVs on NPS server.
  • Configure SHVs for the desired health policy.
  • Run the New Network Policy Wizard to create NAP health policies. Configure the policy such that it is not restricting network access and is operating in reporting mode.
  • Enable the network policy and set the policy to grant access.
  • Monitor the NAP health of the clients and address any problems to reduce the number of noncompliant clients to the desired level.
  • In the network policy, enable network restriction using a desired grace time to allow clients time to attain compliance before being restricted (probation mode).
  • Monitor the NAP health of the network running in probation mode for a period of time until satisfied that operations are performing as expected.
  • In the network policy, eliminate the grace period and implement enforcement mode--where noncompliant clients are given restricted access at the time of health check until they undergo remediation and are returned to a compliant state.

Enabling NAP Monitoring and Reporting

It is a good idea to be familiar with how to enable NAP reporting so that you can troubleshoot issues and monitor status during the lab testing and pilot deployment phases of your NAP implementation. This section provides an overview of the Network Policy Service logs.

Plan to enable the two types of logging in Network Policy Service (NPS) during lab testing and your pilot deployment.

  • Event logging for NPS : Records NPS events in the system event log. This is used primarily for auditing and troubleshooting connection attempts.
  • Logging user authentication and accounting requests:Logs user authentication and accounting requests to log files in text or database format, or in a stored procedure in a SQL Server 2000 or SQL Server2005 database. Request logging is used primarily for connection analysis and billing purposes. It is also useful as a security investigation tool, providing a method of tracking down the activity an attacker.

To make the most effective use of NPS logging, you should turn on logging (initially) for both authentication and accounting records. After you've successfully deployed and configured NAP in your production environment, you can modify these selections based on what is appropriate for the environment. You should plan to have a log-file backup system in place, because the logs cannot be recreated when they are damaged or deleted. Also, ensure that event logging is configured with a capacity that is sufficient to maintain the logs. If you choose to store the logs in a database, plan to provide failover and redundancy. With SQL Server logging, place two computers running SQL Server on different subnets. Use the SQL Server Create Publication Wizard to set up database replication between the two servers. For more information, see the SQL Server documentation.

NAP Resources

See the following links for more information about NAP:

Introduction to Network Access Protection

Overview of NAP scenarios and NAP components and a brief description of how NAP works for Internet Protocol security (IPsec)-based communication, 802.1X authenticated connections, virtual private network (VPN) connections, and Dynamic Host Configuration Protocol (DHCP) configuration.

Frequently Asked Questions about Network Access Protection

Frequently asked questions about NAP.

Network Access Protection Platform Architecture

Detailed description of the components of the NAP architecture, how NAP works, and how NAP allows third-party software vendors and system integrators to create complete solutions for system health validated network access.

Internet Protocol Security Enforcement in the Network Access Protection Platform

Detailed description of how IPsec enforcement in the Network Access Protection platform works to provide system health validation and enforcement for IPsec-secured communication.

Configuring Network Access Protection Policies in Windows Server 2008

Description of how to configure NAP health requirements and enforcement behavior using the Network Policy Service (NPS) in Windows Server 2008.

Summary

This guide describes the decisions that an administrator must make when planning a Network Access Protection (NAP) deployment. NAP is a network access control technology included in Microsoft Windows Vista, Windows XP Professional Service Pack 3, and Windows Server 2008. This guide does not describe NAP concepts or the components of NAP. Rather, it provides a brief overview of the following phases of a NAP deployment and describes running NAP in reporting mode before fully enabling its enforcement and network restriction capabilities:

  • Planning
  • Lab testing
  • Pilot deployment
  • Production deployment

The main topics of this guide are defining health policy, comparing and choosing NAP enforcement methods, and defining network restrictions for noncompliant client computers undergoing any of these enforcement methods:

  • Virtual private network (VPN) connections
  • Dynamic Host Configuration Protocol (DHCP) address configuration
  • Internet Protocol security (IPsec)-based communication
  • IEEE802.1X-authenticated connections

Remediation techniques used to bring computers into compliance are also discussed, as is the recommendation that administrators enable reporting for NAP in order to troubleshoot issues during the phases of deployment and monitor progress. Also included in this deployment guide is a sample deployment scenario.