Health Registration Authority

Health Registration Authority (HRA) is a component of a Network Access Protection (NAP) infrastructure that plays a central role in NAP Internet Protocol security (IPsec) enforcement. HRA obtains health certificates on behalf of NAP clients when they are determined to be compliant with network health requirements. These health certificates authenticate NAP clients for IPsec-protected communications with other NAP clients on an intranet. If a NAP client does not have a health certificate, the IPsec peer authentication fails and the NAP client cannot initiate communication with other IPsec-protected computers on the network.

HRA is installed on a computer that is also running Network Policy Server (NPS) and Internet Information Services (IIS). If they are not already installed, these services will be added when you install HRA.

See Also

  • Overview of Health Registration Authority
  • Checklist: Deploy NAP IPsec Enforcement with HRA
  • Configuring HRA
  • Understanding HRA Authentication Requirements
  • Understanding HRA Request Policy
  • Troubleshooting HRA
  • Understanding NAP IPsec Enforcement
  • Configure NAP Certification Authority
  • Configure HRA Cryptographic Policy
  • Configure HRA Transport Policy
  • Verify Certification Authority Configuration
  • Verify NAP Client Configuration
  • Verify NPS Configuration
  • Verify IIS Configuration


Overview of Health Registration Authority

Health Registration Authority (HRA) provides a service for the Network Access Protection (NAP) platform that is commonly referred to as a registration authority in an X.509 public key infrastructure (PKI). As a registration authority, HRA is responsible for validating client credentials and then forwarding a certificate request to a certification authority (CA) on behalf of the client. HRA validates certificate requests by checking with Network Policy Server (NPS) to determine if the NAP client is compliant with network health requirements. If the client is found to be compliant, HRA requests a special type of certificate from the CA called a health certificate. The health certificate is used by NAP client computers to communicate on an IPsec-protected network. In this capacity, HRA functions as a NAP enforcement server for the NAP Internet Protocol security (IPsec) enforcement method.

Important concepts

To understand the role of HRA in a NAP deployment, review the following concepts.

  • Health certificates

    X.509 certificates issued to NAP client computers that are used to provide proof of their compliance with network health requirements. The NAP client computer obtains a health certificate by providing a declaration of its health status, called a statement of health (SoH), to HRA. The NAP client will continuously monitor its health status, and delete the health certificate if it becomes noncompliant. Health certificates can be used to authenticate NAP clients when they initiate IPsec-secured communications with other NAP clients on an intranet. NAP IPsec enforcement limits communication for IPsec-based NAP clients by dropping incoming communication attempts that are sent from computers that do not have health certificates.

  • NAP certification authorities

    Servers running Active Directory® Certificate Services (AD CS) that host X.509 certificates and issue them to NAP clients when they are determined to be compliant with network health requirements. You must specify one or more CAs that will issue NAP health certificates. For more information, see Configure NAP Certification Authority and Verify Certification Authority Configuration.

  • HRA request policy

    Settings that determine how clients are allowed to communicate with HRA when requesting health certificates. You can customize HRA request policy by customizing cryptographic policy and transport policy settings. You do not need to modify HRA request policy settings. The default settings are recommended. If you choose to change these settings, it is important to configure identical settings on both HRA servers and NAP client computers. For more information, see Understanding HRA Request Policy, Configure HRA Cryptographic Policy, and Configure HRA Transport Policy.

  • Internet Information Services (IIS)

    A set of Internet-based services that is installed automatically when you install HRA. The IIS service provides an HTTP/HTTPS interface for NAP clients to contact the HRA server and request health certificates. It processes these requests using an Internet Server Application Programming Interface (ISAPI) extension that can be provided to anonymous users or restricted to users who have been authenticated to the domain. For more information, see Understanding HRA Authentication Requirements and Verify IIS Configuration.

  • Network Policy Server (NPS)

    The Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy. If your server is not already running NPS, it is automatically installed when you install HRA. You can configure NPS on your HRA server as either a NAP health policy server or NPS proxy. When you configure NPS as a NAP health policy server, you must also configure NAP policies and settings, including:

    • Connection request policies: Sets of conditions and settings that validate requests for network access and specify where this validation is performed.

    • Network policies: Sets of conditions, constraints, and settings that allow you to designate who can connect to the network.

    • Health policies: System health requirements that define which SHVs are used in validating the configuration of computers that attempt to connect to your network.

    • System health validators (SHVs): A NAP health policy server software counterpart to a system health agent (SHA). SHVs define configuration requirements for computers that attempt to connect to your network.

When you configure NPS as a RADIUS proxy, you must verify network connectivity to remote RADIUS server groups and validate their configuration as NAP health policy servers. For more information, see Verify NPS Configuration.

See Also

  • Checklist: Deploy NAP IPsec Enforcement with HRA
  • Configuring HRA
  • Troubleshooting HRA
  • Understanding NAP IPsec Enforcement


Checklist: Deploy NAP IPsec Enforcement with HRA

Step | Reference
Configure a certification authority (CA) to issue health certificates. | Verify Certification Authority Configuration
Select authentication requirements and install Health Registration Authority (HRA). | Understanding HRA Authentication Requirements
Configure Network Access Protection (NAP) health policy server and Network Policy Server (NPS) proxy (if applicable) on NPS. | Verify NPS Configuration
Configure certification authorities in HRA. | Configure NAP Certification Authority
Configure NAP-capable clients for Internet Protocol security (IPsec) NAP enforcement. | Verify NAP Client Configuration
Use IPsec policies to create logical networks. | Understanding NAP IPsec Enforcement

See Also

  • Troubleshooting HRA


Configuring HRA

Available options for configuring Health Registration Authority (HRA) include:

  • Authentication requirements

    Configured by using the Add Roles Wizard during the installation of the HRA role service. For more information, see Understanding HRA Authentication Requirements.

  • Certification authorities (CAs)

    Configured during installation of HRA, or later using either the HRA snap-in or netsh nap hra context commands. At least one CA must be configured in order for HRA to obtain health certificates on behalf of Network Access Protection (NAP) clients. For more information, see Configure NAP Certification Authority.

  • Request policy

    Configured after installation of HRA by using the HRA snap-in or the command line. You do not have to modify default HRA request policy settings. For more information, see Understanding HRA Request Policy.

See Also

  • Configure HRA Cryptographic Policy
  • Configure HRA Transport Policy


Understanding HRA Authentication Requirements

During the installation of Health Registration Authority (HRA), you are given the option to configure HRA to provide health certificates only when users are authenticated to the domain, or to optionally provide health certificates to anonymous users. If you choose to allow anonymous requests for health certificates, two Web sites will be created:

  • DomainHRA

    Internet Information Services (IIS) authentication settings on this site have Windows authentication enabled. All other authentication methods are disabled.

  • NonDomainHRA

    IIS authentication settings on this site have Anonymous authentication enabled. All other authentication methods are disabled.

If you choose to require that only authenticated members of the domain are granted the ability to receive health certificates, then only the DomainHRA Web site is created.

These Web sites host an IIS Internet Server Application Programming Interface (ISAPI) extension that processes HTTP/HTTPS requests, evaluates health using Network Policy Server (NPS), and issues health certificates using a certification authority (CA).

Important

