2.2.1 IPsec Policy Creation/Modification

This section specifies how the IPsec Group Policy administrative plug-in creates and modifies an IPsec policy that is stored in Active Directory.

This section also provides background information that is needed to understand the storage of IPsec policy settings that are contained both within Group Policy Objects (GPOs) and the IPsec policy data that is contained within an IPsec-specific Active Directory data store. It also specifies how individual IPsec policy data items are written and modified in a generic policy store (in this case, Active Directory).

The following figure specifies the IPsec policy storage. IPsec policy storage deviates from the typical Group Policy storage mechanism as specified in [MS-GPOL] by storing the IPsec policy data separately from the GPO. The GPO contains a reference to the actual IPsec policy that is assigned to the policy target accounts, as specified in [MS-GPOL] section 1.3.3, "Policy Application".

An IPsec policy is created by writing the appropriate IPsec policy attributes to the "System\IP Security" container. The policy can then be assigned by writing a "reference" to the policy data in the "System\Policies\GPO-GUID\Machine\Microsoft\Windows\IPSEC" container. Note that the GPO_GUID text MUST be replaced by a curly braced GUID string ([MS-DTYP] section 2.3.4.3, "GUID--Curly Braced String Representation") that identifies the GPO.

The reference of the policy that is assigned to a GPO MUST be stored in the "Machine\Microsoft\Windows" container in the IPSEC object of the GPO for this Group Policy protocol. IPsec Policy Assignment is specified in section 2.2.2.

Figure 6: IPsec policy storage

The actual IPsec policy creation and modification protocol consists of writing a series of messages that create or modify the ipsecPolicy, ipsecISAKMPPolicy, ipsecNFA, ipsecNegotiationPolicy, and ipsecFilter entries (and the associated attributes as specified in [MS-ADSC] section 2.71, "Class ipsecFilter", [MS-ADSC] section 2.72, "Class ipsecISAKMPPolicy", [MS-ADSC] section 2.73, "Class ipsecNegotiationPolicy", [MS-ADSC] section 2.74, "Class ipsecNFA", and [MS-ADSC] section 2.75, "Class ipsecPolicy") to the "System\IP Security" container. IPsec policy creation uses 'addRequest' messages that conform with [RFC2251] section 4.1.1. IPsec policy modification uses 'modifyRequest' messages that conform with [RFC2251] section 4.1.1.

All attributes MUST be present and correctly formatted to specify an IPsec policy. There is no restriction on the order in which the values are written. The individual policy objects MUST be stored in the "IP Security" container, as the following figure shows.

Figure 7: Individual policy objects stored in the IP Security container

IPsec policy creation MUST use the addRequest when adding the policy. The individual values are specified in the data descriptions that follow in sections 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, and 2.2.1.5.

IPsec policy modification MUST use the "replace" operation of modifyRequest when writing policies to enable "update-to" values representing the policy. The individual values are specified in the data descriptions that follow in sections 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, and 2.2.1.5.

The individual objects in a single policy MUST be organized into a logical hierarchy. The hierarchy is defined by individual data object attributes (as specified in sections 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, and 2.2.1.5). A complete IPsec policy consists of five hierarchical data objects, as shown in the following figure. Each IPsec policy instance MUST have one of each policy type. The diagram depicts the required policy items and logical hierarchy.

The individual items are all stored in the "IP Security" container, and the relationships shown are logical, not physical. A logical relationship is formed by an attribute of one item having as a value the name of another item.

Figure 8: Required policy items and logical hierarchy for a complete IPsec policy

To create a complete IPsec policy, object creation and modification can be implemented in the following order:

1. Create ipsecPolicy.

2. Create ipsecISAKMPPolicy.

3. Create ipsecNFA.

4. Create ipsecNegotiationPolicy.

5. Create ipsecFilter.

6. Modify ipsecPolicy - with ipsecISAKMPReference ipsecNFAReference.

7. Modify ipsecNFA - with ipsecFilterReference ipsecNegotiationPolicyReference.

Note In practice, the policy structure might not be as simple as the preceding diagram suggests because multiple ipsecNFA objects can (and usually do) exist per ipsecPolicy. For example, consider two ipsecFilter objects, two ipsecNegotiationPolicy objects, and three different ipsecNFA objects. In this example, these objects are denoted as F1, F2; NegPol1, NegPol2; and NFA1, NFA2, and NFA3 respectively. Note that NFA1 can reference F1 and NegPol1, and NFA2 can reference F2 and NegPol2. Then, a single ipsecPolicy can reference both NFA1 and NFA2. These relationships are illustrated in the following figure.

Figure 9: Multiple ipsecNFA objects per ipsecPolicy

Note  Multiple ipsecPolicy objects can be stored in the "IP Security" container. Separate policies (ipsecPolicy objects) are often assigned as active policy to particular GPOs, so that a specific IPsec policy can be applied to a group of machines that have a common need.

The following explains the cardinality of object associations:

• Each ipsecPolicy object can be associated to one or more ipsecNFA objects. Each ipsecNFA object can be associated to a maximum of one ipsecPolicy object.

• Each ipsecISAKMPPolicy object can be associated to one ipsecPolicy object. Each ipsecPolicy object can be associated to a maximum of one ipsecISAKMPPolicy object.

• Each ipsecNegotiationPolicy object can be associated to zero or more ipsecNFA objects. Each ipsecNFA object can be associated to a maximum of one ipsecNegotiationPolicy object.

• Each ipsecFilter object can be associated to zero or more ipsecNFA objects. Each ipsecNFA object can be associated to one or more ipsecFilter objects.