Windows Server : Network Access Policy and Server and Domain Isolation (part 3) - Planning NAP VPN Enforcement, Planning NAP 802.1x Enforcement

4. Planning NAP VPN Enforcement

VPN enforcement in NAP is supported for VPN remote access connections by using PPP, specifically working in conjunction with the PPP authentication phase. Windows XP SP3, Windows Vista, and Windows Server 2008 support the remote access quarantine enforcement client for NAP clients.

VPN enforcement design requires you, the enterprise administrator, to consider the following:

• VPN authentication methods

• VPN servers in use

• VPN clients compliant with VPN enforcement

• Configuration of the restricted network for remediation

• Other VPN enforcement considerations such as:

  • Non-NAP-capable VPN clients

  • Configuring exemptions

  • Migration from network access quarantine control to VPN enforcement

  • Installing support for additional SHAs on NAP clients

  • Installing support for additional SHVs on NAP health policy servers

When VPN enforcement is employed, VPN clients are evaluated for compliance with health policy immediately after successful PPP authentication. Therefore, VPN clients are left in one of three stages after an attempt to connect through remote access:

• Clients fail authentication and the PPP session ends.

• Clients succeed in authenticating but do not possess a VPN enforcement client.

• Clients succeed in authenticating but do not pass the health inspection and become noncompliant.

• Clients succeed in authenticating, pass the health inspection, and become compliant.

Planning VPN Authentication Protocol Use for VPN Enforcement

Microsoft supports the use of the two PEAP-based authentication protocols, PEAP-TLS and PEAP-MSCHAP v2, for VPN enforcement. This is due to PEAP-TLS messages used to transmit system health state information between the VPN client and the NAP health policy server.

Your current VPN remote access solution can use PEAP-TLS and PEAP-MSCHAP v2 as you ramp up the environment to support NAP. PEAP-TLS requires support for a computer certificate on each computer within the environment as well as on the NPS server performing RADIUS authentication. PEAP-MSCHAP v2 requires a computer certificate for authentication only on the RADIUS server. The VPN enforcement clients are required to trust the certificate issued to the RADIUS server and need to have the certificate of the root CA in their Trusted Root Certification Authorities store. You can use Group Policy to issue a required certificate to each computer as well as to update the local computers’ Trusted Root Certification authorities.

If a PKI already exists, configuring PEAP-based support for managed computers is a bit easier administratively. Within AD DS, you can use a variety of ways to deliver Group Policy to select accounts. The two easiest methods to accomplish this goal without extensive Group Policy filtering are to:

• Create a computer group and add all the computer accounts to the group membership that participate as VPN enforcement clients.

• Create an organizational unit (OU) and move the computer accounts that participate as VPN enforcement clients into the OU.

Now, apply Group Policy and ensure that the container the Group Policy is applied to is the one that contains just the necessary computer accounts or contains the computer group containing the respective computer account members. If using a computer group to assemble the necessary computer accounts, you can filter Group Policy by ensuring that the specific computer group has the required Read and Apply Group Policy permissions assigned to it.

Other VPN Enforcement Considerations

Setting up support for VPN enforcement requires you to consider several remaining elements:

• Non-NAP-capable VPN clients

• Migration from network access quarantine control

• Installing or updating SHAs on clients

• Installing additional SHVs on NAP health policy servers

Non-NAP-Capable VPN Clients

VPN clients not capable of performing NAP and VPN enforcement need to be treated in one of two ways:

• Allow unlimited access by creating an exemption group.

• Allow only limited access to the restricted network.

To allow unlimited access, create an exemption group whose membership includes the non-NAP-capable computer accounts. Create a network policy by using the Windows Groups condition and selecting the newly created exemption group. On the settings for NAP enforcement on this network policy, ensure that the computer group is allowed full network access for an unlimited time or for a specified time limit. Using a specified time limit allows a period during which a non-NAP-capable client is upgraded to support VPN enforcement.

