Lesson 2: Planning an IPSec Infrastructure | MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)

< Day Day Up >

You could enable IPSec for your entire domain with a few mouse clicks-but it would not be wise. If configured incorrectly, IPSec can cause minor problems, such as a network application that performs poorly, or major problems, such as total loss of network connectivity. Only careful planning can ensure the success of an IPSec deployment. That planning involves choosing an authentication method, deciding how to manage IPSec's integration with Active Directory, and devising a testing procedure to validate application compatibility with your planned IPSec configuration.

After this lesson, you will be able to

Describe the considerations for deploying IPSec integrated with an Active Directory domain.
List the various authentication methods that IPSec in Windows Server 2003 can use, and list the advantages and disadvantages of each.
Explain the importance of thoroughly testing applications with IPSec, and explain the most critical steps to take during the testing process.

Estimated lesson time: 20 minutes

Active Directory Considerations

For organizations with large numbers of computers that must be managed in a consistent way, it is best to distribute IPSec policies by using Group Policy objects (GPOs). Although you can assign local IPSec policies to computers that are not members of a trusted domain, distributing IPSec policies and managing IPSec policy configuration and trust relationships is much more time-consuming for computers that are not domain members.

Another advantage of using Active Directory-based IPSec policy is that you can delegate permissions on the IP Security Policies On Active Directory container to enable specific administrators to manage IPSec throughout your organization. These administrators do not necessarily need permissions to directly manage the individual computers that will receive the IPSec policy, however. This capability is vital to organizations that divide responsibility for security tasks between various groups.

To delegate permissions on the IP Security Policies container, you must use an Active Directory editing tool, such as ADSI Edit. ADSI Edit is a Windows support tool that uses the Active Directory Service Interfaces (ADSI). The Windows support tools can be installed from the \Support\Tools folder on the Windows 2000 and Windows Server 2003 operating system CDs.

An IPSec policy administrator typically requires Write access to all IPSec policy objects. You should not attempt to assign permissions to individual IPSec policies. If many administrators in your organization want to manage Active Directory-based IPSec policy, you should channel all IPSec changes through existing Domain Admins. The individuals making the changes to IPSec policy can configure local IPSec policy on a computer in a lab environment, and then use IP Security Policy Management to export an IPSec policy file for the domain administrator or another delegated administrator. The Domain Admin can then import the IPSec policy file into the IP Security Policies On Active Directory container. This practice minimizes the number of administrators who can modify IPSec policy, which decreases the risk of human error negatively affecting IPSec policy.

Although an Active Directory-based IPSec policy might be suitable to help secure most communications for a group of servers, you might need to customize an IPSec policy for a specific server. You can do this by using a Windows 2000, Windows XP Professional, or Windows Server 2003 IPSec command-line tool to create a dynamic IPSec policy. Lesson 3 has more information about using command-line tools to configure IPSec policy.

Authentication for IPSec

Peer authentication is the process of ensuring that an IPSec peer is the computer it claims to be. By using peer authentication, IPSec can determine whether to allow communications with another computer before the communication begins. You can choose from three authentication methods: Kerberos v5, public key certificates, and preshared keys.

If you have deployed a Windows 2000 or Windows Server 2003 Active Directory environment, and all hosts that will be using IPSec are part of that domain (or a member of a trusted domain), then you should use Kerberos. If you are communicating with outside organizations, and your partners use a Web-based CA, you can use public key certificates. If neither of these methods is available, you can use a preshared key.

Kerberos v5 authentication

Kerberos v5 is the default authentication standard in Windows Server 2003 and Windows 2000 domains. This method of authentication can be used by any computer in the domain or a trusted domain. Kerberos is the most natural form of IPSec authentication, and configuration is straightforward and simple. However, there are a couple of important considerations.

First, earlier versions of Windows automatically allowed Kerberos traffic through IPSec filters. However, Windows Server 2003 will drop Kerberos packets if an IPSec rule determines that the traffic should be blocked. If you want to enable Kerberos authentication, you must create filters in the IPSec policy that explicitly allow all traffic to your domain controllers.

Second, for IPSec to use Kerberos authentication across a cross-forest trust, you must use fully-qualified domain names to configure the trusts. In addition, you must configure the IPSec client policy to allow communication to any domain controller in the forest domain hierarchy so that IPSec can obtain a Kerberos ticket from a domain controller in the IPSec peer's domain.

Public key certificates authentication

A public key infrastructure (PKI) can be used to authenticate and encrypt communications for a wide variety of applications, including Web applications, e-mail, and IPSec. Although using public key certificates is not as convenient as using Kerberos, there are specific circumstances for which certificates are the logical choice for authentication in IPSec. Specifically, you should use public key certificates when you need to communicate privately with external business partners or other computers that do not support the Kerberos v5 authentication protocol.