If anonymous certificate requests are allowed, you should configure trusted server groups on NAP clients so that authenticated certificate requests are given a higher priority in the ordered list of URLs than anonymous certificate requests. This will help to ensure that domain-joined clients that pass health checks are not issued anonymous health certificates.

Certificates for SSL encryption

IIS can use Secure Sockets Layer (SSL) to encrypt communications with NAP client computers. If you enable SSL, remote clients must access your site by using URLs that start with https://, and your IIS server must be provisioned with a SSL certificate. Requirements for this SSL certificate are:

  • The certificate must be in either the local computer certificate store or the current user certificate store.

  • The current system time must be after the Valid from property of the certificate and before the Valid to property of the certificate.

  • The certificate must be meant for server authentication. This requires the Enhanced Key Usage property of the certificate to specify Server Authentication (1.3.6.1.5.5.7.3.1).

If you import an existing certificate for use with SSL encryption during installation of the HRA role service, it is automatically added to the local computer certificate store. You can also create a self-signed certificate or install a certificate for SSL encryption later.

See Also

  • Overview of Health Registration Authority
  • Configuring HRA
  • Verify IIS Configuration


Understanding HRA Request Policy

You can use the Health Registration Authority (HRA) snap-in to specify the security mechanisms that the HRA server uses to communicate with client computers. These settings, known as request policy settings, determine which asymmetric key algorithm, hash algorithm, and cryptographic service provider (CSP) the HRA server uses to encrypt communication with client computers. If you specify request policy settings using the HRA snap-in, the HRA server will use only these security mechanisms to communicate with client computers.

Important

You do not need to configure request policy settings on your HRA server. By default, a NAP-capable client computer initiates a negotiation process with a HRA server using a mutually acceptable default security mechanism for encrypting communication. You should not modify request policy settings unless you have thoroughly tested your request policy settings in a secure test environment.

If you configure request policy settings on your HRA server, you must configure identical request policy settings on your client computers. If your HRA servers are not configured to use exactly the same asymmetric key algorithm, hash algorithm, and CSP as your client computers, then your HRA servers will not be able to communicate with client computers. The client computers might be determined to be noncompliant, which will result in limited network connectivity.

Cryptographic policy

You can configure HRA server request policy settings by specifying custom cryptographic policy. Cryptographic policy settings specify asymmetric key algorithms, hash key algorithms, and cryptographic service providers. For more information, see Configure HRA Cryptographic Policy.

Asymmetric key algorithms

Asymmetric key algorithms are also known as public key algorithms. Asymmetric algorithms are used to generate the asymmetric keys that are associated with client health certificate requests. Default settings allow any available algorithm to be accepted in communication between the HRA server and client computers. You can use the HRA snap-in to specify which algorithms in the list are allowed, and you can modify the minimum and maximum key lengths for these algorithms.

Hash key algorithms

Hash algorithms are also known as secure hash algorithms or hash functions. Hash algorithms are designed to perform a one-way operation on data, providing a unique output value that can be used for verification, but cannot be used to re-create the original data. Default settings support the use of any hash algorithm. You can use the HRA snap-in to specify which algorithms in the list are allowed.

Cryptographic service providers

Cryptographic service providers are hardware and software components of Windows operating systems that provide generic cryptographic functions. Each of the CSPs configured for use by HRA can support different algorithms, formats, and keys used for encryption and decryption. Default settings support the use of any CSP. You can use the HRA snap-in to specify which CSPs in the list are used.

Transport policy

You can configure HRA server request policy settings by specifying custom transport policy. Transport policy settings specify HTTP client user agents. For more information, see Configure HRA Transport Policy.

HTTP client user agents

HTTP client user agents are strings that specify the identity of HTTP/HTTPS client applications used to request health certificates from HRA. Any agent is allowed by default. You can use the HRA snap-in to specify the allowed user agents.

See Also

  • Troubleshooting HRA
  • Verify NAP Client Configuration


Configure NAP Certification Authority

Health Registration Authority (HRA) must be configured with at least one certification authority (CA) from which to request health certificates on behalf of client computers. Certificates are requested when new clients connect to the network or when the health certificate validity period is about to expire on a compliant client computer. Certificates can also be removed and reissued to client computers if their health state changes while they are connected to the network. HRA will only request health certificates from the CA configured first in the order, unless that server is unavailable or has been identified as unresponsive.

Configure CAs

Use this procedure to configure CAs in HRA. CAs can be added or deleted, and their order can be modified. You can also specify the number of minutes to wait between requests before identifying a CA as unavailable. If you are using an enterprise CA, you can select the authenticated and anonymous certificate templates to use. If you are using a standalone CA with Network Access Control, you can enable client extended state information by enabling policyOIDs.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Add a new CA

For optimal performance, a dedicated standalone subordinate CA should be used to issue health certificates. Fault tolerance is provided when you configure more than one CA in the HRA snap-in. Load balancing can be achieved by configuring an additional HRA with a different CA processing order. You can use the following procedure to configure CAs for use with HRA.

To add a new certification authority using the Windows interface

  1. Open the HRA console.

  2. In the console tree, right-click Certification Authority, and then click Add Certification Authority. The Add Certification Authority dialog box opens.

  3. Click Browse. The Select Certification Authority dialog box opens.

  4. Under CA, click the name of the CA that will be used to issue NAP health certificates, and then click OK twice.

  5. In the HRA console tree, click Certification Authority, and verify the name and order of configured CAs.

    Note

    You cannot browse to a CA from a workgroup environment.

Configure CA wait time

HRA will only attempt to obtain health certificates from the CA that is configured first in the processing order, unless that CA has been marked as unavailable. You can use the following procedure to change the number of minutes to wait before identifying a CA as unavailable.

To configure certification authority wait time using the Windows interface

  1. Open the HRA console.

  2. In the console tree, right-click Certification Authority, and then click Properties. The Certification Authorities Properties dialog box opens.

  3. Enter the number of minutes to wait between requests before identifying a CA as unavailable, and then click OK.

Configure health certificate validity period

The default validity period for health certificates is 4 hours. Clients will attempt to renew a health certificate 15 minutes prior to expiration or when a change in client health status occurs. You can use the following procedure to configure a custom validity period for health certificates.

To configure the validity time for health certificates approved by HRA using the Windows interface

  1. Open the HRA console.

  2. In the console tree, right-click Certification Authority, and then click Properties. The Certification Authorities Properties dialog box opens.

  3. Select the unit of time using the available drop-down list box. You can select Minutes, Hours, Days, or Weeks.

  4. After choosing a unit of time, enter the number of units desired, and then click OK.

  5. If you are using an enterprise CA, you must perform the following steps in order to override the validity period that is configured in your certificate templates.

    1. Click Start, right-click Command Prompt, and then click Run as administrator.

    2. In the command window, type Certutil.exe -setreg policy\EditFlags +EDITF_ATTRIBUTEENDDATE, and then press ENTER.

    3. In the command window, type net stop certsvc && net start certsvc, and then press ENTER.

    4. Verify that Active Directory® Certificate Services (AD CS) stops and starts successfully.
Important

The maximum health certificate validity period is determined by the CA validity period, which is set by default to 52 weeks. Use caution when configuring a validity period of less than 1 hour due to potential performance issues with the CA server. Do not use a validity period of 15 minutes or less.

