Windows Server : Network Access Policy and Server and Domain Isolation (part 2) - Planning NAP IPsec Enforcement

2. Considerations for NAP Enforcement

When deliberating between the types of NAP enforcement methods to institute within your network, you need to know the strengths and weaknesses of each method. How does each method deal with non-NAP capable computers? What is required in each method to administer unmanaged computers (computers not part of the internal AD DS)? In planning a NAP solution, consider that all the NAP enforcement methods have one or more of the following aspects:

• NAP does not stop attackers.

• NAP, to some degree, implies a trust with the NAP client.

• NAP does not remove harmful software from connecting computers.

• NAP should be treated as an assurance feature.

NAP cannot stop an attacker. A malicious user, whether an employee, guest, or outside user, might provide all the necessary compliance for access to your network but still launch an attack when inside your network.

NAP indirectly assumes that the client has not provided false settings, configurations, or modifications to installed software to attain a false positive of compliance. Remember, you are essentially asking the computer owner whether everything on the computer is fine and he or she has not falsified, concealed, or knowingly allowed anyone to configure or install software on this computer. Does this sound similar to the security warnings you might hear a dozen times an hour at any airport?

NAP provides a health statement based on the appearance of sound security configurations, settings, and installed software. It does not scan the computer for malicious software but, rather, assumes that the verified health state of a computer means that another subsystem or configuration on an installed security software application performs that feature.

Finally, NAP is an assurance feature. You are determining that the computers connecting to your network and communicating with the secure internal environment have applied the necessary security precautions to prevent an outbreak. Remember, if someone with malicious intent were to circumvent your NAP solution, the assurance that all other computers have complied with your NAP policies will help deter an attacker from damaging your environment or possibly acquiring sensitive information. As an enterprise administrator, realize your NAP solution was not meant to stop an employee or would-be attacker intent on stealing information; that is not the role a NAP infrastructure is meant to play.

3. Planning NAP IPsec Enforcement

When looking for the strongest enforcement method to apply within your network, NAP IPsec enforcement provides the most robust and tamper-resistant solution compared to all other NAP enforcement methods. IPsec enforcement has these advantages:

• Tightly controlled enforcement that not even the local administrator is capable of bypassing

• Upgrades to network infrastructure devices such as hubs, switches, and routers to support NAP are unnecessary

• Granular control to network access

• Easier avenue to end-to-end encryption of sensitive communications

Even by manipulating settings and the configuration of the local computer, administrators cannot bypass health certificates issued by the Health Registration Authority (HRA). Because all other computers are also protected by the same means, there is no way to subvert this requirement. Introducing new switches or other network devices provides no means around the required legitimate health certificate to communicate with hosts expecting the certificate during the IPsec negotiation.

IPsec works at layer 3 and uses a logical connection that is above the physical layers in the network; bypassing it would require modification or extensive reconfiguration of physical hardware.

IPsec allows an administrator to control communication pathways end-to-end. An administrator can create hardened IPsec policies that dictate source and destination IP addresses along with source and destination ports that are allowed for communication and must be encrypted. IPsec enforcement can also control access to the network stringently but use a general approach to managing communication. If you use IPsec enforcement to tightly control access to the secure network, you have already taken a large leap toward encrypting sensitive traffic within your environment.

The disadvantages of an IPsec enforcement solution deserve serious consideration as well:

• It requires creation and maintenance of network zones for the logical separation of network communication.

• It requires the establishment of an internal PKI. If one already exists, it might need a minor overhaul if its creator did not anticipate the additional load that an IPsec enforcement solution will incur.

• It requires another series of servers, which must be managed for configuration, load balancing, and high availability. Loss of the ability to issue health certificates would mean a catastrophic loss of communication within the environment.

When weighing the advantages and disadvantages of a NAP solution using IPsec enforcement, an organization has to consider the increased security that would be provided. IPsec enforcement provides not only the direct benefits offered by a NAP solution but also the increased benefits of data confidentiality when communicating throughout the network environment.

Designing NAP IPsec Enforcement

When planning NAP IPsec enforcement for any organization, you need to establish the security zones first and determine which services to offer in the boundary network. The three security zones for an IPsec solution are:

• Restricted network

• Boundary network

• Secure network

Restricted Network

The restricted network, also referred to as the remediation network, is not the same as the perimeter network. The restricted network is a select network where noncompliant computers have limited access to services to perform remediation. Computers placed into the restricted network consist of either noncompliant NAP clients or non-NAP-capable clients. For IPsec enforcement, the restricted network includes only these devices.

