Understanding Network Access Protection

There are already solutions around that can do some of these things. Some of them are homegrown. For example, one organization I’m familiar with uses a DHCP registration system that links MAC addresses to user accounts stored in Active Directory to control which machines have access to the network. But homegrown solutions like this tend to be hard to manage and difficult to maintain, and they can sometimes be circumvented-for example, by using a static IP address configuration that allows access to a subnet scoped by DHCP.

Vendors also have their own solutions to this problem, and Microsoft has one for Windows Server 2003 called Network Access Quarantine Control, but although this solution can enhance the security of your network if implemented properly, it has its limitations. For example, although Network Access Quarantine Control can perform client inspection on machines trying to connect to the network, it’s only intended to do so for remote access connections. Basically, what Network Access Quarantine Control does is delay normal remote access to a private network until the configuration of the remote computer has been checked and validated by a quarantine script. And it’s the customers themselves who must write these scripts that perform the compliance checks because the exact nature of these scripts depends upon the customer’s own networking environment. This can make Network Access Quarantine Control challenging to implement.

Other vendors, such as Cisco Systems, have developed their own solutions to the problem, and Cisco’s solution is called Network Access Control (NAC). NAC is designed to enforce security policy compliance on any devices that are trying to access network resources. Using NAC, you can allow network access to devices that are compliant and trusted, and you can restrict access for devices that are noncompliant. NAC is both a framework that includes infrastructure to support compliance checks based on industry-common AV and security management products, and a product called NAC Appliance that you can drop in and use to build your compliance checking, remediation, and enforcement infrastructure.

Network Access Protection (NAP) in Windows Server 2008 is another solution, and it’s one that is rapidly gaining recognition in the enterprise IT community. NAP consists of a set of components for both servers (Windows Server 2008 only) and clients (Windows Vista now, Windows XP soon), together with a set of APIs that will be made public once Windows Server 2008 is released. NAP is not a product but a platform that is widely supported by over 100 different ISVs and IHVs, including AV vendors like McAfee and Symantec, patch management companies like Altiris and PatchLink, security software vendors like RSA Security, makers of security appliances including Citrix, network device manufacturers including Enterasys and F5, and system integrators such as EDS and VeriSign. Those are all big names in the industry, and the number of vendors supporting NAP is increasing daily. And that’s not marketing hype, it’s fact-and it’s important to IT pros like us because we want a platform like NAP to support our existing enterprise networks, which typically already have products and solutions from many of the vendors I just listed.

What NAP Does

If you want a short definition of NAP, it’s this: NAP is a platform that can enforce compliance by computing devices with predetermined health requirements before these devices are allowed to access or communicate on a network. By itself, NAP is not designed to protect your network and is not intended to replace firewalls, AV products, patch management systems, and other protection elements. Instead, it’s designed to work together with these different elements to ensure devices on your network comply with policy that you have defined. And by devices I mean client computers (Windows Vista and soon Windows XP as well), servers running Windows Server 2008, PDAs running Windows Mobile (soon), and eventually also computers running other operating systems such as Linux and the Apple Macintosh operating system (using NAP components developed by third-party vendors).

Let’s unpack this a bit further. NAP supplies an infrastructure (components and APIs) that provides support for the following four processes:

• Health policy validation NAP can determine whether a given computer is compliant or not with a set of health policy requirements that you, the administrator, can define for your network. For example, one of your health requirements might be that all computers on your network must have a host-based firewall installed on them and enabled. Another requirement might be that all computers on your network must have the latest software updates installed on them.

• Network access limitation NAP can limit access to network resources for computers that are noncompliant with your health policy requirements. This limiting of access can range from preventing the noncompliant computer from connecting to any other computers on your network to quarantining it on a subnet and restricting its access to a limited set of machines. Or you can choose to not limit access at all for noncompliant computers and merely log their presence on the network for reporting purposes; it’s you’re choice-NAP puts you, the administrator, in control of how you limit network access based on compliance.