Choose CA type

Use the following procedure to configure the NAP certification authority type. It is important to choose a CA type that corresponds to the CA that you configured in the preceding procedure. If you are using an enterprise CA, you must configure templates prior to performing this procedure.

To choose the certification authority type using the Windows interface

  1. Open the HRA console.

  2. In the console tree, right-click Certification Authority, and then click Properties. The Certification Authorities Properties dialog box opens.

  3. If you are using a standalone CA, choose Use standalone certification authority.

  4. Do not select the check box next to Enable PolicyOIDs unless you are using client extended state information for Network Access Control.

  5. If you are using an Active Directory-integrated enterprise CA, or you are using both enterprise and standalone CAs, choose Use enterprise certification authority, and then use the drop-down list to select an Authenticated compliant certificate template and Anonymous complaint certificate template from the list of available templates. If you did not choose to allow anonymous requests for health certificates during the installation of HRA, then configuring an anonymous template in this procedure does not enable anonymous certificate requests.

Configure order or delete CAs

Use the following procedure to modify the priority of CAs used by HRA, or to remove CAs from the HRA configuration. HRA will only request certificates from the first CA configured in the list, unless that CA has been marked as unavailable.

To configure the order or to delete certification authorities using the Windows interface

  1. Open the HRA console.

  2. In the console tree, click Certification Authorities.

  3. Right-click a CA name in the list of servers. Click Move Up to increase preference for this server in the order. Alternatively, click Move Down to decrease preference for this server in the order.

  4. To delete a CA from the list, right-click the CA name, and then click Delete.

See Also

  • Verify Certification Authority Configuration


Configure HRA Cryptographic Policy

Use this procedure to configure cryptographic policy in Health Registration Authority (HRA). You can configure cryptographic policy by specifying supported asymmetric algorithms, hash algorithms, and cryptographic service providers (CSPs).

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To configure cryptographic policy using the Windows interface

  1. Open the HRA console.

  2. In the console tree, double-click Request Policy, and then click Cryptographic Policy. Asymmetric Keys Algorithms, Hash Keys Algorithms, and Cryptographic Service Providers are displayed in the details pane.

  3. To specify asymmetric key algorithms, right-click Asymmetric Keys Algorithms, and select Properties. The default selection is Any algorithm. To configure a specific asymmetric algorithm, select Specific algorithms, and then select the check box next to the desired algorithms in the list. To edit the minimum and maximum key length for an algorithm, select the name of the algorithm from the list, and then click Edit. Enter the desired minimum and maximum key lengths, and then click OK. When you are finished selecting algorithms, click OK.

  4. To specify hash key algorithms, right-click Hash Keys Algorithms, and select Properties. The default selection is Any algorithm. To configure specific algorithms, select Specific algorithms, select the check box next to the desired algorithms in the list, and then click OK.

  5. To specify cryptographic service providers, right-click Cryptographic Service Providers, and select Properties. The default selection is Any provider. To configure specific providers, select Specific provider, select the check box next to the desired providers in the list, and then click OK.

Additional considerations

  • If you configure request policy settings on your HRA servers, you must configure identical request policy settings on your client computers. If your HRA servers are not configured to use exactly the same asymmetric key algorithm, hash key algorithm, and cryptographic service provider as your client computers, then your client computers will not be able to communicate with your HRA servers. Your client computers could be deemed noncompliant, which will result in limited network access.

See Also

  • Understanding HRA Request Policy


Configure HRA Transport Policy

Use this procedure to configure transport policy in Health Registration Authority (HRA). You can configure transport policy by specifying supported HTTP client user agents. By default, any HTTP client user agent is allowed.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To configure transport policy using the Windows interface

  1. Open the HRA console.

  2. In the console tree, double-click Request Policy, and then click Transport Policy.

  3. In the details pane, right-click HTTP Client User Agents, and then click Properties.

  4. The default setting of Any agent is selected. This setting allows the use of any HTTP user agent.

  5. To specify a HTTP user agent, select Specific agent, enter the HTTP agent string, and then click Add. The HTTP agent string will appear in the list of Currently allowed agents.

  6. To modify or remove items in the Currently allowed agents list, click the name of the agent, and then click Edit or Remove.

  7. Click OK to close the HTTP Client User Agent Properties dialog box.

See Also

  • Understanding HRA Request Policy


Troubleshooting HRA

Deploying Network Access Protection (NAP) Internet Protocol security (IPsec) enforcement with Health Registration Authority (HRA) requires NAP infrastructure services and components in addition to HRA.

  • NAP-capable client computers

    NAP agent, the IPsec enforcement client, and one or more system health agents must be configured and running on your client computers in order for these clients to be NAP-capable. For more information, see Verify NAP Client Configuration.

  • Certification authority (CA)

    CA must be configured to provide health certificates to HRA that can be issued to compliant NAP client computers. For more information, see Verify Certification Authority Configuration.

  • Network Policy Server (NPS)

    NPS must be configured on your HRA server as either an NPS proxy or NAP health policy server. Several NAP-related policies and components must also be configured on the NAP health policy server, including connection request policies, health policies, network policies, and system health validators (SHVs). For more information, see Verify NPS Configuration.

  • Internet Information Services (IIS)

    IIS must be running on your HRA server to provide an HTTP/HTTPS interface that clients can use to request health certificates. For more information, see Verify IIS Configuration.

Each of these infrastructure components must be available and correctly configured in order for HRA to obtain and issue health certificates to compliant NAP client computers. Problems with one or more of these components can disable NAP functionality, resulting in NAP clients being unable to acquire a health certificate even when they are compliant with network health requirements.

See Also

  • Understanding NAP IPsec Enforcement


Understanding NAP IPsec Enforcement

Network Access Protection (NAP) Internet Protocol security (IPsec) enforcement provides the strongest and most flexible method for maintaining client computer compliance with network health requirements.

IPsec enforcement confines the communication on your network to those computers that are considered compliant and have acquired health certificates. By leveraging IPsec and its configuration flexibility, this NAP enforcement method allows to you to define requirements for secure communications with compliant clients on a per-IP address or port number basis. For more information about IPsec, see http://go.microsoft.com/fwlink/?LinkId=50170.

Benefits of IPsec enforcement

IPsec enforcement is commonly used when you want a stronger and more robust enforcement mechanism than 802.1X, DHCP, or VPN enforcement provide. Benefits of IPsec enforcement are the following:

Tamper-resistant enforcement

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 by manipulating settings on the local computer, even if a user has 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 Internet layer of the TCP/IP protocol suite and is therefore independent of physical network infrastructure components, such as hubs, switches, and routers.

Flexible limitations on network access

With IPsec enforcement, 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-server or per-application basis.

Optional end-to-end encryption

By specifying IPsec policy settings, you can encrypt IP traffic between IPsec peers for highly sensitive traffic. Unlike IEEE 802.11 wireless local area networks (LANs), which only encrypt frames from the wireless client to the wireless access point, IPsec encryption is between IPsec peer computers.

IPsec enforcement and logical networks

