An Introduction to Network Access Protection (Part 1)

An introduction to Network Access Protection and how it works.

One aspect of network security that is frustrating for many administrators is that they have no control over the configuration of remote computers. Although the corporate network might be running a highly secure configuration, there is presently nothing to prevent remote user from connecting to the corporate network using a computer that is infested with viruses or that contains outdated patches. Longhorn Server’s Network Access Protection feature will change all this. In this article series, I will introduce you to Network Access Protection and show you how it works.

When I was a network administrator one of the things that really frustrated me was how little control I have over remote users. My organization’s business requirements mandated that remote users be able to connect to the corporate network from locations outside of the office. The problem was that although I had gone to extreme measures to secure the corporate network, I had absolutely no control over the PCs that users would use to connect to the network remotely. After all, a user’s home computer is not company property.

The reason why this was so frustrating was because I never knew what type of condition a remote user’s computer would be in. Sometimes remote users would connect to the network using a PC that was infested with viruses. Other times, a remote user’s PC might be running an ancient version of the Windows operating system. Although I took steps to secure a corporate network, I was always afraid that a remote user with inadequate protection would infect files on the network with a virus, or would inadvertently disclose sensitive information because their PC was infected with some kind of Trojan.

Several years ago there was a ray of hope though. As Microsoft prepared to release Windows Server 2003 R2, there was talk of a new feature called Network Access Protection. To make a long story short, some of the early builds practically required you to have a Ph.D. in computer science in order to configure Network Access Protection. As such, the Network Access Protection feature was removed prior to R2 being released.

Microsoft has done a lot of work on Network Access Protection since that time, and Network Access Protection will be one of the key security features in Longhorn Server. Although the Longhorn version of Network Access Protection is going to be much easier to configure than the ill-fated Windows Server 2003 version, it is still somewhat complicated. Therefore, my purpose in writing this article series is to give you an introduction to Network Access Protection, and show you how it works before Longhorn Server is released.

Before I Begin

Before I get started, there is one thing that I want to clarify in regards to Network Access Protection. The Network Access Protection feature’s purpose is to make sure that remote user’s computers comply with your organization’s security requirements. Network Access Protection does nothing to prevent unauthorized access to your network. If an intruder has a PC that complies with your corporate security policy, then Network Access Protection will do nothing to try to stop that intruder. Preventing the intruder from gaining access to network resources is the job of other security mechanisms. Network Access Protection is simply designed to prevent legitimate users from logging onto your network using insecure PCs.

One more thing that I want to mention before I get started is that Network Access Protection is different from the Network Access Quarantine Control feature found in Windows Server 2003. Network Access Quarantine Control provides limited health policy control for remote computers, but is inferior to Network Access Protection.

The Fundamentals of Network Access Protection

Network Access Protection is designed to augment a corporate VPN. The process begins when clients establish a VPN session with a Longhorn Server that is running the Routing and Remote Access service. After the user establishes a connection, a network policy server validates the remote system’s health. This is done by comparing the remote computer’s configuration against a network access policy defined by the administrator. What happens next depends on the policy that the administrator has configured.

The administrator has the option of configuring either a monitoring only policy or an isolation policy. If a monitoring only policy is in effect then any user with a valid set of credentials will be given access to network resources, regardless of whether or not their PCs is in compliance with the corporate security policy. Although a monitor only policy will not prevent any PCs from gaining access your network, the compliance state each remote PC attempting a connection will be logged.

In my opinion, a monitoring only policy is best suited for making the transition to a Network Access Protection environment. Think about it for a second, if you’ve got remote users who need to be able to access resources on your corporate network in order to do their jobs, you probably don’t want to initially enable Network Access Protection in isolation mode. If you do, there is a good chance that none of your remote users will be able to access your corporate network. Instead, you can initially configure Network Access Protection to use a monitoring only policy. This will allow you to gauge the impact of your network access policies without accidentally preventing anyone from being able to do their job. Once you have all the kinks worked out you can switch the policy to isolation mode.