• Automatic remediation NAP can automatically remediate noncompliant computers that are attempting to access the network. For example, say you have a laptop that doesn’t have the latest security updates installed on it. You try to connect to corpnet, and NAP identifies your machine as noncompliant with corpnet health requirements, and it quarantines your machine on a restricted subnet where it can interact only with Windows Server Update Services (WSUS) servers. NAP then points your machine to the WSUS servers and tells it to go and get updates from them. Your machine downloads the updates, NAP then verifies that your machine is now healthy, and you’re let in the door and can access corpnet. Automatic remediation like this allows NAP to not just prevent unhealthy machines from connecting to your network, but also help those machines become healthy so that they can have access to needed network resources without bringing worms and other malware into your network. Of course, NAP puts you, the administrator, in the driver’s seat, so you can turn off auto-remediation if you want to and instead have NAP simply point the noncompliant machine to an internal Web site that gives the user instructions on what to do to make the machine compliant (or simply states why the noncompliant machine is not being allowed access to the network). Again, it’s your choice how you want NAP to operate with regard to how remediation is performed.

• Ongoing compliance Finally, NAP doesn’t just check for compliance when your computer joins the network. It continues to verify compliance on an ongoing basis to ensure that your machine remains healthy for the entire duration of the time it’s connected to your network.

