This documentation is archived and is not being maintained.
The Cable Guy NAP on the Internet
Network Access Protection (NAP) on the Internet is the natural evolution of Internet Protocol Security (IPsec) enforcement that extends health checking and ongoing remediation of system health for managed computers that are roaming on the Internet. NAP on the Internet enables a stronger, host-based security model for domain-joined computers connected to the Internet from anywhere, at any time. For example, a mobile computer connecting to a Wi-Fi network at a local coffee shop can use NAP on the Internet to evaluate and correct its system health without the user's knowledge or intervention.
Before we get into the details, let's review some of the basics and the deployment details about NAP and IPsec enforcement.
IPsec Enforcement Overview
IPsec enforcement is an extension of the domain isolation scenario that incorporates a NAP health assessment as part of the IPsec peer authentication process. In the domain isolation scenario, you configure domain members with IPsec policy settings to require that all incoming connections be authenticated and protected (encryption of traffic is optional). IPsec peers can use Kerberos or digital certificates for authentication. Domain members automatically have Kerberos credentials, and certificates can be automatically deployed to domain members with a Windows-based certificate authority (CA) and Group Policy.
For IPsec enforcement in NAP, the credential for IPsec peer authentication is a health certificate containing the System Health Authentication Enhanced Key Usage (EKU). IPsec policy for IPsec enforcement requires that all incoming connection attempts use a health certificate for authentication. This ensures that the peer initiating the communication is not only a domain member, but is also compliant with system health requirements. In full enforcement mode, if a NAP client does not have a health certificate, the IPsec peer authentication fails and the noncompliant NAP client cannot initiate communications with a compliant IPsec peer.
When a NAP client configured for IPsec enforcement starts up, it contacts a Health Registration Authority (HRA). An HRA is a computer running Windows Server 2008, Internet Information Services (IIS), and the HRA role service of the Network Policy and Access Services role. The HRA obtains an X.509 certificate from a CA on behalf of a NAP client when the NAP health policy server has determined that the client is compliant.
To obtain health certificates for compliant NAP clients, you must configure your HRAs with the locations of the NAP CAs on your intranet. For NAP clients to locate the HRAs on your intranet, you can either configure them with a trusted server group—a list of URLs for the HRAs on your intranet—or HRA discovery (see the sidebar "HRA Discovery and Internet-facing HRAs").
When NAP clients start, they locate an HRA on the intranet, submit their health status, and, if compliant, obtain a health certificate. When NAP clients initiate communications to other intranet endpoints, they attempt to negotiate IPsec protection for the traffic using the health certificate credential. If the IPsec negotiation fails, the NAP client connects without IPsec protection. If a compliant NAP client's health or network state changes, it does an additional system health check with an HRA, and if compliant, it obtains a new certificate. If there are system health conditions that need to be corrected, the NAP client will have to correct them before obtaining a health certificate.
HRA Discovery and Internet-facing HRAs
A NAP client can also use HRA discovery to automatically discover the HRAs on a network. Rather than configuring a list of URLs in a trusted server group, a NAP client that has HRA discovery enabled attempts to find an HRA by sending a DNS query for SRV records for _hra._tcp.site_name._sites.domain_name. For example, if a NAP client's primary domain is contoso.com and the client is using the default Active Directory site and has HRA discovery enabled, it will query for the SRV records for _hra._tcp.default-first-site-name._sites.contoso.com. The SRV record for HRAs contains the Fully Qualified Domain Name (FQDN) of the HRA. The DNS SRV records for HRAs must be manually configured in the appropriate zones.
For NAP on the Internet, you configure intranet HRA SRV records for the FQDNs of your intranet HRAs and Internet HRA SRV records for the FQDNs of your Internet-facing HRAs. The NAP client queries for the same name and record type, but gets different FQDNs depending on the location.
To enable HRA discovery for NAP clients that receive NAP configuration through Group Policy, set the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\ NetworkAccessProtection\ClientConfig\Enroll\HcsGroups\ EnableDiscovery registry value (DWORD type) to 1.
For more information, see "Configure HRA Automatic Discovery."
NAP on the Internet
When a NAP client computer configured for IPsec enforcement leaves the intranet and connects to the Internet, the NAP client still attempts to locate an HRA. Because the roaming computer on the Internet can no longer contact an intranet HRA and perform system health validation, it can no longer determine whether it is compliant with system health policies and how to correct its system health. Over time, a NAP client that roams the Internet can end up with missing operating system or application updates, or the user, depending on his privilege level, may perform configuration changes that put the computer at risk, such as disabling the host firewall.
When the noncompliant computer returns to the intranet, it must first remediate its system health before it can obtain a health certificate and begin communicating. While the noncompliant computer is being remediated, there is a risk that it can infect other intranet computers that are not protected by IPsec.
By placing HRAs on the Internet and configuring NAP clients to locate them, NAP clients on the Internet can check their health on an ongoing basis as if they were connected to the intranet. Although the health certificate is not used to perform IPsec peer authentication, the NAP client is still validating its health state. If autoremediation is enabled, the NAP client will automatically attempt to correct its health state to mitigate risks to the computer while on the Internet. Autoremediation keeps the computer compliant with your organization's system health requirements without requiring user intervention. A mobile computer that is already compliant returning from the Internet greatly reduces the risk of infection to intranet resources.
Remediation of system health issues is limited to the functionality of system health agents (SHAs) and may require that you deploy additional remediation servers on the Internet.
Note that by default, NAP clients try Kerberos authentication when connecting to the Internet-facing HRAs. Because a domain controller is not available on the Internet, this authentication will fail. Therefore, you must run the following command on the Internet-facing HRAs so that NAP clients use NTLM authentication:
%windir%\system32\inetsrv\appcmd.exe set config -section: system.webServer/security/authentication/windowsAuthentication /-providers.[value='Negotiate']
You can use the information logged by your NAP health policy servers to determine the overall health compliance of the NAP clients that are roaming on the Internet.
If your Internet-facing HRAs are separate from your intranet HRAs, you can configure a separate set of health requirement policies for your Internet-connected NAP clients. For example, you can configure separate sets of network policies by specifying the IP address of the HRAs as a condition. The intranet health requirement policies use all of your SHAs, such as the Windows Security Health Agent (WSHA), the Forefront SHA, and the System Center Configuration Manager (SCCM) SHA. The Internet set of health requirement policies use only the WSHA.
NAP on the Internet, an Example
Figure 1 shows a simplified illustration of how the Contoso Corporation has deployed NAP on the Internet.
Figure 1 Deploying NAP on the Internet
In this example, the Internet-facing HRAs are physically connected to both the Internet and the intranet so that they can reach the NAP CAs and the NAP health policy servers. To protect the Internet-facing HRAs, firewall settings allow only TCP port 443 traffic to and from the Internet-facing HRAs, corresponding to SSL over HTTP traffic.
Let's say the intranet HRAs have the names hra1.corp.contoso.com and hra2.corp.contoso.com. The Internet-facing HRAs have the names int_hra1.contoso.com and int_hra2.contoso.com. Of course, intranet DNS servers cannot resolve the names int_hra1.contoso.com and int_hra2.contoso.com and Internet-facing DNS servers cannot resolve the names hra1.corp.contoso.com and hra2.corp.contoso.com.
With this configuration, the network administrator for Contoso configures a trusted server group with the following list of URLs:
NAP clients first try the intranet HRAs and then the Internet-facing HRAs.
A NAP client on the intranet will connect to HRA1 or HRA2. A NAP client on the Internet will first attempt to resolve the names hra1.corp.contoso.com and hra2.corp.contoso.com. These two name resolution attempts quickly result in a DNS Name Not Found error. The NAP client then successfully resolves int_hra1.contoso.com or int_hra2.contoso.com and connects to INT_HRA1 or INT_HRA2.
Once the IPsec enforcement scenario has been deployed on your intranet, extending health compliance validation and correction for Internet-connected NAP clients is relatively easy, requiring some additional servers for the Internet-facing HRAs (or additional roles for existing Internet-facing servers). Moreover, depending on how your NAP clients locate HRAs, you may need to publish Internet DNS records for the Internet-facing HRAs and update your trusted server groups. You can also create an additional set of health requirement policies to specify the system health checks and autoremediation behavior for Internet-connected NAP clients.
Joseph Davies is a Principal Technical Writer on the Windows networking writing team at Microsoft. He is author or coauthor of a number of books published by Microsoft Press, including Windows Server 2008 Networking and Network Access Protection (NAP), Understanding IPv6, Second Edition, and Windows Server 2008 TCP/IP Protocols and Services.