IPsec enforcement divides a physical network into three logical networks. A computer is a member of only one logical network at any time. The logical networks are defined in terms of which computers have health certificates and which computers require IPsec authentication for incoming communication attempts. Logical networks allow you to limit access of computers that do not meet health requirements and provide compliant computers with a level of protection from noncompliant computers. IPsec enforcement defines the following logical networks:

  • Secure network

    Computers on the secure network have health certificates and require that incoming communication attempts authenticate with these certificates. They use a common set of IPsec policy settings for providing IPsec protection. For example, most server and client computers that are members of an Active Directory® infrastructure would be in a secure network. NAP health policy servers, servers running Active Directory Certificate Services (AD CS), and e-mail servers are examples of network components that normally reside in a secure network.

  • Boundary network

    Computers on the boundary network have health certificates, but do not require IPsec authentication of incoming communication attempts. Computers in the boundary network must be accessible to computers on the entire network. These types of computers are the servers required to assess and remediate NAP client health or otherwise provide network services for computers in the restricted network, such as HRA servers, antivirus update servers, read-only domain controllers, and DNS servers. Because computers in the boundary network do not require authentication and protected communication, they must be closely managed to prevent them from being used to attack computers in the secure network.

  • Restricted network

    Computers on the restricted network do not have health certificates. These are computers that have not completed health checks, are guests, or are NAP-ineligible computers, such as computers running versions of Windows that do not support NAP, Apple Macintosh computers, or UNIX-based computers.

The following figure shows an example of IPsec logical networks.

See Also

  • Overview of Health Registration Authority


Verify NAP Client Configuration

Use this procedure to verify that NAP-capable client computers are configured for the Network Access Protection (NAP) Internet Protocol security (IPsec) enforcement method. A NAP-capable computer is one that has the NAP components installed and can verify its health state by sending statements of health (SoHs) to Network Policy Server (NPS) for evaluation. For more information about NAP, see http://go.microsoft.com/fwlink/?LinkId=94393.

Note

These procedures only apply to NAP client computers running Windows Vista®. Other NAP-capable client computers, such as those running Windows® XP with Service Pack 3, require that NAP client configuration be verified using the command line.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Verify NAP client components

NAP components include the NAP agent service, one or more NAP enforcement clients, and at least one system health agent (SHA). Other services can also be required if they support an installed SHA. All of these components work together to continuously monitor the health status of a NAP client computer and provide this status to NAP servers for evaluation.

NAP agent

The NAP agent service collects and manages health information on the client computer. NAP agent also processes SoHs from all installed SHAs and reports client health to enforcement clients. NAP agent must be operational to enable client computers to request or receive health certificates.

To verify NAP agent

  1. Click Start, click Control Panel, click System and Maintenance, click Administrative Tools, and then double-click Services.

  2. In the list of services, under Name, double-click Network Access Protection Agent.

  3. Verify that the Service status is Started, and Startup type is set to Automatic.

  4. If the service is not started, choose Automatic next to Startup type, and then click Start below Service status.

  5. Click OK to close the Network Access Protection Properties dialog box.

  6. Close the Services console.
Note

Restarting the NAP agent service will automatically reinitialize SHAs and attempt to acquire a new health certificate. This can be useful when troubleshooting NAP.

NAP IPsec enforcement client

The NAP IPsec enforcement client must be installed and enabled on client computers. The NAP enforcement client requests access to a network, and communicates a client computer's health status to other components of the NAP client architecture. The NAP IPsec enforcement client restricts access to IPsec-protected networks by interacting with the certificate store on a client computer.

To verify the NAP IPsec enforcement client

  1. Click Start, point to All Programs, click Accessories, and then click Run.

  2. Type napclcfg.msc, and press ENTER.

  3. In the console tree, click Enforcement Clients, and verify the status of IPSec Relying Party as Enabled.

  4. If the status is Disabled, right-click IPSec Relying Party in the details pane, and then click Enable.

  5. Close the NAP Client Configuration console.

Other services

Installed SHAs might depend on other services to provide client health status. For example, the Windows System Health Agent (WSHA) that is included with Windows Vista and Windows XP with Service Pack 3 requires that Security Center is enabled and running in order to monitor and report client health status. Security Center is disabled by default in a domain environment. Use the following procedure to automatically enable Security Center in a domain environment.

To automatically enable Security Center in a domain environment

  1. Click Start, point to All Programs, click Accessories, and then click Run.

  2. Type gpedit.msc, and then press ENTER.

  3. In the Local Group Policy Object Editor console tree, open Local Computer Policy/Computer Configuration/Administrative Templates/Windows Components/Security Center.

  4. In the details pane, double-click Turn on Security Center (Domain PCs only), click Enabled, and then click OK.

  5. Close the Local Group Policy Object Editor console.

Verify IPsec client configuration

NAP clients must be configured with settings that allow them to communicate with NAP server components. You can configure these settings by using Group Policy, the NAP Client Configuration console, or the command line. For the IPsec enforcement method, NAP client settings include Request Policy and Trusted Server Groups.

Request policy

You do not need to modify the default request policy settings on NAP client computers. If these settings are changed, then it is important to verify that similar settings are enabled on your NAP servers. By default, a NAP-capable client computer initiates a negotiation process with a NAP server using a mutually acceptable default security mechanism for encrypting communication. It is recommended that you use the default request policy settings.

To verify request policy settings

  1. Click Start, point to All Programs, click Accessories, and then click Run.

  2. Type napclcfg.msc, and press ENTER.

  3. In the console tree, double-click Health Registration Settings, and then click Request Policy.

  4. In the details pane, click Hash Algorithm.

  5. Verify that the Chosen Setting corresponds to the default setting of sha1RSA or that the configured setting matches the hash algorithm used on your Health Registration Authority (HRA) servers.

  6. In the details pane, click Cryptographic Service Provider.

  7. Verify that the Chosen Setting corresponds to the default setting of Microsoft RSA SChannel Cryptographic Provider with a Key Length of 2048. Verify that these settings match those configured on your HRA servers.

  8. Close the NAP Client Configuration console.

Trusted server groups

Trusted server groups are configured within client health registration settings so that NAP client computers can contact Web sites that are used by HRA to process health certificate requests. If trusted server groups are not configured or are configured incorrectly, NAP client computers will fail to acquire health certificates.

To verify trusted server groups

  1. Click Start, click All Programs, click Accessories, and then click Run.

  2. Type napclcfg.msc, and press ENTER.

  3. In the console tree, double-click Health Registration Settings, and then click Trusted Server Groups.

  4. In the details pane, click the name of each trusted server group in the list to view the URLs in Available URLs. Confirm that these URLs correspond to Web sites on your HRA servers that are used to process health certificate requests.

  5. Double-click the name of a trusted server group to modify properties or change the order of URLs.
Note

A NAP client computer will attempt to obtain a health certificate from the first URL in all configured trusted server groups unless that server has been marked as unavailable. For more information, see Verify IIS Configuration and Understanding HRA Authentication Requirements.

Review NAP client events

Reviewing information contained in NAP client events can assist you with troubleshooting. It can also help you to understand NAP client functionality.