Computers in the restricted network can initiate communication with computers in the restricted and boundary networks. Neither communication is protected by IPsec. Computers in all three networks, however, can initiate communication with computers in the restricted network. This communication is not protected by IPsec either.

Non-NAP-compliant computers have already attempted communication with an HRA and have received a System Statement of Health Response (SSoHR) that contains the Statement of Health Responses (SoHRs) stating which system health agents (SHAs) are noncompliant. The non-NAP-compliant computer in the restricted network will initiate contact with servers in the boundary network to perform remediation. After remediation has been performed, the non-NAP-compliant computer will try again to attain a health certificate. The computer will go through the process of accumulating, across all SHAs, a Statement of Health (SoH) and submit a System Statement of Health (SSoH) to an HRA. The HRA, using System Health Validators (SHVs), will process all SoHs on the SSoH to formulate its SSoHR.

Upon receiving the SSoHR that shows the NAP client as compliant, the HRA also issues a health certificate so that the NAP client is now part of the secure network and initiates IPsec-authenticated communication with computers in either the boundary network or the secure network.

Non-NAP-capable computers are those of guests and other unsupported operating systems such as any version of Windows earlier than Windows XP SP3, Apple Macintosh computers, and UNIX computers. A guest computer can be NAP capable but, because it is unmanaged (not part of AD DS), will more than likely be treated like a non-NAP-capable computer unless network policies dictate otherwise.

Boundary Network

The boundary network contains computers responsible for remediation as well as for the HRAs, support services such as DNS, AD DS, and DHCP servers, WSUS and possibly, the NAP CAs. Because the boundary network requires communication from computers residing in the restricted and secure networks, IPsec policies should allow for IPsec-authenticated traffic as well as for unauthenticated traffic. Computers in the boundary network should be managed computers. This enables them to receive their IPsec policies and changes to those policies through Group Policy.

Boundary servers, when communicating with computers in the restricted network, allow unauthenticated communication because computers in the restricted network do not contain the necessary health certificates. When boundary servers communicate with servers in the restricted network, IPsec-authenticated traffic is required.

There is a twist to this last statement. The boundary computers themselves are the ones that offer the update services, have the necessary configuration for compliance, and are part of the NAP components. To ensure that they are capable of initiating IPsec-authenticated communication, they also require a health certificate. To provide these computers with a health certificate, create an IPsec NAP exemption group whose membership includes all the computers of the boundary network. Configure a Group Policy setting that sets the NAP IPsec exemption group for certificate autoenrollment to acquire the necessary health certificate. Because the computers of the exemption group need to hold onto this certificate for the period of time they are performing their services, ensure that the template used to issue the certificate has been set for an extended period of time.

Computers from the restricted network as well as the computers in the boundary network need authentication services. Domain controllers located in the boundary network should be RODCs.

Secure Network

The secure network includes all computers that have passed health validation and have acquired a health certificate. The remaining portion of the NAP components related to IPsec enforcement also resides here. These components consist of the following:

• NAP Health Policy servers

• Health Requirement servers

• Root CAs

• RADIUS proxy servers

Computers within this network should be managed computers (part of AD DS). This enables them to acquire their IPsec policies and any configuration changes to your NAP environment through Group Policy.

Scaling NAP IPsec Enforcement for Small Environments

When deploying components for NAP IPsec enforcement, you have the opportunity to decide which components can be installed together. In smaller environments, it might be appropriate to consolidate several services on one computer. The issue becomes deciding which services to install together.

The HRA must be able to support unprotected communication from NAP clients, and you should, therefore, install the HRA in the boundary network. Because the load on the HRA in a small environment might not be that heavy, you might decide to install it on a computer that has one or more of the following services other computers in the boundary network also need:

• RODCs

• NPS configured for the NAP Health Policy Server role

• NAP CA

If your environment is expected to grow, it would be wise to move some of these components to another server. You can then assume that the server installed with the HRA would be deployed in the boundary network, and another computer with the remaining services would be deployed in the secure network.

Administrators of extremely small sites of 15 or fewer computers might consider employing ISA Server 2006. ISA Server can create a site-to-site VPN link to the main office boundary network. The connection from the VPN server in the boundary network can be treated like any other local connection requiring IPsec enforcement to obtain a certificate initially. After a computer at the remote office has obtained a health certificate, IPsec rules can be managed granularly to ensure that the branch office computer is able to communicate only with the necessary services at the remote office, through the site-to-site VPN, and in the boundary network for remediation and renewal of certificates. ISA Server would require a certificate as well and should probably be included in the IPsec exemption group. Ensure that a computer certificate is issued to the computer running ISA Server for an extended period of time.

