As previously mentioned, it is wise to deploy a certificates-based approach to L2TP VPN connections to maintain the highest levels of security and control over VPN access. To deploy this type of environment, a Public Key Infrastructure (PKI) must be set up. PKI provides a mechanism by which individual encrypted certificates are distributed to individual computers to validate their identity.
Remember that L2TP/IPSec requires the ISA Server's public interface to be directly addressednot behind any type of Network Address Translation (NAT)for this type of VPN connection using PKI certificates to take place. The one exception to this case is if the systems providing the network address translation capability are compliant with the recent RFCs for NAT traversal (RFCs 3947 and 3948). Because this is a relatively new technology, it may take a few years for common acceptance of this practice, however.
PKI environments can be set up in a number of ways, with Microsoft and third-party products providing for robust implementations. The Microsoft implementation of PKI is installed on Windows Servers and involves the deployment of a Windows certificate authority. The two primary configurations for a Windows certificate authority (CA) are enterprise and stand-alone.
It is recommended that an organization with an existing Active Directory infrastructure implement an enterprise CA primarily because of the integration with Active Directory. By leveraging group policies with the enterprise CA, an administrator can automatically provision certificates to domain members, certificates being the key element in a L2TP/ IPSec VPN configuration. With a stand-alone or commercial CA, the certificate provisioning process is manual, requiring a specific process to be performed for each VPN client and server.
A PKI design process is complex, and should not be taken lightly. In addition, a Windows certificate authority implementation can be utilized for numerous applications and services in addition to VPN support, so it is recommended that you put careful thought into the design and implementation of a PKI infrastructure.
Installing the Enterprise Root Certificate Authority (CA)
If a PKI Infrastructure is not already in place, the Microsoft implementation can be set up and configured in the internal environment. The following steps can be used to install Microsoft Internet Information Services (IIS) and the certificate authority on a domain member. Note that a CA should not be setup on the ISA Server itself, and IIS should never be set up on ISA (with the possible exception of the SMTP component of IIS in certain circumstances). IIS is required to support the certificate enrollment website and must be installed on the same system as the CA to provide for web certificate enrollment.
Configuring the Enterprise Root CA
If using an enterprise certificate authority, and supporting non-domain members, such as an ISA Server that is a member of a workgroup, then a template to allow machine certificates should be added and configured to allow provisioning through the web enrollment page. This is common when supporting a mix of domain members and non-domain members.
The following steps can be used to configure the existing enterprise certificate authority with a new computer certificate template.
This process is not required and is not possible with a stand-alone certificate authority because the Client Authentication and Server Authentication certificates are already available by default.
The previous steps enable machine certificates to be issued through the web enrollment page, using the default settings. This is required when certificates need to be installed on non-domain members. It is highly recommended to research and configure the remaining options as required by company policy.
Now that the template has been created it must be added to the list of templates available to the enterprise CA. The following process can be used to accomplish this:
The enterprise certificate authority is now ready to provision machine certificates through web enrollment.
Requesting a Certificate for the ISA VPN Server
The process of requesting a certificate from a private internal certificate authority or a public certificate authority generally follows the same principles when the ISA server has been implemented as a stand-alone workgroup member.
Before starting the certificate enrollment process, it is important to add the certificate server to the trusted Internet security zone of the web browser on the ISA Server. In addition, there must not be any rules set up on the ISA server that block access from the local host to the web server with the CA installed on it.
The following process can be used to request a certificate for the ISA server. This can be performed from the system that will have the certificate installed on it, but that is not a requirement. If this is performed on a different system, after the certificates have been created they need to be exported and then imported to the correct system.
For this process to work properly, the certificate web enrollment server must be accessible via ISA's system policy rules, which normally restrict the ISA Server's capability to read web pages on servers. For more information on the system policy, refer to Chapter 5, "Deploying ISA Server 2004 as a Firewall."
The following procedure can be used to create the initial certificate request:
A certificate has now been installed in the system's local computer certificate store. The process to move this certificate to another system is discussed later in this chapter.
Requesting a Certificate for the VPN Client
The same process can be used to generate a certificate for a VPN client. Although a certificate can be generated for both a member and a non-member, it is not recommended to configure domain members this way. It is much more efficient to configure the group policy Autoenrollment, which automatically distributes the proper certificates to computers that are members of an Active Directory domain. To manually add the certificate to the client, perform the following steps:
A certificate for the VPN client has now been installed in the local computer certificate store of the VPN client. The process to move this certificate to another system is discussed later in this chapter.
Downloading the CA Certificate
After the client(s) and ISA Server have been enrolled and a certificate has been generated, it must then be downloaded and added to the Trusted Root Certification Authorities local store on each device.
An advantage to using an enterprise CA is that the CA certificate is automatically added to the local certificate store on all domain members; only nondomain members are required to add the certificate. A stand-alone CA certificate is added to the local certificate store on domain members only if it is installed on a domain controller. Otherwise this certificate needs to be added to all systems that will establish a L2TP/IPSec VPN tunnel.
This file is not required to be protected and can be freely distributed via any method including email. This is only the CA's public keynot the private key. For example, many commercial CAs' public keys are distributed with Internet Explorer.
Exporting and Importing Certificates
If all the certificates were created through the certificate enrollment page, either with the enterprise CA or the stand-alone CA, from the same computer, they must then be exported to removable media and imported into the local certificates store.
To view the local certificate store on a client or a server, a Microsoft Management Console (MMC) session must be set up. Follow the steps outlined here to perform this function:
One MMC console can be set up to manage all the different systems that require certificates. This option is usually not available because the VPN server is protected with a firewall, so the certificates may have to be transferred on portable, erasable media.
The certificates that are to be exported contain both the private and public key. It is extremely important to make sure the process that is used to transfer the certificates from one system to another is secure and the media is destroyed afterwards. Compromising the private key can render the encryption used in the VPN tunnel useless. In many cases, this transfer takes place at a trusted location, such as a laptop staging area of a help desk, to avoid compromise of the key.
To export the certificate, perform the following steps:
Repeat the previous process for each of the server and client certificates created. Use the following process to import the certificates to the required systems.
Repeat the entire process of importing the certificate and the CA certificate for the remaining VPN servers and client systems.
Using Active Directory Autoenrollment
When VPN clients are members of the internal domain and a PKI infrastructure has been deployed, the easiest and most secure method to get certificates on a workstation is through the process of group policy autoenrollment. The autoenrollment process automatically requests and maintains a certificate for the computers and servers.
As beneficial as autoenrollment may be, many prerequisites must be in place for it to work. These prerequisites are as follows:
If these prerequisites are satisfied, the following process can be used to configure auto enrollment.
The following steps describe autoenrollment configuration steps using the Group Policy Management Console (GPMC) tool, which is a downloadable add-on to Windows Server 2003. Although the same settings can be accomplished with the built-in tool, it is highly recommended to download and install GPMC. It greatly extends the management capabilities of group policies. The tool can be downloaded at the following URL:
The machine requests the certificate during login or during the next group policy refresh cycle. Use the GPUPDATE.EXE command to refresh the group policy. The simplest method to invoke the autoenrollment process is just to restart the system. Look for event 19, from source Autoenrollment, in the event log of the local system to see whether the process was successful. The Certificates snap-in can also be used to view the newly acquired certificate on the client, and the Certification Authority console can be used to view newly provisioned certificates.