To review NAP client events in Event Viewer

  1. Click Start, point to All Programs, click Accessories, and then click Run.

  2. Type eventvwr.msc, and press ENTER.

  3. In the left tree, navigate to Event Viewer(Local)\Applications and Services Logs\Microsoft\Windows\Network Access Protection\Operational.

  4. Click an event in the middle pane.

  5. By default, the General tab is displayed. Click the Details tab to view additional information.

  6. You can also right-click an event and then click Event Properties to open a new window for reviewing events.

See Also

  • Troubleshooting HRA


Verify Certification Authority Configuration

Use the following procedures on your NAP certification authorities (CAs) to verify that these servers are correctly configured for use with Health Registration Authority (HRA) and the NAP IPsec enforcement method. NAP CAs are servers that have Active Directory® Certificate Services (AD CS) installed and running, and are capable of issuing NAP health certificates. For more information about AD CS, see http://go.microsoft.com/fwlink/?LinkId=94390.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Choosing a NAP certification authority

HRA must be associated with at least one CA in order to obtain and issue NAP health certificates to compliant NAP client computers. You can select a CA during the installation of HRA by choosing to install the CA locally or by selecting an existing remote CA. You can also add NAP CAs later using the HRA snap-in or a command line. You must use the HRA snap-in or a command line in order to associate more than one CA with HRA. You can configure HRA to use either an enterprise CA or standalone CA. Configuration requirements for a NAP CA differ depending on the type of CA that you choose. You must configure CA security settings and certificate issuance requirements whether you choose a standalone or enterprise CA. In its recommended configuration, HRA is associated with a dedicated standalone subordinate CA. For more information about configuring HRA to use a NAP CA, see Configure NAP Certification Authority.

Choosing a standalone certification authority

A standalone CA does not use certificate templates. Therefore, you do not need to configure a health certificate template when you use a standalone NAP CA. If you choose a standalone CA, you must still configure CA security settings and certificate issuance requirements so that HRA can request and automatically issue health certificates to compliant client computers.

Choosing an enterprise certification authority

An enterprise CA issues certificates based on certificate templates. The policy module is used to provide a list of certificate extensions to the issued certificates, such as system health authentication for NAP. If your enterprise CA is running Windows Server® 2008, then the System Health Authentication certificate template is available by default with application policy extensions suitable for domain and health authentication. If your enterprise CA is running Windows Server® 2003, then you must create and publish a template containing these application policy extensions. You can use the following procedures to verify that enterprise CAs are configured to automatically issue health certificates with the correct application policy extensions.

Verify template availability

If your enterprise CA server is running Windows Server 2008, a certificate template for domain authenticated NAP clients is automatically available with a display name of System Health Authentication. If your enterprise CA is running Windows Server 2003, this template must be created. Use the following procedure to verify that a NAP health certificate template is available with the correct application policy extensions, or create this template if it is not available. This procedure does not apply if you are using a standalone CA.

To verify template availability

  1. Click Start, click Run, type certtmpl.msc, and then press ENTER.

  2. In the details pane, under Template Display Name, review the list of templates. Double-click the name of your NAP health certificate template. If a NAP health certificate template is not listed, perform the following steps:

    1. Right-click Workstation Authentication, and then click Duplicate Template.

    2. Under Template display name, type System Health Authentication, and then click the Extensions tab.

    3. Under Extensions included in this template, click Application Policies, and then click Edit.

    4. Click Add, and then click New.

    5. In New Application Policy, under Name, type System Health Authentication.

    6. Under Object identifier, type 1.3.6.1.4.1.311.47.1.1, and then click OK four times.

    7. Confirm that your new template was created successfully.

    8. To verify your new template, double-click its name and complete the remaining steps in this procedure.

  3. Click the Extensions tab.

  4. Under Extensions included in this template, click Application Policies.

  5. Under Description of Application Policies, verify that System Health Authentication and Client Authentication are listed, and then click Edit.

  6. Click System Health Authentication, and then click Edit.

  7. In Edit Application Policy, under Object identifier, verify the value is 1.3.6.1.4.1.311.47.1.1. If the value of the application policy object identifier is different, then use the previous steps in this procedure to create a new system health authentication template. You should also correct application policy names so that the object identifier associated with System Health Authentication is 1.3.6.1.4.1.311.47.1.1.

  8. Click Cancel three times, and then close the Certificate Templates console.
Note

If this certificate template is used to issue anonymous health certificates, do not include the Client Authentication application policy. Certificates containing the client authentication application policy are issued to clients that authenticate with domain credentials.

Verify certificate availability

On an enterprise CA, certificates must be made available before they can be issued to client computers. Use the following procedure to ensure that your NAP health certificate is available to be issued. This procedure does not apply if you are using a standalone CA.

To verify certificate availability

  1. Click Start, click Run, type certsvr.msc, and then press ENTER.

  2. In the console tree, click Certificate Templates.

  3. In the details pane, under Name, verify that your NAP health certificate is listed. If your enterprise CA server is running Windows Server 2008, the default health certificate template for domain authenticated NAP clients has a display name of System Health Authentication.

  4. If the health certificate template has been created, but is not displayed in the list, use the following steps to issue the template:

    1. Right-click Certificate Templates, point to New, and then click Certificate Template to Issue.

    2. In Enable Certificate Templates, under Name, click the name of your NAP health certificate, and then click OK. If the template is not listed, then it has already been enabled, or it must be created before performing this procedure.

    3. Verify that your NAP health certificate template is added to the list of templates.

  5. Close the Certification Authority console.

Verify certificate enrollment permissions for HRA

In order for HRA to obtain certificates from an enterprise CA and issue these to clients, it must be granted permission to enroll the health certificate. Enabling autoenroll permission allows HRA to automatically add this certificate to its local certificate store. If only enroll permission are allowed, you must manually provision a health certificate on the HRA server. Use the following procedure to verify that HRA has been granted these permissions. This procedure does not apply if you are using a standalone CA.

To verify certificate enrollment permissions for HRA

  1. Click Start, click Run, type certtmpl.msc, and then press ENTER.

  2. In the details pane, under Template Display Name, double-click the name of your NAP health certificate. If your enterprise CA server is running Windows Server 2008, the default health certificate template for domain authenticated NAP clients has a display name of System Health Authentication.

  3. Click the Security tab.

  4. Verify that Enroll and Autoenroll permissions have been granted to the DNS name of your HRA server, or to a group of which the HRA server is a member. If these permissions are not allowed, perform the following steps:

    1. Click Add, click Object Types, select the Computers check box, and then click OK.

    2. Type the DNS name of your HRA server under Enter the object names to select, and then click OK. Alternatively, you can type the name of a group of which the HRA server is a member.

    3. Click the name or group you added, select Allow permissions for Enroll and Autoenroll, and then click OK.

  5. Close the Certificate Templates console.

Verify certification authority security settings

CA security settings determine whether HRA has sufficient permissions to issue health certificates. Use the following procedure to verify these permissions on your NAP certification authorities. This procedure applies to both enterprise and standalone CA servers.

To verify certificate security settings

  1. Click Start, click Run, type certsrv.msc, and then press ENTER.

  2. Right-click the common name for your CA, and then click Properties.

  3. Click the Security tab.

  4. If your HRA and NAP CA are running on the same computer, verify that NETWORK SERVICE is found in the list under Group or user names.

  5. If your HRA and NAP CA are running on different computers, verify that the computer name for your HRA server is found in the list under Group or user names.

  6. Click the name of your HRA server, or click NETWORK SERVICE, and verify that permissions are allowed to Issue and Manage Certificates, Manage CA, and Request Certificates.

  7. Click OK, and then close the Certification Authority console.

