The CoS definition entry is an instance of the cosSuperDefinition object class. The CoS definition entry also contains an object class that specifies the type of template entry it uses to generate the entry. There are three different object classes which can be specified, depending upon the type of CoS. The target entries share the same parent as the CoS definition entry.

There are three types of CoS, defined using three types of CoS definition entries:

For more information about the object classes and attributes associated with each type of CoS, refer to Section 5.2.3, “Managing CoS from the Command-Line”.

If the CoS logic detects that an entry contains an attribute for which the CoS is generating values, the CoS, by default,supplies the client application with the attribute value in the entry itself. However, the CoS definition entry can control this behavior.

The CoS template entry contains the value or values of the attributes generated by the CoS logic. The CoS template entry contains a general object class of cosTemplate. The CoS template entries for a given CoS are stored in the directory tree along with the CoS definition.

The relative distinguished name (RDN) of the template entry is determined by one of the following:

An administrator creates a pointer CoS that shares a common postal code with all of the entries stored under dc=example,dc=com. The three entries for this CoS appear as illustrated in Figure 5.1, “Sample Pointer CoS”.

Figure 5.1. Sample Pointer CoS

In this example, the template entry is identified by its DN, cn=exampleUS,cn=data, in the CoS definition entry. Each time the postalCode attribute is queried on the entry cn=wholiday,ou=people,dc=example,dc=com, the Directory Server returns the value available in the template entry cn=exampleUS,cn=data.

An administrator creates an indirect CoS that uses the manager attribute of the target entry to identify the template entry. The three CoS entries appear as illustrated in Figure 5.2, “Sample Indirect CoS”.

Figure 5.2. Sample Indirect CoS

In this example, the target entry for William Holiday contains the indirect specifier, the manager attribute. William's manager is Carla Fuentes, so the manager attribute contains a pointer to the DN of the template entry, cn=Carla Fuentes,ou=people,dc=example,dc=com. The template entry in turn provides the departmentNumber attribute value of 318842.

An administrator creates a classic CoS that uses a combination of the template DN and a CoS specifier to identify the template entry containing the postal code. The three CoS entries appear as illustrated in Figure 5.3, “Sample Classic CoS”:

Figure 5.3. Sample Classic CoS

In this example, the CoS definition entry's cosSpecifier attribute specifies the employeeType attribute. This attribute, in combination with the template DN, identify the template entry as cn=sales,cn=exampleUS,cn=data. The template entry then provides the value of the postalCode attribute to the target entry.

CoS definitions provide values for attributes in entries. For example, a CoS can set the postalCode attribute for every entry in a subtree. Searches against those CoS-defined attributes, however, do not behave like searches against regular entries.

Because of the potential issues with running LDAP search request on CoS-defined attributes, take care when deciding which attributes to generate using a CoS.

For a pointer CoS or a classic CoS, there must be a template entry, according to the template DN set when the class of service was created. Although the template entries can be placed anywhere in the directory as long as the cosTemplateDn attribute reflects that DN, it is best to place the template entries under the CoS itself.

For a pointer CoS, make sure that this entry reflects the exact DN given when the CoS was created. For a classic CoS, the template DN should be recursive, pointing back to the CoS entry itself as the base suffix for the template.

The CoS will be visible in the left navigation pane once there are entries beneath it. For classic CoS, there can be multiple entries, according to the different potential values of the attribute specifier.

To edit the description or attributes generated on the target entry of an existing CoS, do the following:

Each type of CoS requires a particular object class to be specified in the definition entry. All CoS definition object classes inherit from the LDAPsubentry object class and the cosSuperDefinition object class. Table 5.2, “CoS Definition Entry Object Classes” lists the object classes associated with each type of CoS definition entry.

Table 5.3, “CoS Definition Entry Attributes” lists attributes that available to use in the CoS definition entries.

The cosAttribute attribute allows an additional qualifier after the attribute value. There are four possible qualifiers:

If no qualifier is set, default is assumed.

For example, a pointer CoS definition entry that contains an override qualifier is created as follows:

dn: cn=pointerCoS,dc=example,dc=com
objectclass: top
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com
cosAttribute: postalCode override

This pointer CoS definition entry indicates that it is associated with a template entry, cn=exampleUS,ou=data,dc=example,dc=com, that generates the value of the postalCode attribute. The override qualifier indicates that this value will take precedence over the value stored by the entries for the postalCode attribute.

For more information about the attributes, refer to the Directory Server Configuration, Command, and File Reference.