As an example, let’s say your NAP health policy is configured to enforce compliance with the requirement that Windows Firewall be turned on for all Windows Vista and Windows XP clients connected to the network. You’re on the road and you VPN into corpnet, and NAP-after verifying that Windows Firewall is enabled on your machine- lets you in. Once you’re in, however, you decide for some reason to turn Windows Firewall off. (You’re an administrator on your machine, so you can do that-making users local administrators is not best practice, but some companies do that.) So you turn off Windows Firewall, which means the status of your machine has now changed and it’s out of compliance. What does NAP do? If you’ve configured it properly, it simply turns Windows Firewall back on! How does this work? The client computer has a NAP agent running on it and this agent detects this change in health status and tries to immediately remediate the situation. It can be a bit more complicated than that (for example, agent detects noncompliance, health certificate gets deleted, client goes into quarantine, NAP server remediates, agent confirms compliance, client becomes healthy again and regains access to the network) but that’s the basic idea-we’ll talk more about the NAP architecture in a moment.

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. (This role service is part of the Network Policy And Access Services role. (See Chapter 5 for more information about roles and role services.)

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. (See the Windows Vista Resource Kit from Microsoft Press for more information.) 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. Let’s learn more about HRA from an expert at Microsoft:

From the Experts: HRA Auto Discovery for Network Access Protection IPSec Enforcement

Large enterprises often have complex deployments involving many domains, multiple forests, and a large number of sites within this hierarchy. NAP clients require the configuration of Health Registration Authorities (HRAs), which clients need to contact to acquire a health certificate. This can be configured on the client either locally or pushed out via Group Policy, which requires the administrators to create site-specific GPOs to specify which HRAs a client should hit to acquire a health certificate and which HRAs are perceived to be too costly. This can be complex.

An alternative solution is to use the HRA Auto Discovery feature built into the NAP client, which enables clients to dynamically discover the appropriate HRA based on DNS SRV records.

How HRA Auto Discovery Works

A client will dynamically discover HRAs only when there is no NAP Group Policy or NAP Local configuration on the client. Also, clients need to be explicitly set to discover HRA. Here’s how it works.

The client first checks to see whether there are SRV records for HRAs in the “site” the host is in:

• If yes, add the HRA as the discovered one.

• Or else, try to see if there are SRV records for the AD domain the host is in and derive the HRA list from there.

• If not, the client discovers the HRA from the SRV records for the DNS domain the host is in.

  Domain-joined clients discover HRA from the “DNS site SRV” records of the DNS server, while site-less domain clients discover HRA from the “Domain SRV records.” Workgroup clients look up the “DNS domain name” from the DHCP server and then discover HRA from the “Domain SRV records” of that DNS server.

  With HRA Discovery, the client discovers HRA dynamically when it roams from one network to another. Also, to ensure that posture information is sent only to trusted HRAs, the NAP client always attempts an HTTPS connection with Server certificate validation. The NAP client communicates only with an HRA that has a certificate issued by the enterprise CA.

  HRA Discovery Setup

  Setting up HRA Discovery requires actions to be performed on the DNS server, the DHCP server, and the client.

  On the DNS Server: Add site SRV records (one for each HRA) as follows:

• DNS\<machine_name>\Forward Lookup Zones\<domain_name>\_sites\Default-First-Site-Name\_tcp

• SRV record name: “_hra”

• SRV record data: <HRA_machine_name>

  Also add Domain SRV records (one for each HRA) as follows:

• DNS\<machine_name>\Forward Lookup Zones\<domain_name>\_tcp

• SRV record name: “_hra”

• SRV record data: <HRA_machine_name>

  On the DHCP Sever: Add the DNS domain name and DNS Server in the Scope options of the DHCP server.

  On the Client: Enable HRA Discovery on the client using the following registry key:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\napagent\ LocalConfig\Enroll\HcsGroups

• EnableDiscovery REG_DWORD = 1

  Some Troubleshooting Steps

• The client will discover HRAs only if it is configured to do so, so verify that the client does not have any NAP configuration pushed down through Group Policy or configured locally.

• The client will send requests to the discovered HRA only if IPSec QEC is enabled.

• If the client fails to discover HRA, make sure that the client is able to contact the DNS server and look up the DNS records. Nnslookup can help in troubleshooting.

• In case of workgroup clients, make sure that the client has acquired an IP address from the correct DHCP server and that the client is able to look up the DNS records.

• On the server side, make sure that the DNS and DHCP records are configured properly.

• If the client discovers HRA correctly but fails to acquire a health certificate, investigate the following:

• Verify that there are no network issues that are preventing the client from being able to reach the discovered HRA.

• Verify that the discovered server is a trusted enterprise server.

• Verify that the discovered server is configured to accept SSL requests, as by default the client sends HTTPS requests to the discovered HRA.

  For further troubleshooting procedures, see the additional sidebars later in this chapter.

  –Harini MuralidharanSoftware Development Engineer in Test, Network Access Protection

TS Gateway Enforcement

TS Gateway is yet another NAP enforcement method-see Chapter 8, “Terminal Services Enhancements,” for more information about what TS Gateway is and how it works. 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.

Let’s hear from another expert at Microsoft to learn more about TS Gateway and NAP:

From the Expert: Better Together-TS Gateway, ISA Server, and NAP

Terminal Services–based remote access has long been used as a simpler, lower-risk alternative to classical layer 2 VPN technologies. Whereas the layer 2 VPN has often provided “all ports, all protocols” access to an organization’s internal network, the Terminal Services approach restricts connectivity to a single well-defined port and protocol. However, as more and more capability has ascended the stack into RDP (such as copy/paste and drive redirection), the potential attack vectors have risen as well. For example, a remote drive made available over RDP can present the same kinds of security risks as one mapped over native CIFS/SMB transports.

With the advent of TS Gateway, allowing workers to be productive from anywhere has never been easier. TS Gateway also includes several powerful security capabilities to make this access secure. In addition to its default encryption and authentication capabilities, TS Gateway can be combined with ISA Server and Network Access Protection to provide a secure, manageable access method all the way from the client, through the perimeter network, to the endpoint Terminal Server. Combining these technologies allows an organization to reap the benefits of rich RDP-based remote access, while mitigating the potential exposure this access can bring.

ISA Server adds two primary security capabilities to the TS Gateway solution. First, because it can act as an SSL terminator, it allows for more secure placement of TS Gateway servers. Because ISA can be the Internet-facing endpoint for SSL traffic, the TS Gateway itself does not need to be placed within the perimeter network. Instead, the TS Gateway can be kept on the internal network and the ISA Server can forward traffic to it. However, if ISA were simply performing traffic forwarding, it would be of little real security benefit. Thus, the second main security benefit ISA brings to the solution is application-layer inspection capabilities. Rather than simply terminating SSL traffic and forwarding frames on to the TS Gateway, ISA can perform advanced application layer inspection of the traffic to ensure that only desired IP frames are forwarded on to the TS Gateway. Using ISA as the SSL endpoint and traffic inspection device allows for better placement of TS Gateway resources and ensures that they receive only inspected, clean traffic from the Internet.

Although ISA Server provides important network protection abilities to a TS Gateway solution, it does not address client-side threats. For example, users connecting to a TS Gateway session might have malicious software running on their machines or be noncompliant with the organization’s security policy. To mitigate against these threats, TS Gateway can be integrated with Network Access Protection to provide enforcement of security and healthy policies on these remote machines.

NAP is included in Windows Server 2008 and can be run on the same machine as TS Gateway, or TS Gateway can be configured to utilize an existing NAP infrastructure running elsewhere. When combined with TS Gateway, NAP provides the same policy-based approach to client health and enforcement as it does on normal (not RDP-based) network connections. Specifically, NAP can control access to a TS Gateway based on a client’s security update, antivirus, and firewall status. For example, if you choose to enable redirected drives on your Terminal Servers, you can require that clients have antivirus software running and up to date. NAP allows organizations to ensure that computers connecting to a TS Gateway are healthy and compliant with its security policies.

–John Morello

Senior Program Manager, Windows Server Division