Verify certificate issuance requirements

In order for NAP client computers to acquire health certificates immediately when they are determined to be compliant with network health requirements, NAP CAs must be configured to issue health certificates automatically. Use the following procedure to verify that certificates are issued automatically. This procedure applies to both enterprise and standalone CA servers.

To verify certificate issuance requirements

  1. Click Start, click Run, type certsrv.msc, and then press ENTER.

  2. Right-click the common name of your CA, and then click Properties.

  3. Click the Policy Module tab, and then click Properties.

  4. Verify that Follow the settings in the certificate template is selected.

  5. Click OK twice, and then close the Certification Authority console.

See Also

  • Troubleshooting HRA
  • Configure NAP Certification Authority


Verify NPS Configuration

Network Policy Server (NPS) is the central server used with all Network Access Protection (NAP) enforcement methods to evaluate NAP client access requests. Network health requirements are defined on NPS using policies that grant or restrict access of NAP client computers based on their health. A server running NPS that hosts these NAP policies is called a NAP health policy server. Depending on your deployment, you may have one or more NAP health policies servers on your network. Conditions and settings used by a NAP health policy server to define and enforce network health requirements include: RADIUS clients, connection request policies, network policies, health policies, and system health validators (SHVs).

When you install Health Registration Authority (HRA), NPS is installed on the same computer automatically. If you have deployed more than one HRA, and prefer to centralize policy evaluation by placing your NAP health policies on another computer, you must configure the local NPS server as a RADIUS proxy. When you use NPS as a RADIUS proxy, connection request policy is configured to tell the local NPS server to forward network access requests to remote RADIUS server groups for evaluation.

For more information about NPS, see http://go.microsoft.com/fwlink/?LinkId=94389.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Verify NAP health policy server configuration

Use the following procedures as a general guide for verifying the configuration of the local NPS as a NAP health policy server. If the local HRA server is configured as a RADIUS proxy, see Verify NPS proxy configuration.

RADIUS clients

If you have configured remote HRA servers as RADIUS proxies to forward connection requests to the local NPS for evaluation, then the local NPS must have a corresponding RADIUS client entry for each remote HRA server. NAP with IPsec enforcement does not require RADIUS clients if all HRA servers are also NAP health policy servers. If you are using HRA servers on your network that have NPS configured as a RADIUS proxy, use the following procedure to verify that RADIUS clients are configured correctly on the local NPS server so that it can process client connection requests received by remote HRA servers.

To verify RADIUS clients

  1. Click Start, click Run, type nps.msc, and then press ENTER.

  2. In the NPS console tree, double-click RADIUS Clients and Servers, and then click RADIUS Clients.

  3. In the details pane, double-click the friendly name of a RADIUS client corresponding to an HRA server on your network with NPS installed and configured as a RADIUS proxy. If no RADIUS client entry is present, use the following procedure to create a new RADIUS client. This procedure applies only if you have remote HRA servers configured to forward connection requests to the local NPS.

    1. Right-click RADIUS Clients, and then click New RADIUS Client.

    2. Under Friendly name, type a name for the RADIUS client, for example HRA-1.

    3. Under Address (IP or DNS) enter the IP address or DNS name of the remote HRA server, click Verify, and then click Resolve.

    4. Confirm that the IP address displayed corresponds to the correct remote HRA server, and then click OK.

    5. Under Shared secret and Confirm shared secret, type the secret that is configured in remote RADIUS server group settings on the remote HRA server.

    6. If the remote HRA server has enabled the message authenticator attribute in its remote RADIUS server group configuration settings, then select the Access-Request messages must contain the Message-Authenticator attribute check box. If this option is not enabled on the remote HRA, then verify that this check box is cleared.

    7. Select the RADIUS client is NAP-capable check box, and then click OK.

    8. Resume the current procedure to validate configuration of the new RADIUS client.

  4. In the Properties window, verify that the Enable this RADIUS client check box is selected.

  5. Verify that the RADIUS client is NAP-capable check box is selected.

  6. If the remote HRA server is configured to require that access requests contain the message authenticator attribute, then verify that the Access-Request messages must contain the Message-Authenticator attribute check box is selected. Otherwise, verify that this check box is cleared.

  7. Next to Vendor name, verify that RADIUS Standard is selected.

  8. Under Address (IP or DNS), confirm that the DNS name or IP address listed corresponds to the correct remote HRA server, and then click Verify.

  9. In the Verify Client dialog box, click Resolve.

  10. Under IP address, confirm that the IP address listed corresponds to an HRA server that has been configured to forward requests to the local NPS, and that the local NPS has network connectivity to this IP address.

  11. Click OK. If a shared secret mismatch is suspected, type the secret next to Shared Secret and Confirm shared secret, and then click OK.

  12. Repeat this procedure for each HRA on your network that is configured to forward connection requests to the local NPS for processing.

Connection request policies

Connection request policies are conditions and settings that validate requests for network access and govern where this validation is performed. Use the following procedure to confirm that connection request policy on the local NPS is configured for NAP IPsec enforcement.

To verify connection request policies

  1. In the NPS console tree, double-click Policies, and then click Connection Request Policies.

  2. In the details pane, double-click the connection request policy that is used to authenticate incoming network access requests from IPsec-protected NAP clients. If this policy is not present, perform the following steps to create a connection request policy.

    1. Right-click Connection Request Policies, and the click New.

    2. Under Policy Name, type a name for the connection request policy, for example: NAP IPsec with HRA.

    3. Under Type of network access server, select Health Registration Authority, and then click Next.

    4. Connection request policy requires that at least one condition be specified. A condition will be added that does not deny any incoming access requests. To add this condition, click Add on the Specify Conditions page.

    5. In the Select condition window, click Day and Time Restrictions, and then click Add.

    6. In the Time of day constraints window, select Permitted. Verify that all days and times are permitted, click OK, and then click Next.

    7. If the local NPS is a NAP health policy server, verify that Authenticate requests on this server is chosen, click Next three times, and then click Finish. If the local NPS will forward requests to another server for evaluation, see Verify NPS proxy configuration.

    8. Resume the current procedure to validate the new connection request policy.

  3. On the Overview tab, verify that the Policy enabled check box is selected.

  4. On the Overview tab, verify that the Type of network access server is either Health Registration Authority or Unspecified. For more information about specifying an access server type, see additional considerations.

  5. Click the Conditions tab and verify that all configured conditions are matched by both compliant and noncompliant NAP clients. For example, Day and time restrictions can be configured to permit network access only on specified days at specified times.

  6. Click the Settings tab. Under Required Authentication Methods, click Authentication Methods, and verify that the Override network policy authentication settings check box is cleared.

  7. Under Forwarding Connection Request, click Authentication.

  8. To enable the local NPS as a NAP health policy server, verify that Authenticate requests on this server is chosen.

  9. Click OK to close the properties window.

Network policies

