This chapter describes collective attributes in Oracle Internet Directory and explains how to manage them.
This chapter contains the following topics:
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.
See Also :
RFC 3671 "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)" and RFC 3672 "Subentries in the Lightweight Directory Access Protocol (LDAP)" at http://www.ietf.org for more information.
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.
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.
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.
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
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.
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"}
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.
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} }
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.
You can manage a collective attributes sub entry from the command line, like any other directory entry.
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} }
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