NAP Enforcement Methods

So NAP can enforce compliance with network health policies you define for your network. But how does it enforce compliance? What are the enforcement mechanisms available? NAP actually has five different enforcement mechanisms you can use: DHCP, VPN, 802.1X, IPSec, and TS-Gateway. Let’s briefly look at each of these mechanisms and how NAP uses them to verify health and enforce compliance with health policies you’ve defined.


DHCP Enforcement
DHCP is the network administrator’s friend. It makes managing IP addresses across an enterprise easy. You don’t want to have to go back to managing addresses manually, do you? But DHCP is a notoriously unsecure protocol that basically just gives an address to any machine that wants one. You want an IP address? Here, you can have this one-don’t bother me for a while. Once your machine has an IP address (and subnet mask, default gateway, and DNS server addresses), you’re on the network and you can communicate with other machines. If you have the right permissions, you can access shared resources on the network. If you don’t have any permissions, you can’t access any resources, but you can still wreak havoc on the network if your machine is infected with Blaster, Slammer, or some other worm.

So how does NAP help prevent such infected machines from damaging your network? It’s easy if your DHCP server is running Windows Server 2008 and either has the Network Policy Server (NPS) role service installed as a RADIUS server (with policies) or has NPS installed as a RADIUS proxy that redirects RADIUS requests to a different NPS server running as a RADIUS server somewhere else on your network. Basically, what happens in this enforcement scenario is this (for simplicity we’ll assume the first option above is true, that is NPS and DHCP servers are installed on the same Windows Server 2008 machine):

1. Client configured to obtain IP address configuration using DHCP tries to connect to DHCP server on network to obtain address and access the network.

2. DHCP (NAP) server checks the health of the client. If the client is healthy, it leases a full, valid IP address configuration (address, mask, gateway, and DNS) to the client and the client enters the network. If the client is unhealthy (not in compliance with NAP health policy requirements), the DHCP server leases a limited IP address configuration to the client that includes only the following:
• IP address
• Subnet mask
• Set of host routes to remediation servers on the restricted network

3. Once configured, the client has no default gateway and can access only the specified servers on the local subnet. These servers (called remediation servers) can apply patches, provide updated AV sigs, and perform other actions to help bring the client into compliance.

4. Finally, once the client has been brought into compliance (made healthy), the DHCP server leases a full IP address configuration to it and it can now connect to the intranet.


VPN Enforcement
VPN is the most popular way today’s enterprises provide remote access to clients. Remember the old days when large businesses had to buy modem banks and lease dozens of phone lines to handle remote clients that needed to dial in and connect to corpnet? Those days are long gone now that secure VPN technologies have arrived that encrypt all communication between VPN clients and servers. Windows Vista has a built-in VPN client that enables a client computer to tunnel over the Internet and connect to a VPN server running Windows Server 2008. To use VPN as an enforcement mechanism for NAP, your VPN server needs to be running Windows Server 2008 and have the Routing And Remote Access Services role service installed on it.

Basically, VPN enforcement works like this:
1. The remote VPN client attempts to connect to the VPN server on your perimeter network.

2. The VPN server checks the health of the client by contacting the NAP server (which again is either a separate NPS or RADIUS server running Windows Server 2008 or a RADIUS proxy redirecting RADIUS requests to a different NPS on your network). If the client is healthy, it establishes the VPN connection and the remote client is on the network. If the client is unhealthy, the VPN server applies a set of packet filters that quarantines the client by letting it connect only to your restricted network where your remediation servers are located.

3. Once your client gets remediated (for example, by downloading the latest AV sig file) the VPN server removes the packet filters from the client and the client can then connect freely to corpnet.


802.1X Enforcement
802.1X is an IEEE standard that defines a mechanism for port-based network access control. It’s used to provide authenticated network access to Ethernet networks and was originally designed for wired networks but also works with 802.11 wireless networks. By port-based network access control I mean that 802.1X uses the physical characteristics of a switched LAN infrastructure to authenticate a device that is attached to a port on a switch. If the device is authenticated, the switch allows it to send and receive frames on the network. If authentication is denied, the switch doesn’t allow the device to do this. The authentication mechanism used by 802.1X is EAP (Extensible Authentication Protocol), which is based on PPP (Point-to-Point Protocol), and for Windows Vista and Windows Server 2008 the exact supported authentication protocols are EAP-TLS, PEAP-TLS, and PEAP-MS-CHAP v2. We’re talking acronym city here-we won’t go into that.

802.1X enforcement basically works like this:
1. An EAP-capable client device (for example, a computer running Windows Vista, which has an EAPHost NAP enforcement client) tries to connect an 802.1X-capable switch on your network. Most modern managed Ethernet switches support 802.1X, and in order to support NAP the switch must support 802.1x authentication and V-LAN switching based on the authentication results from the auth submitted to the RADIUS server (in this case the RADIUS server is NPS, which will also do NAP).