Scaling NAP IPsec Enforcement for Larger Environments

For larger environments, several components require a thorough design review to ensure high availability and load balancing of specific components. You can begin by deciding which of the following services will be installed individually on at least two or more computers in the boundary network at the corporate office:

• HRA

• RODC

• Subordinate NAP CA

• Remediation server services

By providing fault tolerance for the HRA, the RODCs, and the NAP CA, you are ensuring a healthy environment. Remember that by employing IPsec enforcement, you are required to have these services running constantly. If one or more of these services become unavailable, health certificates will expire, and communication within the network will fail. Ensuring the ability of NAP clients to acquire health certificates is essential because all communication depends upon the necessity of each computer to present a valid health certificate when attempting to communicate with another computer.

In the secure network, deploy at least two NAP health policy servers. Configure the HRA computers as RADIUS clients of the NAP health policy servers. To ensure proper load balancing when configuring the remote RADIUS server group of the NPS service on the HRA computers, use the same priority and weight settings for all members of the RADIUS server group on each of the HRA computers.

For deployments at the branch offices, consider using the deployment models discussed previously for a small company. The services offered at the branch offices would model the same considerations given to a smaller company with a single site.

PKI Support for IPsec Enforcement

IPsec enforcement use of health certificates requires you, as the enterprise administrator, to reexamine the role PKI currently has within your environment. If a PKI does not exist, you need to deploy one. If one already exists, consider the additional load balancing and management that will be needed.

Smaller environments that already have a PKI probably require only the creation of a subordinate CA for NAP. This CA can be deployed in the boundary networks on the HRA to conserve server resources.

Larger environments require more planning because you now need to consider additional aspects of PKI when employed for use with NAP IPsec enforcement. The load on the CA issuing health certificates will be directly proportional to:

• The number of NAP clients in the environment.

• The lifetime of a health certificate.

The number of NAP clients is not something that you can truly control because deploying a NAP solution would entail using it pervasively throughout the environment.

The lifetime of the health certificate is something you can administer, and it has a direct influence over the load on your NAP CAs. Microsoft recommends for best practices to keep the lifetime at a minimum, preferably four hours. Reducing this time increases the load on the NAP CAs for renewals. Increasing the time, although reducing the load on the NAP CAs, also increases the likelihood that a computer can be out of compliance for a longer period due to changes in the health requirement policy.

Structure of the PKI

For most environments, adding an additional subordinate CA to issue health certificates for NAP is sufficient. Microsoft recommends that, in large environments, administrators create an entirely new PKI for NAP. You need to install a new root CA on a server within the secure environment and secure its private key with a hardware security module (HSM). Create subordinate CAs for NAP to issue the health certificates. These can be deployed in the boundary network and given the same security consideration as the RODCs deployed there. This would mean the removal of all unnecessary services and provide a limited attack surface. Securing its private key is not as critical as securing the root CA because certificates issued by it will have a limited lifetime.

You do not need to worry about issuing timely certificate revocation lists (CRLs) for this portion of your PKI because the certificates will expire long before the CRLs are published. In addition, an OCSP responder service is also unnecessary due to the limited lifetime of your health certificates.

Configuring Additional NAP Components on Clients

System health agents from third-party members need to be installed on all NAP clients. A variety of software distribution methods is available to an administrator. You can use any one of the following not only for IPsec enforcement but also for VPN enforcement, 802.1x enforcement, and DHCP enforcement:

• Software deployment or logon scripts through Group Policy.

• Desktop management software such as Microsoft System Center Configuration Manager

  2007.

• Manual installation for unmanaged computers.

• Shares on remediation servers. Configure the troubleshooting URLs to instruct the user to install the missing SHAs.

Configuring NAP Health Policy Servers

The NPS server running the NAP health policy server can be configured with additional third-party SHVs. Installation instructions for the third-party SHVs are provided by the third-party vendor. The SHVs must be installed on all NAP health policy servers participating in the NAP solution for IPsec as well as for VPN enforcement, 802.1x enforcement, and DHCP enforcement. Windows Server 2008 provides the default Windows Security Health Validator SHV that provides security settings for the Windows Security Center on Windows NAP clients.