IPSec's use of certificate authentication is compatible with many different PKI architectures, and IPSec places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use IPSec authentication. To use certificates for IPSec authentication, you define an ordered list of acceptable root CA names in the authentication method. This list controls the certificates that IPSec can select and the certificates that IPSec will select.

If IPSec authentication fails, you cannot retry the authentication using a different method. For this reason, before you apply an IPSec policy that can use certificates for authentication, make sure that all target computers have the correct root CA certificates and relevant cross-certificates, in addition to valid computer certificates. Additionally, to ensure that certificate authentication works as intended, test your PKI infrastructure with various IPSec policy configurations before deployment.

In Windows 2000 and Windows Server 2003, you can use Certificate Services to implement the root CA. Certificate Services is integrated with Active Directory and Group Policy, and it simplifies certificate deployment by enabling certificate auto-enrollment and renewal and by providing configurable certificate templates. In addition, by publishing the computer certificate as an attribute of the domain computer account, Certificate Services allows you to use IPSec to restrict access to network services.

Preshared key authentication

If both IPSec peers are not in the same domain and do not have access to a CA, a preshared key can be used. For example, a standalone computer on a network that does not connect to the Internet might need to use a preshared key, because neither Kerberos authentication through the computer's domain account nor access to a CA on the Internet is available. A preshared key is a shared secret key (basically a password) that has been agreed upon by administrators who want to secure the computers' communications by using IPSec. Administrators must manually configure their systems to use the same preshared key.

The preshared key authentication method uses symmetrical encryption to authenticate the hosts, which itself is very secure, but which requires that any two hosts communicating have been configured with a predefined password. Unfortunately, this key is not stored securely on the IPSec hosts. The authentication key is stored in plaintext format in the system registry and hex-encoded in Active Directory-based IPSec policy. If attackers can access your registry, they can find your preshared key, which would allow them to decrypt your traffic or impersonate one of the hosts. Use preshared key authentication only when no stronger method can be used.

If you must use preshared key authentication, use a local IPSec policy, a 25-character or longer random key value, and a different preshared key for each IP address pair. These practices result in different security rules for each destination and ensure that a compromised preshared key compromises only those computers that share the key.

Testing IPSec

As a rule, you should perform extensive testing before making any changes to your infrastructure. This rule certainly holds true when planning to use IPSec. IPSec has the potential to interfere with all network communications and, as a result, can break any network applications that your organization uses.

Begin testing IPSec in a lab environment. Configure computers with the client- and server-side of your critical applications, and verify that the lab is functional and accurately simulating the production environment. Your lab environment should have computers with each of the potential IPSec client operating systems, because different operating systems support different IPSec functionality. Develop performance metrics for each of your applications, and gather baseline performance data that you can use for comparison after IPSec has been implemented. Then implement IPSec policies on the lab computers.

Not all network equipment provides the same IPSec capabilities, and you should use the testing phase to determine which network devices need configuration changes or upgrades. Add firewalls, proxy servers, and routers to the lab environment to simulate the potential for those devices to interfere with IPSec communications in the production environment. If you plan to use IPSec for remote access, be sure to include a remote access client in your lab environment, and have that client connect from a typical remote network. If employees will use IPSec to connect to your internal network from home, test IPSec across a variety of commonly used home routing equipment. Test non-IPSec-enabled clients with IPSec-enabled servers. Even if you plan to deploy IPSec to every computer, there will be a transition period during which some computers will not yet have received the IPSec configuration.

After IPSec clients and network equipment have been configured in the lab environment, test the application functionality. If you identify problems, document the problems and solutions so that they can be quickly resolved if they appear in the production environment. Besides verifying that applications function, verify IPSec functionality. If you allow IPSec clients to use unsecured communications if IPSec negotiations fail, it is possible for applications to appear to be compatible with IPSec when the computers were unable to establish an IPSec session.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the 'Questions and Answers' section at the end of this chapter.

You are an administrator at an organization that uses Windows Server 2003 Active Directory. Which IPSec authentication method should you recommend for authenticating internal clients to an intranet Web server?
1. Kerberos authentication
2. Public key certificates authentication
3. Preshared key authentication
You need to grant employees at an external partner company access to an application server, but you want to ensure that the communications are authenticated and encrypted. Which IPSec authentication method should you recommend?
1. Kerberos authentication
2. Public key certificates authentication
3. Preshared key authentication

Lesson Summary

You should use GPOs to deploy IPSec whenever practical. However, you should limit access to modify the IPSec policies to the smallest number of administrators possible to reduce the opportunity for both human error and abuse.
Use Kerberos authentication when all IPSec peers are members of a trusted Active Directory forest.
Use public key certificates for IPSec authentication when Active Directory does not exist or when some computers are external to your organization.
Use preshared key authentication only when neither Kerberos nor public key certificates can be used to authenticate IPSec connections.

< Day Day Up >