Once you've designed an IPSec policy that meets your needs, you must deploy the IPSec policy to all Windows 2000–based computers that require the security provided by the IPSec policy. This lesson begins with an overview of the default IPSec policies that ship with Windows 2000 and then examines the following topics:
After this lesson, you will be able to
Estimated lesson time: 45 minutes
Windows 2000 includes three default IPSec policies that may or may not meet your organization's security requirements. The default IPSec policies are available in both a domain or workgroup environment and you can apply them locally or by using Group Policy.
The predefined IPSec policies are
In many cases you require custom IPSec policies. While the default policies enable IPSec protection for all network traffic, you may often need to add exclusions for specific protocols. For example, you don't need to enable IPSec protection for protocols, such as HTTP, that support application-layer security.
If modifications are required, create a custom IPsec policy instead of modifying the default policies. Modifying the default policies can result in unexpected behavior if you apply the modified IPSec policy and it doesn't function as expected.
You can restore the default IPSec policies in an MMC console by right-clicking the IPSec Policies On Local Machine or IPSec Policies On Active Directory console and then clicking Restore Default Policies. This action restores the default settings for the three default IPSec policies.
Table 12.11 shows the factors that influence your IPSec design to deploy the default IPSec policies.
Table 12.11 Choosing to Deploy the Default IPSec Policies
|Use||When Any of the Following Business Requirements Exist|
|Secure Server (Require Security)||The highest level of default security is required. This IPSec policy requires IPSec to be used for all protocols, except those that can't be protected by IPSec. |
All traffic sent to the server must be protected by using IPSec.
Fallback to unprotected data transmissions isn't desired.
Only Windows 2000–based computers are required to connect to the server.
You've placed all servers that require the IPSec configuration in the same organizational unit (OU) or OU structure.
|Server (Request Security)||All traffic sent to the server should be protected by using IPSec. |
Fallback to unprotected data transmissions will be supported for legacy clients.
The server must support a mix of Windows 2000 and non–Windows 2000–based clients.
You've placed all servers that require the IPSec configuration in the same organizational unit (OU) or OU structure.
|Client (Respond Only)||Enable the Windows 2000–based computer to use IPSec protection when requested by a server. |
You don't want the client computer to initiate IPSec protection.
You determine that all computers within an OU or OU structure are to be enabled for IPSec protection.
Fabrikam requires custom IPSec policies to meet its security objectives. The default IPSec policies don't meet the current security requirements. The one scenario where they could consider using a default IPSec policy would be for the data collection software.
If more than one laptop were used for data collection, the laptops could be assigned the Client (Respond Only) IPSec policy. This IPSec policy would enable the laptop computers to negotiate an IPSec SA when requested but still use unprotected transmissions to other servers.
If the Client (Respond Only) IPSec policy were enabled, you'd have to modify the IPSec policy applied to the server hosting the data collection software to accept unsecured communication but always respond using IPSec. This modification is required because the Client (Respond Only) IPSec policy would have the client send an unprotected packet initially to TCP port 5555. Only after the server responds would the IPSec SA be negotiated and established.
A workgroup environment can't depend on Active Directory for the consistent application of IPSec policies. In a workgroup environment, you can configure IPSec policies only by connecting to the local computer security settings.
You can achieve consistent IPSec configuration across similar computers by exporting properly configured IPSec settings to a .ipsec export file and importing the IPSec settings to all matching computers.
Although you can configure the IPSec policies through the Local Computer Security console, you can't configure IPSec settings through security templates. Security templates don't contain information for IPSec policies. Because of this, you can't use the Secedit command to ensure consistent application of IPSec policy. You must manually inspect IPSec policies at periodic intervals.
When designing IPSec deployment in a workgroup environment, include the following tasks in your IPSec deployment design:
The two tunnel servers may not be members of the domain at Fabrikam or A. Datum Corporation. Because the tunnel servers aren't members of the domain, you must define the IPSec policy in the local computer policy for each tunnel server.
Because each site has only one tunnel server and the rules are different at each server, it would be best to deploy the IPSec policy by manually configuring the IPSec policy at each tunnel server.
Active Directory enables an administrator to standardize IPSec configuration by applying IPSec policies in Group Policy objects. You can define IPSec policies for the site, domain, or OU to ensure that all computer objects within the container have consistent IPSec policies applied.
The use of Group Policy ensures that a computer's administrator can't override the desired IPSec settings at the local computer. The settings inherited from Group Policy always supersede local policy settings.
You can't use security templates to define IPSec policies. Security templates don't include settings for IPSec policy definition. To define IPSec policies, create the IPSec policy at a stand-alone computer and then export the settings to a .ipsec export file. The export file can then be imported into the Group Policy object where you wish to deploy the IPSec policy.
In an Active Directory environment, consider the following when designing your IPSec deployment:
If Fabrikam were to deploy additional laptops, the best strategy would be to place all of the Windows 2000–based laptops in a common OU. By doing this, you can define a Group Policy object that applies the custom IPSec policy.
The Group Policy object takes precedence over any domain settings or local settings defined directly at the laptop computers and ensures that a consistent IPSec policy is applied to all laptops running the data collection client software.
At the Washington office, you could place the data collection server in a separate OU or have the Group Policy object that defines the IPSec policy applied with a filter so that only the data collection server applies the Group Policy object. This action ensures that the policy is consistently applied to the data collection server and that the local computer policy can't be changed to lessen the security for the data collection software.
IPSec gives two computers entering into a SA the ability to authenticate with certificates. In a Windows 2000 network, only domain controllers (DCs) acquire certificates by default. If you wish to use certificates for authentication, you must either manually configure each computer with the necessary certificate or enable automatic certificate enrollment.
You configure automatic certificate enrollment within Group Policy objects, as shown in Figure 12.20.
Figure 12.20 Configuring automatic certificate enrollment for an IPSec certificate
You can apply the Group Policy object at the site, the domain, or the OU to deploy the certificate automatically to all computer accounts within the container. A CA trusted by both computers in the SA must issue the certificates. In other words, the issuing CA must be a trusted intermediate CA and the root CA in the CA hierarchy must be a trusted root CA.
To enable IPSec, you can choose one of three certificate templates:
Consider the following points when designing certificate-based authentication for IPSec:
In the Fabrikam scenario described at the beginning of the chapter, the tunnel servers probably wouldn't be members of the organization's domains, so you couldn't configure automated certificate deployment. But if you decided to use certificate-based authentication for the data collection software IPSec solution, then you could configure automatic certificate requests.
As with the IPSec policies, you could apply Group Policy at the OU containing the laptops and at the OU containing the data collection server. For the laptops, you could define the autoenrollment certificate request to issue either IPSec or computer certificates. Because no other projects are defined that require a PKI for Fabrikam, the securest solution would be to issue an IPSec certificate to the computers. This would require ensuring that the Discretionary Access Control List (DACL) for the IPSec certificate template is modified to allow the laptops the Read and Enroll permissions for the IPSec certificate template. Additionally, an existing CA must be configured to issue the IPSec certificates. With this configuration, all laptops located in the OU will automatically request an IPSec certificate when the computer account is authenticated at startup or when Group Policy settings are refreshed at the regular interval.
Sometimes an IPSec design doesn't work as expected. When this occurs, you can use several tools use to determine why an IPSec SA isn't being established. These tools include
Figure 12.21 Current SAs as shown in the IPSec monitor
By default, Oakley logs aren't enabled. You must add the value EnableLogging to the registry in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley key. The REG_DWORD value must be set to a value of "1" to enable Oakley logging.
Table 12.12 lists some potential IPSec connection problems and the tools you use to troubleshoot them.
Table 12.12 Troubleshooting IPSec Connection Problems
|Use This Strategy||To Perform These Actions|
|Ping||Determine if authentication is working between the two IPSec hosts. Change the IPSec filter to encrypt only ICMP packets. If the encryption of ICMP packets works, you probably have a filter definition problem and must edit your original IPSec filter settings.|
|A preshared key||Determine if the filter is working correctly. A preshared key is the least complex form of authentication and ensures that you only have to troubleshoot your filter definition.|
|IPSec Monitor||Determine if a SA is established between your computer and the target computer. |
Determine which protocol is protected with IPSec.
Review statistics for IPSec usage to determine if errors are occurring.
|Netdiag||Determine which IPSec policy is currently assigned to the computer. |
Determine which filters are in use for the IPSec SA.
Determine which authentication protocol is used for the SA.
|SMS Network Monitor||Look at the packet level to determine if the ISAKMP process is taking place. |
Determine if the ISAKMP process is successful. You determine this by looking for AH and ESP protocol packets.
|Oakley logs||Determine errors found during the ISAKMP negotiation between two computers. |
Only use as a last resort for troubleshooting IPSec configuration errors.
The scenario mentions that the tunnel servers were suffering from authentication errors during testing of the tunnel. This could be because the certificates issued to the tunnel servers aren't being recognized by the other organization's tunnel server. To troubleshoot the problem, complete the following steps:
After defining your IPSec policies, you must deploy the IPSec policies to the necessary computers in your network. Take advantage of Active Directory to ensure that IPSec policies are applied consistently to similar computers on the network. Group Policy ensures that the proper IPSec policies are applied and that local computer settings don't change the IPSec policies assigned to a computer.
Once you have the policies assigned, ensure that the IPSec SA is functioning as expected. If it isn't, know what tools you can use to troubleshoot the problem. Ensure that you use a structured approach to troubleshooting so that each step of the way you eliminate potential configuration issues and narrow the problem down to a likely source.