16 Managing Collective Attributes

This chapter describes collective attributes in Oracle Internet Directory and explains how to manage them.

This chapter contains the following topics:

Section 16.1, "Introduction to Collective Attributes"
Section 16.2, "Managing Collective Attributes by Using the Command Line"

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:

( 2.5.4.20.1 NAME 'c-TelephoneNumber' SUP telephoneNumber COLLECTIVE )

In addition, the collective attribute must be multivalued.

16.1.1.2 Oracle Extensions

Oracle extends the usage as follows:

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:

Dn: cn=collective attributes, dc=mycompany,dc=com
Cn: collective attributes
Objectclass: subentry
Objectclass: collectiveAttributeSubentry
Objectclass: top
Objectclass: extensibleobject
TelephoneNumber;collective: 1234560000
PostalCode;collective: 98765

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.

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 base cn=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:

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe"} }

If you want the collective attributes to be included in a parent DN but not its child entries, define the specification filter like this:

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=Global User" } }

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 objectclass person only, define the specification filter like this:

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter item:person }

Alternatively, you could use:

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter item:2.5.6.6 }

where 2.5.6.6 is the Object Identifier for objectclass person.

Examples of SpecificationFilter

You can use the keywords and, or, and not to further refine your subtreeSpecicfication, as follows:

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter and:{ item:2.5.6.6, item:2.5.6.7} }

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter or:{ item:2.5.6.6, item:2.5.6.7} }

SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter not:{ item:2.5.6.7} }

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:

ldapadd -p port_number -h host -D cn=orcladmin -q -f subentry.ldif

where the contents of subentry.ldif is something like this:

Dn: cn=collective attributes, dc=mycompany,dc=com
Cn: collective attributes
Objectclass: subentry
Objectclass: collectiveAttributeSubentry
Objectclass: top
Objectclass: extensibleobject
TelephoneNumber;collective: 1234560000
PostalCode;collective: 98765
SubtreeSpecification: {base "cn=users", minimum 2, maximum 4, specificExclusions { chopBefore: "ou=Europe", chopAfter: "cn=GlobalUser"},  specificationFilter not:{ item:2.5.6.7} }

16.2.2 Modifying a Subentry by Using ldapmodify

Issue this command to modify the file:

ldapmodify -p 3060 -D "cn=orcladmin" -q -f mod_subentry.ldif

where mod_subentry.ldif is something like this:

dn: cn=collective attributes, dc=mycompany,dc=com
changetype: modify
replace: PostalCode;collective
PostalCode;collective: 98768