2. The switch forwards the health status of the client to the NPS, which determines whether it complies with policy. If the client is healthy, the NPS tells the switch to open the port and the client is let into the network. If the compliance test fails, either the switch can close the port and deny the client entry, or it can VLAN the client to place it on an isolated network where it can talk only to remediation servers. Then once the client is remediated, the switch lets it onto corpnet.


IPSec Enforcement
IPSec enforcement for NAP works a little differently than the other enforcement methods just described. Specifically, IPSec enforcement doesn’t quarantine a noncompliant client by isolating it on a restricted network or VLAN. Instead, a noncompliant client simply doesn’t receive a health certificate as these are only given to machines that connect to a Health Registration Authority (HRA), submit a Statement of Health (SoH), pass the health check and then receive that certificate back. Then, other machines that have IPSec policy that mandates that they only receive incoming connections from machines that have a health certificate will ignore incoming connections from noncompliant machines since they don’t have a health certificate. So in other words, in IPSec NAP enforcement, a noncompliant machine is allowed onto the network in a physical sense (in the sense that it can send and receive frames), but compliant computers on the network simply ignore traffic from the noncompliant machine.

To configure IPSec enforcement, you configure IPSec policy for your client machines to require a health certificate. This is easy to do in Windows Vista because this functionality is built into the new Windows Firewall With Advanced Security. Then you set up a HRA on your network, and the HRA works together with the Network Policy Server (NPS) to issue X.509 health certificates to clients that are determined to comply with NAP health policy for the network. These certificates are then used to authenticate the clients when they attempt to initiate IPSec-protected connections with other machines (called peers) on your network.

The HRA is a key component of using IPSec for NAP enforcements, and it has to be a machine running Windows Server 2008 and having the IIS7 component (Web Server role) installed. The HRA obtains health certificates for compliant NAP clients from a certification authority (CA), and the CA can be installed either on the Windows Server 2008 machine or on a different system. The HRA obtains health certificates.


TS Gateway Enforcement
TS Gateway is yet another NAP enforcement. TS Gateway NAP enforcement, however, supports only quarantine enforcement and does not support auto-remediation of the client when the client fails to meet health checks. To understand how TS Gateway NAP enforcement works, let’s examine a “clean machine” scenario where a TS Gateway client is used for the first time from a non-domain-joined client computer:

1. The user clicks on a Remote Desktop Connection icon, and the TS Gateway Client (TSGC) on his computer attempts to connect through TCP and HTTP transports simultaneously (the client tries TCP first and then HTTP). As soon as Terminal Services (TS) name resolution or TCP fails, the TSGC will attempt to connect to a TS Gateway server (TSGS) and authenticate the user at IIS and RPC layers.

2. During the user authentication process and after SSL handshake but before the GAP/RAP authorization sequence begins, the TSGS challenges the client for a “SoH request” blob and in its challenge/response it includes its certificate in PKCS#7 formats plus a random generated nonce value.

3. Since the request for a SoH was made on behalf of an untrusted TSGS name, the TSG-QEC will block the request. First the TS user must add to the TSG URL in the trusted gateway server list in the registry, and this requires admin privilege on the machine. Network administrators can also use SMS or logon scripts to populate this regkey setting.

4. The TSG_QEC will then talk to the QA to get the SoHs from SHAs. The TSG_QEC will then create a “SoH request blob” by combing SoHs from QAs, the nonce from the TSGS, a randomly generated symmetric key, and the client’s machine name. The TSG QEC will encrypt this “SoH request” blob using the TSGS’s public key and give it to the TSGC.

5. The TSGC then passes this encrypted blob to the TSG server, which decrypts the blob and extracts the SoH, the TSGS nonce, and the TSG_QEC symmetric key. The TSGS then verifies that the nonce it received from the TSG_QEC is the same as the one it sent out previously, and if it is the same, the TSGS sends the decrypted SoH blob to the NPS (RADIUS) server for validation.

6. The NPS server then calls SHVs and sends the “SoH request” blob for validation. The NPS server calls SHVs to validate the SoHs and replay with a response back to the NPS server, and based on SHVs’ pass/fail response the NPS server will create a “SoH response” and send it to the TSGS.

7. The TSGS passes this information to the TSGS RADIUS proxy for GAP (Gateway Authorization Policy) authorization, and if this succeeds, the TSGS RADIUS proxy returns success with its gateway level of access info. Based on this result, the TSGS then allows the TS client to connect to the TS server.

Source of Information : Introducing Windows Server 2008