16.1 Introduction to Collective Attributes

Attributes shared by the entries comprising an entry collection are called collective attributes. Values of collective attributes are visible but not updatable to clients accessing entries within the collection. As administrator, you manage collective attributes by defining and modifying the associated collective attributes sub entry.

16.1.1 The RFC Definition and Oracle Extensions

RFC 3671 describes a specific schema for collective attributes. If you want to, you can define and use the collective attribute schema exactly as described in the RFC. Oracle Internet Directory, however, extends the definition of collective attributes to make them easier to use.

16.1.1.1 RFC 3671

According to RFC 3671, you must define each collective attribute schema before you can use it in the collective subentry. For example, if you want to use the telephone number attribute as a collective attribute, then you define the schema for the c-telephoneNumber in the directory like this:

16.1.1.2 Oracle Extensions

You do not need a schema definition for a collective attribute. You can use any attribute as a collective attribute.

To make an attribute a collective attribute, create it in the collective subentry with the subtype collective.

A collective attribute can be either multivalued or single valued.

The rest of this chapter describes Oracle Internet Directory usage.

16.1.2 Defining the Collective Attribute Subentry

You create a collective attribute by defining a subentry. The following example defines a collective subentry for the entries under dc=mycompany,dc=com. This subentry causes TelephoneNumber and postalCode to be included as collective attributes in all the entries under dc=mycompany,dc=com:

16.1.3 Using subtreeSpecification

You can control which specific entries actually get collective attributes. You do this by using the subtreeSpecification attribute in the collective subentry. If no subtreeSpecification attribute is specified in the collective subentry then the collective attributes are included in all the child entries where the collective subentry is defined.

See Also :

RFC 3672 "Subentries in the Lightweight Directory Access Protocol (LDAP)" at http://www.ietf.org for more details about the subtreeSpecification attribute.

The next three sections provide examples of how to use the subtreeSpecification attribute.

16.1.3.1 Base

You use the base keyword in the subtreeSpecification to limit a collective attribute to a subtree.

For example, to restrict collective attributes only to the subtree cn=users,dc=mycompany,dc=com, you can use the subentry previously shown for dc=mycompany,dc=com, but add a base value to the subtreeSpecification attribute in the collective subentry like this:

SubtreeSpecification: {base "cn=users"}

16.1.3.2 Minimum and Maximum

You use the minimum and maximum keywords in the subtreeSpecification attribute to control the number of RDNs from the base where collective attributes apply.

For example, if you want collective attributes to be added to the entries under ou=Americas,cn=users,dc=mycompany,dc=com but not to one level child entries of cn=users,dc=mycompany,dc=com, or two levels down from cn=users, dc=mycompany,dc=com, then define the subtreeSpecification as follows:

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4}

In this configuration, cn=john doe, ou=Americas,cn=users,dc=mycompany,dc=com gets the collective attributes, but cn=inbox,cn=2009,cn=emailFolder,cn=john doe, ou=Americas,cn=users,dc=mycompany,dc=com does not get the collective attributes because it is more than four levels from the basecn=users.

16.1.3.3 Specific Exclusions

You can further exclude collective attributes from specific entries by using the specificExclusions, chopBefore, and chopAfter keywords. For example, if you do not want to add collective attributes to ou=Europe, define the subtreeSpecification as follows:

In this example, the entry cn=Global User,ou=all region,cn=users,dc=mycompany,dc=com gets the collective attributes, but the entry cn=emailFolder, cn=GlobalUser,ou=all region,cn=users,dc=mycompany,dc=com does not get the collective attributes.

If you want collective attributes to be included for a certain object class only, then specify the Object Identifier or name of the object class in the specificationFilter for the subtreeSpecicfication attribute. For example, to include the collective attributes to the objectclassperson only, define the specification filter like this:

16.1.4 Overriding a Collective Attribute

If you want some entries to have their own values for an attribute, instead of the collective attribute value, you can specifically add that attribute to those entries and add attribute collectiveExclusions:attributeName to that entry.If all the collective attributes needs to be excluded then add attribute excludeAllCollectiveAttributes: true to those entries. Doing so overrides the value of the collective attribute value. For example, if you add the TelephoneNumber attribute and the excludeAllCollectiveAttributes: true attribute to the entry cn=jane smith, ou=Americas,cn=users,dc=mycompany,dc=com, this entry will have its own value for TelephoneNumber instead of the collective attribute.

16.2 Managing Collective Attributes by Using the Command Line

You can manage a collective attributes sub entry from the command line, like any other directory entry.

16.2.1 Adding a Subentry by Using ldapadd

To create collective attributes, you define the collective subentry in an LDIF file using ldapadd, as follows: