Troubleshooting NAP Problems
Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
The topics in this section are intended to group Network Access Protection (NAP) problems into symptom-based categories. Each topic provides a detailed description of the problem and its associated symptoms. Where appropriate, operating system events that occur due to the problem are documented. Possible root causes are listed, and procedures are provided to fix the problem. Troubleshooting techniques you can use to assist in finding solutions to problems that might not be documented, and to help in identifying a root cause are described in the following section.
Troubleshooting NAP
The first step in isolating the cause of a NAP-related problem is to gather information about the problem. Start by obtaining the information described in Things to Check Before Troubleshooting NAP. Begin the troubleshooting process with this basic information before using more advanced troubleshooting tools and techniques.
Starting the troubleshooting process
In addition to gathering basic information, ask yourself the following questions when you start the troubleshooting process:
What is the scope of the problem? If it is isolated to a single computer or a group of computers, what is unique about these computers?
Has NAP worked previously on these computers? If so, what might have changed?
What is the impact of the problem? If it is serious, can you do anything to mitigate the problem until you find a permanent solution?
Are there any risks associated with troubleshooting or fixing the problem? If the problem occurs in a production environment, you might need to schedule a time when you can investigate and repair the issue.
How to troubleshoot NAP problems
Never start troubleshooting a problem in the middle. Instead, find the first event in a process and begin there. Alternatively, you can find the last event and work your way backward. It is also useful to group processes into categories and determine whether that category of processes is working properly.
Consider the following process categories when troubleshooting a NAP problem:
Client access request submission.
NAP enforcement point forwarding to Network Policy Server (NPS).
NPS analysis and reply to the client access request.
Application of network access by the NAP enforcement point.
Client remediation.
For NAP, the first process category results in submission of a statement of health (SoH) from the NAP client computer. The SoH is sent with a network access request that essentially says, “Here is my identity and health status. Please approve network access.” The client computer then waits for a response.
The request for network access is sent to a NAP enforcement point that forwards the request to NPS for analysis. NPS analyzes the access request by using the list of connection request policies and network policies. For each type of policy, NPS starts at the top of the processing order and moves down one policy at a time, attempting to match the client access request. If a match is found, processing stops, even if a more specific match might be found lower in the processing order. This is an important consideration. When you configure the order of connection request policies and network policies, make sure that more general policies are located below more specific policies in the processing order.
Note
NPS can skip processing of some policies if the access request contains a source attribute. For more information, see General Policy Design Considerations in the Network Access Protection Design Guide.
Whether or not it finds a match for the client access request, NPS sends the results back to the NAP enforcement point, which informs the client computer of the results and then grants or denies network access based on these results.
Client access request submission
The following client-side components affect access request submission:
The NAP Agent service.
The NAP Agent service acts as a bridge between the system health agents (SHAs) and an enforcement client. If the NAP Agent service is not running, then the enforcement client will not provide information about client health when the computer makes a network access request. This typically results in the client computer being evaluated by NPS as non-NAP-capable. This problem can occur if the NAP Agent service has not yet started when the computer is authenticated, as might happen after a computer has been restarted. It can also happen if the NAP Agent service has been disabled or does not have permission to start.
SHAs.
SHAs monitor and report on the client’s health status. In other words, they keep tabs on the configuration of the client computer and will submit a new SoH when configuration changes or when the previous SoH has expired. SHAs can work with services on the computer to monitor configuration. For example, the Windows Security Health Agent (WSHA) that is included with Windows 7, Windows Vista® and Windows XP with Service Pack 3 (SP3) uses the Security Center service to monitor client health. A SHA must be registered with NAP Agent to communicate successfully, and it must be initialized to provide an SoH. A SHA will attempt to provide an SoH if the corresponding system health validator (SHV) is enabled in a health policy on NPS. If a SHA is not able to provide an SoH to the NAP Agent service, the client computer will be considered noncompliant if that SHA is required by network policy. This can occur with the WSHA, for example, if the Security Center service is not started. It can also occur if a SHA is not properly registered or initialized.
Enforcement clients.
Enforcement clients are responsible for communicating with NAP server components. They receive a list of SoHs from NAP Agent and forward this list as a single encapsulated SoH to the NAP enforcement point. The NAP enforcement client can also be responsible for applying network access conditions. For example, the IPsec enforcement client (the IPsec Relying Party) is responsible for deleting health certificates from the client certificate store when the client becomes noncompliant with health requirements or when the health certificate expires. When you enable an enforcement client, it must also be initialized before it will work.
Note
When you use the netsh nap client show state command on computers running Windows Vista with no service packs installed, the status of an enforcement client might be incorrectly displayed as not initialized. Review NAP client events to determine if the enforcement client is initialized. If a NAP enforcement client is not enabled and initialized, the NAP client computer will not provide its health status as part of the network access request. This can result in the client computer being evaluated by NPS as non-NAP-capable. This problem can occur if you have enabled an enforcement client in local NAP client settings and configured other NAP client settings in Group Policy. In this case, the local settings will be ignored.
NAP enforcement point forwarding to NPS
The following factors affect NAP enforcement point forwarding of NAP client access requests:
Forwarding configuration.
If the NAP enforcement point also serves as a NAP health policy server, then there is no forwarding configuration. The NAP enforcement point will always have a forwarding configuration if it is an 802.1X-compliant network access device, such as a switch or wireless access point. In this case, forwarding is configured in the authentication, authorization, and accounting (AAA) settings on the device. If you are using NAP with VPN enforcement, the enforcement point can be a server running the Routing and Remote Access service (RRAS). NPS might be installed on this server, but it is not required. If you are using NAP with IPsec enforcement or DHCP enforcement, then NPS will always be installed on the NAP enforcement point. If NPS on this device is not configured to forward authentication requests to a remote RADIUS server group, then authentication will be performed on the NAP enforcement point. This can cause a problem if you do not have NAP policies configured on this server because NPS is expected to forward the authentication request. This problem typically results in denial of NAP client access requests.
NAP-capable setting.
When you use NAP with IPsec enforcement, VPN enforcement, or DHCP enforcement and the enforcement point is not on the same server as the NAP health policy server, you must configure RADIUS client settings. In addition to the standard settings, such as IP address and shared secret, a RADIUS client used with NAP must be configured as NAP-capable. If you used the NAP configuration wizard used to configure the RADIUS client, this setting can be overlooked because it is not displayed in the interface. To configure this setting, you must view RADIUS client properties in the NPS console. Using a RADIUS client that is not configured as NAP-capable produces different results for each of the NAP enforcement methods. For example, HRA servers that are configured to be NAP-capable will not request a health certificate from a NAP CA.
Client authentication.
If the NAP enforcement point is an HRA server, then client authentication can also be a consideration. For the NAP with 802.1X and VPN enforcement methods, authentication occurs on NPS. Client authentication is not used for the NAP with DHCP enforcement method. HRA uses Internet Information Services (IIS) to authenticate NAP client computers through a Web site that hosts an Internet Server Application Programming Interface (ISAPI) extension to process HTTP/HTTPS requests. If HTTPS is used, then HRA must be configured with a valid Secure Sockets Layer (SSL) certificate. Authentication problems can occur if the client does not use the correct trusted server group settings. For example, if DNS SRV records are configured for automatic HRA discovery, these records must use the fully qualified domain name (FQDN) of the HRA server or SSL authentication will fail.
NPS analysis and reply to the client access request
The following factors affect NPS analysis and reply to NAP client access requests:
RADIUS clients and servers.
If RADIUS clients or remote RADIUS server groups are configured, this can affect the ability of NPS to respond to NAP client access requests. For example, if a RADIUS client is disabled or uses an incorrect shared secret, then NAP client computers that request access from that RADIUS client will be denied network access.
Connection request policy and network policy configuration.
This is perhaps the most important factor for determining whether NAP client computers are granted network access, and what kind of access is granted. The NPS event log provides detailed information about which connection request policy and which network policy is matched when a NAP client computer requests network access. Troubleshooting client access requests requires careful analysis of policy conditions and settings. For example, if noncompliant NAP client computers are denied network access instead of being granted restricted network access, it can be because the noncompliant network policy is configured with a setting of Deny Access instead of Grant Access. It might seem counterintuitive that noncompliant computers are granted network access, but access must be granted so that they can remediate their health and become compliant.
Health policy and SHV configuration.
SHVs define configuration requirements for computers that attempt to connect to your network. Health policies define which SHVs are evaluated, and how they are used in the validation of the configuration of computers that attempt to connect to your network. Based on the results of SHV checks, health policies classify client health status. Health policies and SHVs can affect NAP client access requests in the same way that connection request policies and network policies affect access. For example, if you configure a noncompliant health policy with the Client reported as infected by one or more SHVs antivirus SHV check and the antivirus SHA does not provide infected state information as part of the SoH, then the network access of infected client computers will not be restricted.
Remediation server group and troubleshooting URL configuration.
The remediation server group configuration is used for the NAP with VPN enforcement and the NAP with DHCP enforcement methods. A troubleshooting URL configuration is used with all enforcement methods, and can be customized to the type of noncompliance reported by a client computer. When you use NAP with VPN enforcement, you must configure at least one remediation server group or IP filter in order to restrict network access for noncompliant client computers.
Accounting configuration.
The configuration of NPS accounting can affect client access requests if NPS is unable to contact the accounting server. When you configure an accounting location on another server, NPS will stop processing all access requests if it is unable to contact the accounting server. For this reason, it is typically safer to configure accounting records on the local computer.
Health requirement server configuration.
If you are using an SHV that obtains health requirements from a health requirement server, such as the SHV for System Center Configuration Manager, then approval of NAP client access requests will depend on the configuration of this server. For example, you are using the System Center Configuration Manager SHV and the system health validator point is not operational, the network access of noncompliant NAP client computers will not be restricted.
Application of network access by the NAP enforcement point
The application of network access by NAP enforcement points is affected by the following factors:
Enforcement point configuration.
The NAP enforcement point must be configured to provide full and restricted network access, and to deny network access, if necessary. Requirements are different, depending on the type of enforcement point and the method of network access restriction. For example, if NPS instructs a network access device to apply an access control list (ACL) to noncompliant computers, this ACL must be present on the network access device or network access will not be restricted.
Other services.
If the NAP enforcement point depends on other services to provide network access, then these services can also affect NAP client network access. For example, if HRA is the NAP enforcement point, it must be able to contact a NAP CA to request and issue NAP health certificates.
Client remediation
Client remediation depends on the following:
Remediation server access.
In order for a remediation server to provide updates to noncompliant NAP client computers, the server must be accessible on the restricted network. For example, if a remediation server is located on a subnet different from the subnet of the NAP client computers, you must configure the 003 Router option in the default NAP class with the IP address of a gateway device that can route NAP client DHCP requests to the remediation server. If this option is not present or is incorrect, noncompliant NAP client computers will be unable to remediate their health.
Enforcement point access.
In order for noncompliant NAP client computers to regain full network access after they have remediated their health, they must have access to a NAP enforcement point on the restricted network. For example, if a NAP DHCP server is located on a subnet different from the subnet of the NAP client computers, you must configure the 003 Router option in the default NAP class with the IP address of a gateway device that can route NAP client DHCP requests to the enforcement point. If this option is not present, NAP client computers will be unable to obtain a new IP configuration when they complete the remediation process.
Troubleshooting topics
See the following topics for information about specific types of NAP problems:
See Also
Concepts
Introduction to Troubleshooting NAP
Tools for Troubleshooting NAP