An Introduction to Network Access Protection (Part 2)

If you would like to read the other parts in this article series please go to:

• An Introduction to Network Access Protection (Part 1)
• An Introduction to Network Access Protection (Part 3)
• An Introduction to Network Access Protection (Part 4)
• An Introduction to Network Access Protection (Part 5)
• An Introduction to Network Access Protection (Part 6)
• An Introduction to Network Access Protection (Part 7)

In the first article in this series, I introduced you to some of the concepts involved in Network Access Protection. In this article, I want to begin discussing some of the underlying network requirements and various prerequisites. I will then demonstrate the configuration process.

The Network Access Protection Infrastructure

Implementing Network Access Protection requires the use of several servers, each performing a specific role. You can see what a sample deployment might look like in Figure A.

Figure A: Implementing Network Access Protection requires several servers to be used

As you can see in the diagram, the Windows Vista client is connecting to a Longhorn Server that’s running the Remote Access (RRAS) service. This server acts as the VPN server for the network. The Windows Vista client establishes a connection to this VPN server in the usual way.

When the remote user connects to the VPN server, the domain controller validates the user’s credentials. It is then the responsibility of the network policy server to determine what health policies are in effect, and what should happen if the remote client is out of compliance. In a lab environment, a single physical server could be used to host both the Routing and Remote Access Service role and the Network Policy Server role. In the real world, VPN servers exist at the network perimeter, and it is a bad idea to host the network policy server on a perimeter server.

The Domain Controller

If you look at the diagram shown in Figure A, you will see that one of the required servers is a domain controller. Don’t think of this as a single server, but rather as an entire Active Directory infrastructure. As I’m sure you know, the Active Directory cannot function without a DNS server. That being the case, if this diagram were a literal representation of an actual network, then the domain controller would be hosting the DNS services. Of course, in the real world organizations typically use multiple domain controllers and dedicated DNS servers.

Another factor to consider that may not be quite so obvious from the diagram is that an enterprise certificate authority is also required. In the case of this diagram, the certificate services could easily be hosted on the domain controller. In the real world, a dedicated server is often used as a certificate authority, because of the sensitive nature of digital certificates.

In case you’re wondering, the reason why an enterprise certificate authority is required is because the VPN server uses the PEAP-MSCHAPv2 protocol for authentication. The PEAP protocol is certificate based. The VPN server will use a server-side machine certificate, whereas remote clients will use user certificates.

Installing an Enterprise Certificate Authority

The procedure for deploying an enterprise certificate authority varies a little bit depending on whether you are installing the services on a Windows 2003 server or on a Longhorn server. Because one of my purposes in writing this article series is to familiarize you with Longhorn Server, the following procedure is intended for installing the certificate services on a Longhorn Server.

Before I show you how to install the certificate services, there are two things that you need to keep in mind. First, Longhorn Server is still in beta testing. Therefore, there’s always the chance that what I’m about to show you could change by the time the product is the ultimately released, although a major change this late in the development cycle is highly unlikely. 

The other thing to keep in mind is that in a real world deployment, you would want to go to extreme measures to make sure that your enterprise certificate authority is secure. After all, if someone were to compromise your enterprise certificate authority, they own your network. Because this article focuses on Network Access Protection, I’m going to show you just enough to get the certificate services up and running. In a real world deployment, you would want to put a whole lot more thought into the server’s configuration.

Begin the deployment process by opening Longhorn Server’s Server Manager and select the Manage Roles option from the console tree. Next, click the Add Roles link found in the Roles Summary section of the console. This will cause Windows to launch the Add Roles Wizard. Click Next to bypass the wizard’s Welcome screen. You will now see a list of all of the available roles. Select the Active Directory Certificate Server option from the list. Although it may appear that way at first, the roles are not listed in alphabetical order, so you may have to read through the whole list to find the service. Click Next to continue.

At this point, you will see a screen that introduces you to the certificate services and provides you with some words of caution. Click Next to ignore this screen and you will see another screen that asks you which components you want to install. Select the Certification Authority and the Certificate Authority Web Enrollment check boxes and click Next.

You will now see a screen that asks you if you would like to create an enterprise certificate authority or a standalone certificate authority. Choose the Enterprise Certificate Authority option and click Next. You will now be prompted as to whether this server should act as a Root CA or as a Subordinate CA. Since this is the first (and only) certificate authority in your lab, you should choose the Root CA option. Click Next to continue.

The Wizard will now ask you if you want to create a new private key or if you want to use an existing private key. Again, this is a lab setup, so choose the option to create a new private key and click Next to continue.

The next screen that you will encounter asks you to select a cryptographic service provider, a key length, and a hash algorithm. In a real world deployment these are all things that you would want to carefully consider. Since we are setting this certificate authority up solely for demonstration purposes, just go with the defaults and click Next.

The next screen that you will see gives you a chance to define a common name and a distinguished name suffix for the certificate authority. Again, just go with the defaults and click Next.

You should now see a screen asking how long the certificates should be valid for. The default time period is 5 years, which is fine for our purposes, so just click Next. The next screen that you will see asks you where the certificate databases and the corresponding transaction logs should be located. In a production environment, choosing an appropriate location is critical to fault tolerance and security. Since this is a lab, just go with the defaults and click Next.

You will now see a screen detailing the options that you have selected. Click the Install button and Windows will copy the necessary files and configure the underlying services.

Conclusion

Now that I’ve shown you how to configure the enterprise certificate authority, it’s time to begin configuration of the VPN server. I will show you how in Part 3.