Network policies use conditions, settings, and constraints to determine who can connect to the network. To evaluate health status of NAP clients, there must be at least one network policy that will be applied to computers that are compliant with the health requirements, and at least one network policy that will be applied to computers that are noncompliant. Use the following procedure to verify that these policies have been created and configured for NAP IPsec enforcement.

To verify network policies

  1. In the NPS console tree, double-click Policies, and then click Network Policies.

  2. In the details pane, verify that you have at least one policy for compliant computers and one policy for noncompliant computers, and that these policies have a Status of Enabled. To enable a policy, right-click the policy name and then click Enable. If these policies are not present, perform the following steps to create a network policy.

    1. Right-click Network Policies, and the click New.

    2. Under Policy Name, type a name for the network policy, for example: NAP IPsec with HRA Compliant or NAP IPsec with HRA Noncompliant.

    3. Under Type of network access server, select Health Registration Authority, and then click Next.

    4. On the Specify Conditions page, click Add.

    5. In Select condition, click Health Policies, and then click Add.

    6. If this network policy will apply to compliant client computers, under Health Policies, choose a health policy that has been configured to match a compliant client health state, and then click OK.

    7. If this network policy will apply to noncompliant client computers, under Health Policies, choose a health policy that has been configured to match a noncompliant client health state, and then click OK.

    8. If no health policies are available, or health policies are not configured to match compliant and noncompliant client health states, see health policies and then resume this procedure.

    9. Click Next, select Access granted, and then click Next.

    10. On the Configure Authentication Methods page, select the Perform machine health check only check box, and then click Next twice.

    11. On the Configure Settings page, click NAP Enforcement.

    12. Choose an enforcement mode for this policy. See NAP enforcement modes for more information.

    13. To enable auto-remediation of noncompliant clients, select the Enable auto-remediation of client computers check box. If you do not wish to enable auto-remediation, clear this check box.

    14. Click Next, and then click Finish.

    15. Resume the current procedure to validate configuration of the new network policy.

  3. In the details pane, verify that the Processing Order of policies is configured correctly for your deployment. More specific policies are typically processed before more general policies. To change the order of policies, right-click the policy name and then click Move Up or Move Down.

  4. In the details pane, verify that both your compliant and noncompliant NAP policies are configured with an Access Type of Grant Access. To configure access permissions, right-click the policy name, click Properties, click the Overview tab, and then select Grant Access.

  5. In the details pane, verify that the Source of your policies used to process IPsec-protected NAP clients is either Health Registration Authority or Unspecified. For more information about specifying an access server type, see additional considerations.

  6. In the details pane, double-click the name of a network policy used to match compliant clients, and then click the Conditions tab.

  7. Verify that at least one of the conditions specified is Health Policy, and the Value corresponds to a health policy that you have configured to match a compliant client health state. If this condition is not present, perform the following steps.

    1. Click Add, click Health Policies, and then click Add.

    2. Under Health Policies, choose a policy that corresponds to a compliant client health state, and then click OK. If no health policies are available, then verify health policies and repeat this procedure.

  8. Click the Constraints tab, and then click Authentication Methods.

  9. Verify that the Perform machine health check only check box is selected.

  10. Click the Settings tab, and then click NAP Enforcement.

  11. Verify that Allow full network access is selected for this compliant network policy, and then click OK. This completes verification of a compliant network policy.

  12. In the details pane, double-click the name of a network policy used to match noncompliant clients, and then click the Conditions tab.

  13. Verify that at least one of the conditions specified is Health Policy, and the Value corresponds to a health policy that you have configured to match a noncompliant client health state. If this condition is not present, perform the following steps.

    1. Click Add, click Health Policies, and then click Add.

    2. Under Health Policies, choose a policy that corresponds to a noncompliant client health state, and then click OK. If no health policies are available, then verify health policies and repeat this procedure.

  14. Click the Constraints tab, and then click Authentication Methods.

  15. Verify that the Perform machine health check only check box is selected.

  16. Click the Settings tab, and then click NAP Enforcement.

  17. Verify that Allow limited access is selected for this noncompliant network policy if you have deployed NAP in a full enforcement mode.

  18. Verify that Allow full network access for a limited time is selected for this noncompliant network policy if you have deployed NAP in deferred enforcement mode.

  19. Verify that Allow full network access is selected for this noncompliant network policy if you have deployed NAP in reporting mode.

  20. Verify that the Enable auto-remediation of client computers check box is selected if you wish to enable automatic remediation of noncompliant NAP clients.

  21. Click OK.

  22. Repeat these steps as necessary to verify configuration of each of the network policies used to evaluate access requests from IPsec-protected NAP clients.

NAP enforcement modes

When you enable NAP on your network, three enforcement modes are available. Use these enforcement modes for staging your NAP deployment.

  • To enable reporting mode, select Allow full network access for both compliant and noncompliant NAP client computers. In reporting mode, the health status of client computers is logged but network access is not restricted. Both complaint and noncompliant computers receive health certificates.

  • To enable deferred enforcement mode, select Allow full network access in your compliant network policy and Allow full network access for a limited time in your noncompliant network policy. You must also specify a date and time when noncompliant clients will have their access restricted. In deferred enforcement mode, client computers immediately receive NAP notifications if they are not in compliance with network health requirements, but do not have their access restricted until the specified time and date.

  • To enable full enforcement mode, select Allow full network access in your compliant network policy and Allow limited access in your noncompliant network policy. In full enforcement mode, client computers immediately have their network access restricted if they are not in compliance with network health requirements.

Additional considerations

If the type of network access server in connection request policy and network policy is set to Unspecified, NPS uses this policy to evaluate all connection requests that originate from any type of network access server. If the type of network access server is set to Health Registration Authority, then only connection requests that are forwarded from an HRA server are evaluated by this policy. If one or more enabled policies have a specified source of Health Registration Authority, then all policies with an Unspecified source will be ignored by NPS when processing IPsec-protected NAP client network access requests.

Health policies

Health policies define which SHVs are evaluated, and how they are used in validating the configuration of computers that attempt to connect to your network. Based on the results of SHV checks, health policies classify client health status. You need at least one health policy that corresponds to a compliant client health state, and at least one health policy that corresponds to a noncompliant client health state. Use the following procedure to verify that compliant and noncompliant health policies have been configured on the NAP health policy server.