Table 5.4, “CoS Definitions” describes the CoS definition for each type of CoS.

objectclass: top 
objectclass: cosSuperDefinition 
objectclass: cosPointerDefinition 
cosTemplateDn:DN_string
cosAttribute:list_of_attributes qualifier

objectclass: top 
objectclass: cosSuperDefinition 
objectclass: cosIndirectDefinition 
cosIndirectSpecifier:attribute_name
cosAttribute:list_of_attributes qualifier

objectclass: top 
objectclass: cosSuperDefinition 
objectclass: cosClassicDefinition 
cosTemplateDn:DN_string
cosSpecifier:attribute_name
cosAttribute:list_of_attributes qualifier

CoS definition entries are operational entries and are not returned by default with regular searches. This means that if a CoS is defined under ou=People,dc=example,dc=com, for example, the following ldapsearch command will not return them:

ldapsearch -s sub -b ou=People,dc=example,dc=com “(objectclass=*)”

To return the CoS definition entries, add the ldapSubEntry object class to the CoS definition entries. For example:

dn: cn=pointerCoS,ou=People,dc=example,dc=com
objectclass: top 
objectclass: cosSuperDefinition 
objectclass: cosPointerDefinition 
objectclass: ldapSubEntry 
cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com
cosAttribute: postalCode override

Then use a special search filter, (objectclass=ldapSubEntry), with the search. This filter can be added to any other search filter using OR (|):

ldapsearch -s sub -b ou=People,dc=example,dc=com “(|(objectclass=*)(objectclass=ldapSubEntry))”

This search returns all regular entries in addition to CoS definition entries in the ou=People,dc=example,dc=com subtree.

Each template entry is an instance of the cosTemplate object class.

The CoS template entry also contains the attribute generated by the CoS (as specified in the cosAttribute attribute of the CoS definition entry) and the value for that attribute.

For example, a CoS template entry that provides a value for the postalCode attribute follows:

dn:cn=exampleUS,ou=data,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
postalCode: 44438

It is possible to create CoS templates that compete with each other to provide an attribute value. For example, there can be a multi-valued cosSpecifier attribute in the CoS definition entry. Specifying the template priority on each template entry determines which template provides the attribute value. Set the template priority using the cosPriority attribute. This attribute represents the global priority of a particular template. A priority of zero is the highest priority.

For example, a CoS template entry for generating a department number appears as follows:

dn: cn=data,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
departmentNumber: 71776
cosPriority: 0

This template entry contains the value for the departmentNumber attribute. It has a priority of zero, meaning this template takes precedence over any other conflicting templates that define a different departmentNumber value.

Templates that contain no cosPriority attribute are considered the lowest priority. Where two or more templates are considered to supply an attribute value and they have the same (or no) priority, a value is chosen arbitrarily. The behavior for negative cosPriority values is not defined in Directory Server; do not enter negative values. Also, the cosPriority attribute is not supported by indirect CoS.

The following sections provide examples of template entries along with examples of each type of CoS definition entry.

Example Corporation's administrator is creating a pointer CoS that shares a common postal code with all entries in the dc=example,dc=com tree.

The CoS template entry (cn=exampleUS,ou=data,dc=example,dc=com) supplies the value stored in its postalCode attribute to any entries located under the dc=example,dc=com suffix. These entries are the target entries.

This indirect CoS uses the manager attribute of the target entry to identify the CoS template entry, which varies depending on the different values of the attribute.

If the directory or modify the manager entries already contain the departmentNumber attribute, then no other attribute needs to be added to the manager entries. The definition entry looks in the target suffix (the entries under dc=example,dc=com) for entries containing the manager attribute because this attribute is specified in the cosIndirectSpecifier attribute of the definition entry). It then checks the departmentNumber value in the manager entry that is listed. The value of the departmentNumber attribute will automatically be relayed to all of the manager's subordinates that have the manager attribute. The value of departmentNumber will vary depending on the department number listed in the different manager's entries.

The Example Corporation administrator is creating a classic CoS that automatically generates postal codes using a combination of the template DN and the attribute specified in the cosSpecifier attribute.

The classic CoS definition entry applies to all entries under the dc=example,dc=com suffix. Depending upon the combination of the businessCategory attribute found in the entry and the cosTemplate DN, it can arrive at one of two templates. One, the sales template, provides a postal code specific to employees in the sales department. The marketing template provides a postal code specific to employees in the marketing department.