16 Managing Collective Attributes
This chapter includes the following sections:
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.
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.
16.1.1 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 to RFC 3671
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 Attribute
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 sections provide examples of how to use the subtreeSpecification attribute.
16.1.3.1 Limiting Collective Attribute to a Subtree by using base Keyword
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 Controlling Number of RDNs by using minimum and maximum Keywords
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 Applying Specific Exclusions by using chopBefore and chopAfter Keywords
You can 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.
16.1.3.4 Including Certain Object Classes by using specificationFilter
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.
The following sections explain this further:
16.1.3.4.1 Including a Specific Object Class
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.
16.1.3.4.2 Refining Object Classes
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.3.4.3 Extending specificationFilter to Include a LDAP Filter
The scope of the specificationFilter encompasses an LDAP filter, allowing a finer grained control of which entries to target. You can use the keyword filter in the subtreespecification attribute as follows:
subtreespecification: {base "ou=people", filter: orclaccountstatus=enabled }
The following example describes how to define a filter.
dn: cn=building,dc=us,dc=oracle,dc=com
cn: building
subtreespecification: {base "ou=people_grp" , filter: mail=user.1@example.com }
objectclass: top
objectclass: extensibleobject
objectclass: subentry
objectclass: collectiveattributesubentry
street;collective: 200 ABC Street
In the preceding example, the collective attribute value street is only visible for entries that have mail attribute as user.1@example.com.
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.
The following sections explain this further:
16.2.1 Adding a Subentry by Using ldapadd
To create collective attributes, you define the collective subentry in an LDIF file using ldapadd.
The syntax is 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
To modify a subentry in a LDIF file you can use ldapmodify command.
Run the following 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