Using that same policy, you could switch the settings to ensure that the client is allowed only limited access. This would ensure a safer environment but a restriction in access for non-NAP-capable computers. This might severely restrict guests and partner access to a company. Ensure that this is the desired effect prior to implementing this decision.

Migrating from Network Access Quarantine Control

Moving to VPN enforcement is a natural progression from Network Access Quarantine Control, which is supported on Windows Server 2003 with the Internet Authentication Service (IAS) RADIUS server.

When upgrading to Windows Server 2008 from Windows Server 2003 running IAS and configured with Network Access Quarantine Control, all the Network Access Quarantine Control settings are brought over. To move toward NAP using VPN enforcement, you must upgrade all the computers running Windows Server 2003 that are running IAS. Although Windows Server 2008 supports Network Access Quarantine Control, Windows Server 2003 with IAS does not support NAP. During the migration from Network Access Quarantine Control to VPN enforcement, you can run them simultaneously. Upgrade your existing clients to support NAP and the clients configured for VPN enforcement.

5. Planning NAP 802.1x Enforcement

Using 802.1x enforcement means employing NAP at layer 2 over your network and entails both wired and wireless NAP clients configured with an EAPHost NAP enforcement client. Other key components involve an 802.1x-compliant access point and a NAP health policy server. An 802.1x access point can be either a wireless access point or a wired switch, with both being capable of performing 802.1x authentication.

Three Microsoft operating systems provide 802.1x enforcement clients:

• Windows Server 2008 Extensible Authentication Protocol (EAP) Quarantine enforcement client

• Windows Vista Extensible Authentication Protocol (EAP) Quarantine enforcement client

• Windows XP SP2 with two 802.1x enforcement clients

  • A wired client named EAP Quarantine enforcement client

  • A wireless client named Wireless EAPoL Quarantine enforcement client

Design Considerations for 802.1x Enforcement

The first step toward designing your 802.1x enforcement for NAP is to assess your current access points within your environment. Questions to answer involve the following:

• Are all the switches used at the access layer and back-end server farms 802.1x compatible?

• Which RADIUS attributes do they support for your 802.1x enforcement?

• Which 802.1x authentication methods will you use?

• Which type of 802.1x enforcement, access control list (ACL) or virtual local area network (VLAN), will you use?

• Must you support PXE boot?

Using the inventory list from the documentation of your switches, you can begin assessing the switches involved in the 802.1x enforcement. Contact the vendor’s Web site to find out about any known issues with employing NAP and about any necessary updates.

Access Point Considerations

As 802.1x authentication proliferates, more and more vendors are adding NAP support. There are even blogs devoted to listing security vendors supporting NAP. Finding hardware is not the problem; discerning whether the hardware currently in use is or can be made compliant is the issue. Purchasing new hardware is always an easy way to attain compliance but is also the most expensive.

When examining compliance, look for specific RADIUS support. The Microsoft NAP supports the following vendor-specific attributes (VSA) and RADIUS attributes for defining the restricted network with 802.1x enforcement:

• Filter-ID for identifying the ACL

• Tunnel-Medium-Type

• Tunnel-Pvt-Group-ID

• Tunnel-Type

• Tunnel-Tag

For setting the periodic re-authentication interval, the standard Session-Timeout RADIUS attribute has broad support from most of the hardware vendors.

ACLs vs. VLANs

802.1x enforcement can implement ACLs or VLANs for restricted access. Which enforcement method you use depends on your access point or switches’ support and which type provides the restriction desired within your environment.

Using ACLs, an administrator can define a specific set of packet filters that enable a noncompliant NAP client to communicate only with a specific subset of servers. Because the 802.1x enforcement process occurs over layer 2, the noncompliant NAP client still attempts automatic configuration for its IPv4 configuration or autoconfiguration for IPv6. It attains an address for its usual subnet but now is confined to limited access to specific servers for remediation. The big advantage here is that the ACL also prevents a rogue noncompliant NAP client from attempting to infect other noncompliant NAP clients. Because all the remediation servers should be up to date with their security software and configuration settings, the remediation servers should be fairly impervious to attack as well. This creates an isolated network on a per-port basis because the noncompliant client sees only the remediation network servers until fully compliant.