To verify health policies

  1. In the NPS console tree, double-click Policies, and then click Health Policies.

  2. In the details pane, under Policy Name, double-click the name of a compliant health policy. If this policy is not present, use the following steps to create a compliant health policy.

    1. Right-click Health Policies, and then click New.

    2. Under Policy name, type a name for your compliant health policy, for example: NAP IPsec with HRA Compliant.

    3. Under Client SHV checks, select Client passes all SHV checks to create a strict health policy, or select Client passes one or more SHV checks to create a more lenient health policy.

    4. Under SHVs used in this health policy, select the check box next to each SHV that will be used to evaluate client health. The Windows Security Health Validator is available by default. Other SHVs are available if they have been installed.

    5. Click OK, and resume this procedure to validate your new health policy.

  3. Under Client SHV checks, verify that either Client passes all SHV checks or Client passes one or more SHV checks is selected. These conditions are used to create compliant policies that are more restrictive or less restrictive, respectively.

  4. Under SHVs used in this health policy, verify that the check boxes are selected next to installed SHVs that will be used to evaluate health on your IPsec-protected NAP client computers, and then click OK.

  5. In the details pane, under Policy Name, double-click the name of a noncompliant health policy. If this policy is not present, use the following steps to create a noncompliant health policy.

    1. Right-click Health Policies, and then click New.

    2. Under Policy name, type a name for your noncompliant health policy, for example: NAP IPsec with HRA Noncompliant.

    3. Under Client SHV checks, select Client fails one or more SHV checks to create a strict health policy, or select Client fails all SHV checks to create a more lenient health policy.

    4. Under SHVs used in this health policy, select the check box next to each SHV that will be used to evaluate client health. The Windows Security Health Validator is available by default. Other SHVs are available if they have been installed.

    5. Click OK, and resume this procedure to validate your new health policy.

  6. Under Client SHV checks, verify that either Client fails one or more SHV checks or Client fails all SHV checks is selected. These conditions are used to create noncompliant policies that are more restrictive or less restrictive, respectively.

  7. Under SHVs used in this health policy, verify that the check boxes are selected next to installed SHVs that will be used to evaluate health on your IPsec-protected NAP client computers, and then click OK.

  8. Repeat these steps for all health policies used to evaluate your IPsec-protected NAP client computers.

System health validators

SHVs define software and configuration requirements for computers that attempt to connect to your network. Use the following procedure to verify that SHVs are configured correctly for your deployment.

To verify system health validators

  1. In the NPS console tree, double-click Network Access Protection, and then click System Health Validators.

  2. In the details pane, under Name, double-click the name of an installed SHV.

  3. Configuration of SHVs will vary based on implementation. If you are using the Windows Security Health Validator (WSHV), click Configure.

  4. To configure health requirements for computers running Windows Vista, click the Windows Vista tab.

  5. To configure health requirements for computers running Windows XP with Service Pack 3, click the Windows XP tab.

  6. Enable health requirements by selecting the check boxes next to specific health components. Clear these check boxes to disable requirements. The health requirements available when using the WSHV include: Firewall, Virus Protection, Spyware Protection, Automatic Updating, and Security Update Protection.

  7. Click OK, and configure error code resolutions for your deployment. Error code resolutions determine how clients are evaluated under the listed error conditions. You can select to return a status of Compliant or Noncompliant for each condition.

  8. Click OK, and close the NPS console.

Verify NPS proxy configuration

Use the following procedure to verify configuration of the local NPS server as a RADIUS proxy. This procedure does not apply if the local NPS server is configured as a NAP health policy server.

To verify NPS proxy configuration

  1. Click Start, click Run, type nps.msc, and then press ENTER.

  2. In the console tree, double-click RADIUS Clients and Servers, and then click Remote RADIUS Server Groups.

  3. In the details pane, under Group Name, double-click the name of a remote RADIUS server group. If no remote RADIUS server group entry is displayed, perform the following steps to add a remote RADIUS server group.

    1. In the console tree, under RADIUS Clients and Servers, right-click Remote RADIUS Server Groups, and then click New.

    2. Under Group name, type a name for the remote RADIUS server group, for example: NAP Health Policy Server1.

    3. Click Add, and then under Server type the DNS name or IP address of an NPS server that is configured to evaluate NAP IPsec client connection requests forwarded from the local HRA.

    4. Click Verify, and then click Resolve. Confirm that the IP address displayed is correct for your deployment, and then click OK.

    5. Click the Authentication/Accounting tab.

    6. Under Shared secret and Confirm shared secret, type the secret that is configured in NPS settings on the NAP health policy server.

    7. Click OK twice, and resume this procedure to validate the NPS proxy configuration.

  4. In the server group properties window, under RADIUS Server, click the name of a remote RADIUS server, and then click Edit.

  5. On the Address tab, click Verify.

  6. In the Verify Client dialog box, click Resolve. Verify that the IP address of the RADIUS client corresponds to a NAP health policy server on your network that is configured with a RADIUS proxy corresponding to the local NPS.

  7. Click OK, and then click the Authentication/Accounting tab.

  8. Verify that the authentication and accounting ports are correct for your deployment. The default authentication port is 1812 and the default accounting port is 1813.

  9. Verify that the Request must contain the message authenticator attribute check box is selected only if a corresponding access-request message requirement for the message authenticator attribute is enabled on the NAP health policy server. Clear this check box if the NAP health policy server does not require this attribute.

  10. If a shared secret mismatch is suspected, type the secret next to Shared secret and Confirm shared secret, and then click OK twice.

  11. In the console tree, double-click Policies, and then click Connection Request Policies.

  12. In the details pane, double-click the connection request policy that is used to authenticate incoming network access requests from IPsec-protected NAP clients.

  13. Click the Settings tab, and under Forwarding Connection Request, click Authentication.

  14. Verify that Forward requests to the following remote RADIUS server group for authentication is selected, and verify the name of the selected remote RADIUS server group corresponds to the correct NAP health policy servers on your network.

  15. Repeat these steps for all remote NPS servers and groups.

  16. Close the NPS console.

See Also

  • Troubleshooting HRA


Verify IIS Configuration

Use this procedure to verify that Internet Information Services (IIS) is running and configured correctly on your Health Registration Authority (HRA) server. IIS Web sites are used by HRA to process client health certificate requests.

For more information about IIS, see http://go.microsoft.com/fwlink/?LinkId=94386.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Verify availability of DomainHRA and NonDomainHRA Web sites

Two Web sites can be created on your HRA server, depending on the choices you make during the installation of HRA. These sites are used by HRA to process domain-authenticated or anonymous health certificate requests. After installation, no additional configuration of these Web sites is required. However, if IIS is not running or is not correctly configured, HRA might not be able to issue health certificates.

To verify availability of DomainHRA and NonDomainHRA Web sites

  1. Click Start, click Administrative Tools, and then click Services.

  2. In the Services window, verify that the World Wide Web Publishing Service is Started and that its Startup Type is set to Automatic.

  3. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  4. In the Internet Information Services (IIS) Manager window, double-click the computer name of your HRA server.

  5. Double-click Web Sites, and then double-click Default Web Site.

  6. Verify that both the DomainHRA and NonDomainHRA Web sites are displayed if you chose to allow anonymous requests for health certificates during the installation of HRA.

  7. Verify that only the DomainHRA Web site is displayed if you chose to require requestors to be authenticated as members of a domain during the installation of HRA.

  8. Click DomainHRA, and then double-click Authentication. Verify that only Windows Authentication is enabled.

  9. If the NonDomainHRA Web site is installed, click NonDomainHRA, and then double-click Authentication. Verify that only Anonymous Authentication is enabled.

  10. Click the computer name of your HRA server, and then double-click ISAPI and CGI Restrictions. Verify that the hcsrvext.dll extension is set to Allowed.
Important

If anonymous health certificate requests are enabled, you must not configure the NonDomainHRA Web site URL with a higher processing order than the DomainHRA Web site in trusted server group settings on NAP client computers. This can result in domain-joined NAP clients obtaining health certificates that are incompatible with domain authentication requirements used in IPsec-protected communications.

See Also

  • Understanding HRA Authentication Requirements