Page History

...

Introduction

Collective attributes are attributes whose values are shared across a collection of entries. It's very common to encounter situations where a bunch of entries have the same value for an attribute. Collective attributes for LDAP are defined in RFC 3671. ApacheDS implements this RFC.

Use Case

For example one might organize everyone in an engineering department under an ou, 'ou=engineering'. If the engineering team is located in the same area and building then several attributes in each user entry within engineering will have the same value. An example of such an attribute would be the locale. If engineering is located in Sunnyvale CA then all locale attributes of entries under 'ou=engineering' would be set to Sunnyvale.

Rather than manage the value for this attribute in each entry a single collective attribute can be used in a subentry. Changes to the value of this attribute would immediately be reflected to those entries selected by the subtreeSpecification of subentry. For more information on specifying subtrees take at Subentries.

Setting up a Collective Attribute Administration Area (AA)

To manage collective attributes for a collection of entries you must add collective subentries to the Administrative Point (AP) of the collective AA. For more information on AAs see Subentries. These collective subentries must have the objectClass subentry as well as collectiveAttributeSubentry. Also the AP, of the AA, must have an administrativeRole value of collectiveAttributeSpecificArea (2.5.23.5) or collectiveAttributeInnerArea (2.5.23.6).

Example

For the use case above we can presume a partition at the namingContext 'dc=example,dc=com' with an 'ou=engineering' entry below containing users from the engineering team in Sunnyvale. Let's presume no AA has yet been defined so we have to create one. We'll set the partition root 'dc=example,dc=com' as the AP of an AA that spans the entire subtree. For this simple example the AA will be autonomous for the collective aspect. Setting this up is just a matter of modifying the 'dc=example,dc=com' entry so it contains the operational attribute administrativeRole with the value collectiveAttributeSpecificArea. The code below sets up this AAA for collective attribute administration.

...

Note that the minimum value of 4 is used in the subtreeSpecification to make sure that the entry 'ou=engineering,dc=example,dc=com' does not have c-l: Sunnyvale added to it. It's got 3 components to the DN so minimum 4 chops it out of the collection.

Collective Attribute Types

As one can see from the example above, special collective attributes are used for regular attributes: c-l for l. These attributes are derived from the original attribute and are marked as COLLECTIVE. RFC 3671 defines a bunch of these which are listed below. If you don't find what you're looking for just add it to your own schema using this pattern.

...