As you probably already guessed, isolation mode works by placing remote computers that do not comply with the corporate security policy onto an isolated network segment away from the resources on your production network. Of course this is a general statement. It’s ultimately up to the administrator to control what a user with a non-compliant computer can actually access. Normally an administrator will give users with noncompliant machines access to an isolated network segment, which I will talk about more in a moment. The administrator does however have the option of limiting access to a single resource or of preventing access to all network resources.

Right now you may be wondering what the advantage is of granting noncompliant computers access to an isolated network segment. When a non-compliant computer attaches to the network, and Network Access Protection is running in isolation mode, the noncompliant computer is quarantined from the production network. Normally this quarantine lasts for the duration of the user’s connection. Simply quarantining a noncompliant machine might help prevent viral infections or security breaches on your network, but it doesn’t do the remote user a whole lot of good. After all, if the user cannot connect to resources on the network, they cannot do their job.

This is where the isolated network segment comes into play. An administrator can place health update resources on to the isolated segment. These health update resources are secured servers whose job it is to bring the noncompliant remote computer into compliance. They might for example install security patches or antivirus updates.

One thing that is important to note is that Network Access Protection does not contain any mechanisms that are capable of verifying a remote computer’s health or applying updates to a remote computer. This will be the job of System Health Agents and System Health Validators. Rumor has it that these components will be integrated into the next version of SMS Server.

How to configure Windows 2008 Server IP Routing

Introduction

With Windows Server 2008, there are a number of changes to networking and Routing and Remote Access. In fact, I wrote about some of these changes in my WindowsNetworking.com article: Which Windows Server 2008 Networking Services were removed and which should you use instead? In that article, I covered how OSPF is no longer part of Windows Server 2008. I find that unfortunate because I think that OSPF is likely the best dynamic routing protocol ever created. Still, I can also partially understand Microsoft’s decision to remove it as I would venture to guess that 99.9% of Windows Server Admins never used it. So what are we left with?
With the removal of OSPF, we are left with either 1) static routing or 2) dynamic routing with RIPV2. Let’s find out how each of these work.

Should you use static or dynamic routing?

The question of whether you should use static or dynamic routing is really a question of administrative overhead. In the end, the result of your network traffic being routed to the correct network should be the same, no matter what method you choose.
With static routing, you must make an entry on your Windows Server for every network that will be routed by that server. Thus, for a simple network with a single windows server, routing traffic between two networks, static routing is a “no brainer”. You could configure it with two simple route add commands.
On the other hand, on a network where you want the Windows Server 2008 system to route for 25 networks or to exchange routes with a Cisco network that uses RIP, you will want to choose dynamic routing. Obviously, you do not want to have to key in those 25 networks manually nor can you provide the true dynamic features that RIP provides.
Speaking of that, what does dynamic routing provide you? Let’s list out some features.

• Ability to automatically add networks by learning them from other RIP routers
• Ability to automatically remove routes from the routing table when other RIP neighbors delete them
• Ability to select the best route based on routing metrics
• Reduce configuration of Windows Server routing systems that have more than a few static routes that need to be added

So how do you configure static and dynamic routing in Windows Server 2008?

Static Routing in Windows Server 2008

Static routing in Windows Server is nothing new. We have been using the route command for years. You can configure static routing in Windows 2008 Server using either the route command or using the GUI. However, if you use the Windows GUI interface, those routes will not be listed in the CLI interface, when you type route print. Thus, I highly recommend that if you are going to use static routing in Windows 2008, you just use the route command at the windows command prompt.
So let’s look at some examples of how you configure static routing using the route command:
Show the static routing table
Showing the static routing table is easy, just use the route print command, as you see in Figure 1 below.

Figure 1: Showing the IP Routing table in Windows Server 2008
In the route print output, the first important thing that you see is the interface list. Windows Server IP interfaces are labeled with an interface number. The interface numbers in Figure 1 are 16, 14, 1, 15, 20, and 12. These interface numbers are used whenever you add or delete routes to the routing table.
The second important thing in the route print output is the IPv4 Routing Table. This shows us the network destination, network mask, the default gateway, interface, and metric. This table tells the Windows Server where to route the traffic.
Below that is the IPv6 routing table. For more information on IPv6, I recommend Brien Posey’s articles Crash Course in IPv6 (Part One) & Crash Course in IPv6 (Part Two) and Mitch Tulloch’s article IPv6 Support in Microsoft Windows.
Add a static route
So how do you add a static route at the command line? The answer is easy- use the route add command, like this:
route add 1.1.1.0 mask 255.255.255.0 10.0.1.1 if 1
As you see in Figure 2, the results of our route add was an affirmative “OK!”