Using VLANs, an administrator can define a VLAN for remediation. Noncompliant NAT clients and 802.1x NAP clients failing a health check are forced into this VLAN by the wireless access point or a wired switch port on the switch. The VLAN is composed of remediation servers along with other noncompliant NAP clients. This restriction prevents communication outside the VLAN until the NAP client passes its health check. Ensure that this restricted VLAN is used solely for noncompliant NAP clients. Do not configure non-NAP-capable or unauthenticated NAP clients to use this VLAN. Normally, if an EAPHost NAP enforcement client fails authentication, the computer will not be allowed to communicate through the access point, so these unauthenticated computers will not be placed in the VLAN designated as the restricted network either.

Planning Authentication Protocols for 802.1x Enforcement

The only two supported authentication protocols for 802.1x enforcement included in Windows XP SP3, Windows Vista, and Windows Server 2008 are the PEAP types, PEAP-TLS and PEAP-MSCHAP v2. If implementing third-party vendor add-ons for 802.1x enforcement, you need to test their solutions because Microsoft NAP supports only PEAP-based solutions.

When implementing an 802.1x enforcement solution, you must consider the PKI when choosing between PEAP-TLS and PEAP-MSCHAP v2. If you’re using PEAP-TLS, it will probably be more cost effective to implement an internal Microsoft-based PKI. You need computer certificates for the NPS servers performing RADIUS authentication and the NAP clients using 802.1x enforcement. You can acquire certificates for computer accounts through autoenrollment using Group Policy, by importing a certificate file using either a group certificate (considered less secure) or an individual certificate per computer, or, finally, by using Web enrollment.

The RADIUS servers require a certificate for PEAP-MSCHAP v2. You must install the root CA certificate on all computers employing 802.1x enforcement. For managed computers, it is fairly easy to have clients trust the root CA by using Group Policy. For unmanaged computers, you need to import the root CA certificate into the local computer’s Trusted Root Certification Authorities store.

Using 802.1x enforcement also requires you to consider the reauthentication interval. If health policy changes, there is no standard way to enforce client remediation after an 802.1x enforcement client is considered compliant. Setting a time interval that requires clients to reauthenticate provides a reliable means of forcing clients to seek compliance when the health policy is modified. As mentioned earlier, shorter intervals place a greater stress on the NAP infrastructure components such as RADIUS. Microsoft best practices recommends a four-hour interval. You can enforce a reauthentication interval by the following techniques:

• Direct manipulation of the access point’s 802.1x configuration

• A VSA configured on the RADIUS server and supported by the 802.1x access point

• The Session-Timeout RADIUS attribute

Other 802.1x Enforcement Considerations

802.1x enforcement is not without some issues. One of them is the problem of not allowing the use of PXE boot on switch ports where 802.1x enforcement is configured. Also, there might be certain noncapable 802.1x clients within your environment, such as printer servers, fax servers, or computers installed with an operating system that is noncompliant for 802.1x enforcement. You must exempt them from 802.1x enforcement. Configuring exemptions can be as easy as configuring the specific ports used by these network clients to be exempt from 802.1x authentication and 802.1x enforcement or from just 802.1x enforcement if they support 802.1x authentication but not 802.1x enforcement.

Using 802.1x is not the security panacea that will solve all your concerns with keeping out attackers. As stated earlier, NAP is not designed to stop attackers; it is mainly designed to prevent malware outbreaks. In fact, 802.1x authentication has one known flaw regarding man-in-the-middle attacks, but this requires some physical access to your access ports. In addition, 802.1x does not provide the end-to-end security that IPsec enforcement can provide.

802.1x provides the assurance that compliant computers on the network, if attacked by invading malware, are better equipped to ward off the attack. It helps maintain a stable and secure environment.