Figure 2: Using the route add command in Windows 2008
What was important in the route add command was the network we want to add, its subnet, the destination/gateway, and the interface for that route.
Delete a static route
Deleting a route is even easier than adding a route. All you have to do is to tell route delete the network that you want to remove, as you see in Figure 3.

Figure 3: Using the route delete command in Windows 2008
So those are the basics of configuring static routes at the command line. Now let’s learn about configuring dynamic routing.

Dynamic Routing in Windows Server 2008 using RIPV2

Earlier in the article, I talked about the benefits of configuring dynamic routing. So, now let me provide you the steps to configuring RIPv2 in Windows 2008:

1. The first step is to install the Routing and Remote Access (RRAS) role in Windows 2008 Server. If you go into the Add Roles Wizard, the RRAS role can be difficult to find because what you really need to add is the Network Policy and Access Services role then the Routing and Remote Access Services Role (as you see in Figure 4 and Figure 5).

Figure 4: Adding the RRAS Role through he Network Policy and Access Services

Figure 5: The Win 2008 Role Services are part of the Network Policy and Access Services Role
Once installed you can configure RRAS from the Server Manager application but I prefer the Routing and Remove Access application.

2. The second part of this is to Configure Routing and Remote Access by opening the RRAS MMC, right-clicking on the server name, and clicking Configure and Enable Routing and Remote Access, like this:

Figure 6: Configuring and Enabling RRAS
Make sure that you do a Custom Configuration concerning what RRAS protocol to install. Then, choose to install LAN ROUTING then choose to start the service.
From there, you can see the Network Interfaces controlled by RRAS and specific configurations for IPV4 and IPV6.
At this point, you can expand IPV4, go to General, then to New Routing Protocol.

Figure 7: Adding a new Routing Protocol
Next, choose to install RIPV2 as your routing protocol.
Figure 8: Adding RIP V2

3. Now that you have RIPv2 installed, you can configure it. Configuring it is really as easy as adding the interfaces that you want to use to exchange RIP routes with. To do this, go to the RIP section, right click, click on New Interface, select the interface you want to add under RIP as you see in Figure 9.

Figure 9: Adding a new RIP interface

4. After selecting the interface, you have the option to configure a wide variety of RIP connection properties (as you see in Figure 10). There is more to configuring RIP than I can go into in this article as RIP configuration can either be very simple or it can become very complex.

Figure 10: Configuring the new RIP interface

5. Once you have your RIP interfaces added, you can check to see if you are sending and receiving responses on your RIP interfaces (you should be). You can also check to see if you have any RIP neighbors by right-clicking on the RIP protocol, then clicking Show Neighbors.

Before I conclude this section about RIP in Windows, I want to point you to a couple of excellent resources I used while preparing for this article:

1. Recently I was watching Ed Liberman’s Train Signal Windows 2008 Network Infrastructure video. In that video, besides explaining routing and the differences between static and dynamic routing, Ed shows, step by step, how to configure RIPv2 in Windows 2008. I found the video very helpful and recommend it to you whether you just want to learn about Win 2008 and routing or if you are looking to pass Microsoft’s Windows 2008 Network Infrastructure exam (70-642). Here is a screenshot of Ed configuring RIPV2:

Figure 11 Train Signal’s Windows 2008 Video on how to install and configure RIPV2

2. Over at the Petri IT Knowledgebase, I wrote an article on how to configure it in Windows 2003, then another article on how to exchange routes between a Cisco router and a Window Server. While not pertaining to Win 2008, the process of configuring RIP on Win 2003 is similar and the configuration to exchange routes with a Cisco router is very relevant: