Previous     Contents     Index     DocHome     Next     
iPlanet Directory Server Administrator's Guide



Chapter 5   Advanced Entry Management


You can group the entries contained by your directory to simplify the management of user accounts. Directory Server supports a variety of methods for grouping entries and sharing attributes between entries.

This chapter describes the following grouping mechanisms and their procedures:

To take full advantage of the features offered by roles and class of service, in the planning phase of your directory deployment determine your directory topology. Refer to the iPlanet Directory Server Deployment Guide for more information.



Using Groups


Groups are a mechanism for associating entries for ease of administration. This mechanism was provided with previous versions of Directory Server and should be used primarily for compatibility with older versions of the server.

The following sections describe managing static and dynamic groups. For a conceptual overview of groups, refer to the iPlanet Directory Server Deployment Guide. For more information about administering groups, refer to Managing Servers with Directory Console.


Managing Static Groups

Static groups allow you to group entries by specifying the same group value in the DN attribute of any number of users. This section includes the following procedures for creating and modifying static groups:


Adding a New Static Group

  1. In the Directory Server Console, select the Directory tab.

  2. Right-click the entry in the left pane under which you want to add a new group. Select New > Group.

    You can also go to the Object menu and select New > Group.

  3. Click General in the left pane. Type a name for your new group in the "Group Name" field.

    The group name is required.

  4. Enter a description of the new group in the "Description" field.

  5. Click Members in the left pane. In the right pane, select the Static Group tab. Click Add to add new members to the group.

    The standard "Search users and groups" dialog box appears.

  6. In the Search drop-down list, select what sort of entries to search for (users, groups, or both) then click Search. Select one of the entries returned and click OK.

  7. Click Languages in the left pane to add language-specific information for your group.

  8. Click OK to create your new group. It appears in the right pane.


Modifying a Static Group

  1. On the Directory Server Console, select the Directory tab.

    The directory contents appear in the left pane.

  2. Double-click the entry you want to modify or select Open from the Object menu.

    The Edit Group dialog box appears.

  3. Make your changes to the group information. Click OK.

    To view your changes, go to the View menu and select Refresh.


Managing Dynamic Groups

Dynamic groups filter users based on their DN and include them in a single group. This section contains the following procedures for creating and modifying dynamic groups:


Adding a New Dynamic Group

  1. Follow steps 1-4 of "Adding a New Static Group".

  2. Click Members in the left pane. In the right pane, select the Dynamic Group tab. Click Add to create a LDAP URL for querying the database.

    The standard "Construct and Test LDAP URL" dialog box displays.

  3. Enter an LDAP URL in the text field or select Construct to be guided through the construction of an LDAP URL.

  4. Click Languages in the left pane to add language-specific information for your group.

  5. Click OK to create your new group.

    Your new group appears in the right pane.


Modifying a Dynamic Group

  1. On the Directory Server Console, select the Directory tab.

    The directory contents appear in the left pane.

  2. Double-click the entry you want to modify or select Open from the Object menu.

    The Edit Group dialog box appears.

  3. Make your changes to the group information. Click OK.

    To view your changes, go to the View menu and select Refresh.



Using Roles

Roles are a new entry grouping mechanism that unify the static and dynamic groups described in the previous sections. Roles are designed to be more efficient and easier to use for applications. For example, an application can locate the role of an entry, rather than select a group and browse the members list.

This section contains the following topics:


About Roles

Roles unify the static and dynamic group concept supported by previous versions of Directory Server.

You can use roles to:

  • Enumerate the members of a role.

    Having an enumerated list of role members can be useful for resolving queries for role members quickly.

  • Determine whether a given entry possesses a particular role.

    Knowing the roles possessed by an entry can help you determine whether the entry possesses the target role.

  • Enumerate all the roles possessed by a given entry.

  • Assign a particular role to a given entry.

  • Remove a particular role from a given entry.

You can do everything you would normally do with static groups with managed roles, and you can filter members using filtered roles as you used to do with dynamic groups. Roles are easier to use than groups, more flexible in their implementation, and reduce client complexity.

However, evaluating roles is more resource intensive because the server does the work for the client application. With roles, the client application can check role membership by searching the nsRole attribute. The nsRole attribute is a computed attributed that is not stored with the entry itself, which identifies which roles an entry belongs to. From the client application point of view, the method for checking membership is uniform and is performed on the server side.

Each role has members, or entries that possess the role. You can specify members either explicitly or dynamically. How you specify role membership depends upon the type of role you are using. Directory Server supports three types of roles:

  • Managed roles.

    A managed role allows you to create an explicit enumerated list of members.

  • Filtered roles.

    A filtered role allows you to assign entries to the role depending upon the attribute contained by each entry. You do this by specifying an LDAP filter. Entries that match the filter are said to possess the role.

  • Nested roles.

    A nested role allows you to create roles that contain other roles.

For more information about how roles work, refer to iPlanet Directory Server Deployment Guide.


Managing Roles Using the Console

This section contains the following procedures for creating and modifying roles:

When you create a role, you need to decide whether a user can add themselves or remove themselves from the role. Refer to "Using Roles Securely" for more information about roles and access control.


Creating a Managed Role

Managed roles allow you to create an explicit enumerated list of members. Managed roles are added to entries by adding the nsRoleDN attribute to the entry.

To create and add members to a managed role:

  1. On the Directory Server Console, select the Directory tab.

  2. Browse the tree in the left navigation pane and select the parent entry for your new role.

  3. Go to the Object menu and select New > Role.

    You can also right click the entry and select New > Role.

    The Create New Role dialog box is displayed.

  4. Click General in the left pane. Type a name for your new role in the "Role Name" field.

    The role name is required.

  5. Enter a description of the new role in the "Description" field.

  6. Click Members in the left pane.

    A search dialog box appears briefly.

  7. In the right pane, select Managed Role. Click Add to add new entries to the list of members.

    The standard "Search users and groups" dialog box appears.

  8. In the Search drop-down list, select Users from the Search drop-down list, then click Search. Select one of the entries returned and click OK.

  9. When you have finished adding entries to the role, click OK.

    The new role appears in the right pane.


Creating a Filtered Role

You assign entries to a filtered role depending upon a particular attribute contained by each entry. You do this by specifying an LDAP filter. Entries that match the filter are said to possess the role.

To create and add members to a filtered role:

  1. Follow steps 1-5 of "Creating a Managed Role".

  2. Click Members in the left pane.

    A search dialog box appears briefly.

  3. In the right pane, select Filtered Role.

  4. Enter an LDAP filter in the text field, or click Construct to be guided through the construction of an LDAP filter.

  5. If you click Construct, the standard LDAP URL construction dialog appears. Disregard the fields identifying the host server, port number and base DN.

    1. From the "Search" drop-down list, select whether the filter searches for entries one level below the base DN, or searches the whole subtree beneath the base DN. Do not use the base DN only option, because roles are designed to work only on entries within their scope.

    2. Select the types of entries you want to filter from the "For" drop-down list.

      You can choose between users, groups, or both.

    3. Select an attribute from the "Where" drop-down list. The two fields following it allow you to refine your search by selecting one of the qualifiers from the drop-down list (such as contains, does not contain, is, is not) and enter an attribute value in the text box. To add additional filters, click More. To remove unnecessary filters, click Fewer.

    4. Click OK to save your filter.

  6. Click Test to try your filter.

    A Filter Test Result dialog box displays the entries matching your filter.

  7. Click OK.

    The new role appears in the right pane.


Creating a Nested Role

Nested roles allow you to create roles that contain other roles. Before you create a nested role, another role must exist. When you create a nested role, the console displays a list of the roles available for nesting. The roles nested within the nested role are specified using the nsRoleDN attribute.

To create and add members to a nested role:

  1. Follow steps 1-5 of "Creating a Managed Role".

  2. Click Members in the left pane.

    A search dialog box appears briefly.

  3. In the right pane, select Nested Role.

  4. Click Add to add roles to the list.The members of the nested role are members of other existing roles.

    The Role Selector dialog box appears.

  5. Select a role from the "Available roles" list and click OK.

  6. Click OK.

    The new role appears in the right pane.


Viewing and Editing an Entry's Roles

To view or edit a role associated with an entry from the console:

  1. In the Directory Server Console, select the Directory tab.

  2. Browse the tree in the left navigation pane and select the entry for which you want to view or edit a role. Select Set Roles from the Object menu.

    The Roles dialog box displays.

  3. Select the Managed Roles tab to display the managed roles to which this entry belongs.

  4. To add a new managed role, click Add and select an available role from the Role Selector window. Click OK.

    To remove a managed role, select it and click Remove.

    To edit a managed role associated with an entry, click Edit. The Edit Entry dialog box displays. Make any changes to the general information or members and click OK.

  5. Select the Other Roles tab to view what filtered or nested roles this entry belongs to.

  6. Click Edit to make changes to any filtered or nested roles associated with the entry. Click OK to save your changes.

  7. Click OK once you have finished modifying the roles to save your changes.


Modifying a Role Entry

To edit an existing role:

  1. On the Directory Server Console, select the Directory tab.

  2. Browse the navigation tree in the left pane to locate the base DN for your role. Roles appear in the right pane with other entries.

  3. Double-click the role.

    The Edit Entry dialog box appears.

  4. Click General in the left pane to change the role name and description.

  5. Click Members in the left pane to change the members of managed and nested roles or to change the filter of a filtered role.

  6. Click OK to save your changes.


Making a Role Inactive

You can temporarily disable the members of a role by inactivating the role to which they belong. Inactivating a role inactivates the entries possessed by the role and not the role itself.

To temporarily disable the members of a role:

  1. On the Directory Server Console, select the Directory tab.

  2. Browse the navigation tree in the left pane to locate the base DN for your role. Roles appear in the right pane with other entries.

  3. Select the role. Select Inactivate from the Object menu.

    You can also right-click the role and select Inactivate from the menu.

    The role is inactivated.

    To see the inactivated entries, select Inactivation State from the View menu. A red slash through the role icon indicates that the role has been inactivated.


Reactivating a Role

To reactivate a disabled role:

  1. On the Directory Server Console, select the Directory tab.

  2. Browse the navigation tree in the left pane to locate the base DN for your role. Roles appear in the right pane with other entries.

  3. Select the role. Select Activate from the Object menu.

    You can also right-click the role and select Activate from the menu.

    The role is reactivated.

    To see inactivated entries, select Inactivation State from the View menu.The role icon appears as normal, indicating that the role is active.


Deleting a Role

Deleting a role deletes the role only, not its members.

To delete a role:

  1. In the Directory Server Console, select the Directory tab.

  2. Browse the navigation tree in the left pane to locate the base DN for your role. Roles appear in the right pane with other entries.

  3. Right-click the role and select Delete.

    A dialog box appears asking you to confirm the deletion. Click Yes.

  4. The Deleted Entries dialog box appears to inform you that the role was successfully deleted. Click OK.


Managing Roles Using the Command Line

Roles inherit from the ldapsubentry object class, which is defined in the ISO/IEC X.509 standard. In addition, each type of role has two specific object classes that inherits from the nsRoleDefinition object class. Once you create a role, you assign members to it as follows:

  • Members of a managed role have the nsRoleDN attribute in their entry.

  • Members of a filtered role are entries that match the filter specified in the nsRoleFilter attribute.

  • Members of a nested role are members of the roles specified in the nsRoleDN attributes of the nested role definition entry.

The following table lists the new object classes and attributes associated with each type of role:




Role Type

Object Classes

Attributes

Managed Role  

nsSimpleRoleDefinition
nsManagedRoleDefinition  

Description (optional)
 

Filtered Role  

nsComplexRoleDefinition
nsFilteredRoleDefinition  

nsRoleFilter
Description (optional)  

Nested Role  

nsComplexRoleDefinition
nsNestedRoleDefinition  

nsRoleDN
Description (optional)  


Note In some cases you need to protect the value of the nsRoleDN attribute with an ACI, as the attribute is writable. For more information about security and roles, refer to "Using Roles Securely".



Examples: Managed Role Definition

You want to create a role to be assigned to all marketing staff. Run the ldapmodify script as follows:

ldapmodify -D "cn=Directory Manager" -w secret -h host -p 389

Specify the managed role as follows:

dn: cn=Marketing,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsSimpleRoleDefinition
objectclass: nsManagedRoleDefinition
cn: Marketing
description: managed role for marketing staff

Notice that the nsManagedRoleDefinition object class inherits from the LDAPsubentry, nsRoleDefinition and nsSimpleRoleDefinition object classes.

Assign the role to a marketing staff member named Bob by doing an ldapmodify as follows:

ldapmodify -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=Bob,ou=people,dc=siroe,dc=com
changetype: modify
add: nsRoleDN
nsRoleDN: cn=Marketing,ou=people,dc=siroe,dc=com

The nsRoleDN attribute present in the entry indicates that the entry is a member of a managed role, the marketing managed role cn=Marketing,ou=people,dc=siroe,dc=com.


Example: Filtered Role Definition

You want to set up a filtered role for sales managers. Run the ldapmodify script as follows:

ldapmodify -D "cn=Directory Manager" -w secret -h host -p 389

Specify the filtered role as follows:

dn: cn=SalesManagerFilter,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: SalesManagerFilter
nsRoleFilter: o=sales managers
Description: filtered role for sales managers

Notice that the nsFilteredRoleDefinition object class inherits from the LDAPsubentry, nsRoleDefinition, and nsComplexRoleDefinition object classes. The nsRoleFilter attribute specifies the o (organization) attributes that contain the value of sales managers.

The following entry matches the filter (possesses the o attribute with the value sales manager) and therefore is a member of this filtered role:

dn: cn=Pat,ou=people,dc=siroe,dc=com
objectclass: person
cn: Pat
sn: Pat
userPassword: bigsecret
o: sales managers


Example: Nested Role Definition

You want to create a role that contains both the marketing staff and sales managers contained by the roles you created in the previous examples. The nested role you create using ldapmodify appears as follows:

dn: cn=MarketingSales,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsNestedRoleDefinition
cn: MarketingSales
nsRoleDN: cn=SalesManagerFilter,ou=people,dc=siroe,dc=com
nsRoleDN: cn=Marketing,ou=people,dc=siroe,dc=com

Notice the nsNestedRoleDefinition object class inherits from the LDAPsubentry, nsRoleDefinition, and nsComplexRoleDefinition object classes. The nsRoleDN attributes contain the DN of the marketing managed role and the sales managers filtered role.

Both of the users in the previous examples, Bob and Pat, would be members of this new nested role.


Using Roles Securely

Not every role is suitable for use in a security context. When creating a new role, consider how easily the role can be assigned to and removed from an entry. Sometimes it is appropriate for users to be able to easily add themselves to or remove themselves from a role. For example, if you had an interest group role called Mountain Biking, you would want interested users to add themselves or remove themselves easily.

However, in some security contexts it is inappropriate to have such open roles. For example, consider account inactivation roles. By default, account inactivation roles contain ACIs defined for their suffix. When creating a role, the server administrator decides whether a user can assign themselves to or remove themselves from the role.

For example, user A possesses the managed role, MR. The MR role has been locked using account inactivation through the command line. This means that user A cannot bind to the server because the nsAccountLock attribute is computed as "true" for that user. However, suppose the user was already bound and noticed that he is now locked through the MR role. If there are no ACIs preventing him, the user can remove the nsRoleDN attribute from his entry and unlock himself.

To prevent users from removing the nsRoleDN attribute, use the following ACIs depending upon the type of role being used.

Managed roles. For entries that are members of a managed role, use the following ACI to prevent users from unlocking themselves by removing the appropriate nsRoleDN:

aci: (targetattr="nsRoleDN")
     (targattrfilters="
      add=nsRoleDN:(!(nsRoleDN=cn=AdministratorRole,dc=siroe,dc=com)),
      del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=siroe,dc=com ))")
(version3.0;aci "allow mod of nsRoleDN by self
     but not to critical values";
     allow(write)
     userdn="ldap:///self";)

Filtered roles. The attributes that are part of the filter should be protected so that the user cannot relinquish the filtered role by modifying an attribute. The user should not be allowed to add, delete, and modify the attribute used by the filtered role. If the value of the filter attribute is computed, then all attributes that can modify the value of the filter attribute should be protected in the same way.

Nested roles. A nested role is comprised of filtered and managed roles, so the above points should be considered for each of the roles that comprise the nested role.

For more information about account inactivation, see "Inactivating Users and Roles," on page 263.



Assigning Class of Service


A class of service (CoS) allows you to share attributes between entries in a way that is transparent to applications. CoS simplifies entry management and reduces storage requirements.

There are two methods for creating and managing CoS, using the Directory Server console or through the command line. The following sections describe CoS in more detail and provide the procedures for managing CoS through both the console and the command line:


About CoS

Clients of the Directory Server read the attributes on a user's entry. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.

Each CoS is comprised of the following two types of entry in your directory:

  • CoS Definition Entry.

    The CoS definition entry identifies the type of CoS you are using. Like the role definition entry, it inherits from the LDAPsubentry object class. The CoS definition entry is below the branch at which it is effective.

  • Template Entry.

    The CoS template entry contains a list of the shared attribute values. Changes to the template entry attribute values are automatically applied to all the entries within the scope of the CoS. A single CoS might have more than one template entry associated with it.

The CoS definition entry and template entry interact to provide attribute information to their target entries, any entry within the scope of the CoS.


Note LDAP search requests containing a filter that references an attribute defined by a CoS may return unexpected results. Take care when deciding which attributes to generate using a CoS.


The following sections describe the entries that make up a CoS in more detail and provide examples of each type of CoS.


About the CoS Definition Entry

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. You can specify three different object classes depending upon the type of CoS you want to use. The target entries share the same parent as the CoS definition entry.

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

  • Pointer CoS.

    A pointer CoS identifies the template entry using the template DN only.

  • Indirect CoS.

    An indirect CoS identifies the template entry using the value of one of the target entry's attributes. For example, an indirect CoS might specify the manager attribute of a target entry. The value of the manager attribute is then used to identify the template entry.

    The target entry's attribute must be single-valued and contain a DN.

  • Classic CoS.

    A classic CoS identifies the template entry using a combination of the template entry's base DN and the value of one of the target entry's attributes.

For more information about the object classes and attributes associated with each type of CoS, refer to "Managing CoS From the Command Line".

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


About the CoS Template Entry

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:

  • The DN of the template entry alone.

    This type of template is associated with a pointer CoS.

  • The value of one of the target entry's attributes.

    The attribute used to provide the relative DN to the template entry is specified in the CoS definition entry using the cosIndirectSpecifier attribute. This type of template is associated with an indirect CoS.

  • By a combination of the DN of the subtree where the CoS performs a one level search for templates and the value of one of the target entry's attributes.

    This type of template is associated with a classic CoS.


How a Pointer CoS Works

You create a CoS that shares a common postal code with all of the entries stored under dc=siroe,dc=com. The three entries for this CoS appear as follows:



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


How an Indirect CoS Works

You can create an indirect CoS that uses the manager attribute of the target entry to identify the template entry.

The three CoS entries appear as follows:



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=siroe,dc=com. The template entry in turn provides the departmentNumber attribute value of 318842.


How a Classic CoS Works

You can create 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 follows:



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=siroeUS,cn=data. The template entry then provides the value of the postalCode attribute to the target entry.


Managing CoS Using the Console

This section describes creating and editing CoS through the Directory Server Console. It includes the following sections:


Creating a New CoS

  1. In the Directory Server Console, select the Directory tab.

  2. Browse the tree in the left navigation pane and select the parent entry for your new class of service.

  3. Go to the Object menu and select New > Class of Service.

    You can also right click the entry and select New > Class of Service.

    The Create New Class of Service dialog displays.

  4. Select General in the left pane. In the right pane, enter the name of your new class of service in the "Class Name" field. Enter a description of the class in the "Description" field.

  5. Click Attributes in the left pane. The right pane displays a list of attributes generated on the target entries.

    Click Add to browse the list of possible attributes and add them to the list.

  6. Once you have added an attribute to the list, a drop-down list appears in the "Class of Service Behavior" column.

    Select "Does not override target entry attribute" to tell the directory to only return a generated value if there is no corresponding attribute value stored with the entry.

    Select "Overrides target entry attribute" to make the value of the attribute generated by the CoS override the local value.

    Select "Overrides target entry attribute and is operational" to make the attribute override the local value and to make the attribute operational, so that it is not visible to client applications unless explicitly requested.


    Note You can only make an attribute operational if it is also defined as operational in the schema.

    For example, if your CoS generates a value for the description attribute, you cannot select "Overrides target entry attribute and is operational" because this attribute is not marked operational in the schema.


  7. Click Template in the left pane. In the right pane, select how the template entry is identified.

    By its DN. If you choose to have the template entry identified by only its DN (a pointer CoS), enter the DN of the template in the "Template DN" field. Click Browse to locate the DN on your local server.

    Using the value of one of the target entry's attribute. If you choose to have the template entry identified by the value of one of the target entry's attributes (an indirect CoS), enter the attribute name in the "Attribute Name" field. Be sure to select an attribute which contains DN values. Click Change to select a different attribute from the list of available attributes.

    Using both its DN and the value of one of the target entry's attributes. If you choose to have the template entry identified by both its DN and the value of one of the target entry's attributes (a classic CoS), enter both a template DN and an attribute name.

  8. Click OK.


Editing an Existing CoS

The following procedure describes changing the description and attributes generated on the target entry of an existing class of service.

To edit an existing CoS:

  1. In the Directory Server Console, select the Directory tab.

  2. Browse the tree in the left navigation pane and select the parent entry that contains your class of service.

    The CoS appears in the right pane with other entries.

  3. Double-click the CoS.

    The Edit Entry dialog box appears.

  4. Click General in the left pane to change the CoS name and description.

  5. Click Attributes in the left pane to add or remove attributes generated by the CoS.

  6. Click OK to save your changes.

    The target entries of the CoS are automatically updated.


Deleting a CoS

The following procedure describes deleting a CoS:

  1. In the Directory Server Console, select the Directory tab.

  2. Browse the tree in the left navigation pane and select the parent entry that contains your class of service.

    The CoS appears in the right pane with other entries.

  3. Right-click the CoS and select Delete. A dialog box appears asking you to confirm the deletion. Click Yes.

  4. The Deleted Entries dialog box appears to inform you that the CoS was successfully deleted. Click OK.


Managing CoS From the Command Line

Because all configuration information and template data is stored as entries in the directory, you can use standard LDAP tools for CoS configuration and management. This section contains the following topics:


Creating the CoS Definition Entry From the Command Line

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. The following table lists the object classes associated with each type of CoS definition entry:


Table 5-1    CoS Definition Entry Object Classes

CoS Type

Object Classes

Description

Pointer CoS  

cosPointerDefinition  

Identifies the template entry associated with the CoS definition using the template entry's DN value. The DN of the template entry is specified in the cosTemplateDn attribute.  

Indirect CoS  

cosIndirectDefinition  

Identifies the template entry using the value of one of the target entry's attributes. The attribute of the target entry is specified in the cosIndirectSpecifier attribute.  

Classic CoS  

cosClassicDefinition  

Identifies the template entry using both the template entry's DN (as specified in the cosTemplateDn attribute) and the value of one of the target entry's attributes (as specified in the cosSpecifier attribute).  

You can use the following attributes in your CoS definition entries:


Table 5-2    CoS Definition Entry Attributes

Attribute

Definition

cosAttribute  

Provides the name of the attribute for which you want to generate a value. You can specify more than one cosAttribute value. This attribute is used by all types of CoS definition entries.  

cosIndirectSpecifier  

Specifies the attribute value used by an indirect CoS to identify the template entry.  

cosSpecifier  

Specifies the attribute value used by a classic CoS, which, along with the template entry's DN, identifies the template entry.  

cosTemplateDn  

Provides the DN of the template entry associated with the CoS definition. Used for pointer CoS and classic CoS only.  

The cosAttribute attribute allows an additional qualifier after the attribute value. You can use the following qualifiers:

  • Default

    This qualifier indicates that the server only returns a generated value if there is no corresponding attribute value stored with the entry.

  • Override

    This qualifier indicates that the server always returns the value generated by the CoS, even when there is a value stored with the entry.

  • Operational

    This qualifier indicates that the attribute will only be returned if it is explicitly requested in the search. Operational attributes do not need to pass a schema check in order to be returned. When you use operational as a qualifier, it works as if override and operational were specified.


    Note You can only make an attribute operational if it is also defined as operational in the schema.

    For example, if your CoS generates a value for the description attribute, you use the operational qualifier because this attribute is not marked operational in the schema.


If you do not indicate a qualifier, default is assumed.

For example, you might create a pointer CoS definition entry that contains an override qualifier as follows:

dn: cn=pointerCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=siroeUS,cn=data
cosAttribute: postalCode override

This pointer CoS definition entry indicates that it is associated with a template entry, cn=siroeUS,cn=data, 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.


Note If an entry contains an attribute value generated by a CoS, you cannot manually update the value of the attribute if it is defined with the operational or override qualifiers.


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

Now that you have been introduced to the object classes and attributes used by a CoS definition, it is time to put them together to create the definition entry itself. The following table describes the CoS definition for each type of CoS:


Table 5-3    CoS Definitions

CoS Type

CoS definition

Pointer CoS

 

objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: DN_string
cosAttribute: list_of_attributes qualifier  
Indirect CoS

 

objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosIndirectDefinition
cosIndirectSpecifier: attribute_name
cosAttribute: list_of_attributes qualifier  
Classic CoS

 

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


Creating the CoS Template Entry From the Command Line

The CoS template entry also inherits from the LDAPsubentry object class. Each template entry is an instance of the cosTemplate object class.


Note Making the CoS template entry an instance of the LDAPsubentry object classes allows ordinary searches to be performed unhindered by the configuration entries. However, if the template entry already exists and is used for something else (for example, if it is a user entry), you do not need to make it an instance of the LDAPsubentry 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=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
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, you might have a multi-valued cosSpecifier in your CoS definition entry. In such a case, you can specify a template priority on each template entry to determine 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.

Templates that contain no cosPriority attribute are considered the lowest priority. In the case 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.

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

dn: cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
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 precedene over any other conflicting templates that define a different departmentNumber value.

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


Example of a Pointer CoS

You want to create a pointer CoS that shares a common postal code with all entries in the dc=siroe,dc=com tree.

To add a new pointer CoS definition entry to the dc=siroe,dc=com suffix, you do an ldapmodify as follows:

ldapmodify -a -D "cn=directory manager" -w secret -h host -p 389

The ldapmodify utility binds to the server and prepares it to add information to the configuration file.

Next, you add the pointer CoS definition to the dc=siroe,dc=com root suffix as follows:

dn: cn=pointerCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=siroeUS,cn=data,dc=siroe,dc=com
cosAttribute: postalCode

Next, you create the template entry as follows:

dn: cn=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 44438

The CoS template entry (cn=siroeUS,dn=cata,dc=siroe,dc=com) supplies the value stored in its postalCode attribute to any entries located under the dc=siroe,dc=com suffix. These entries are the target entries.


Example of an Indirect CoS

This indirect CoS uses the team attribute of the target entry to identify the CoS template entry.

First, you add a new indirect CoS definition entry to the dc=siroe,dc=com suffix, using ldapmodify as follows:

ldapmodify -a -D "cn=directory manager" -w secret -h host -p 389

The ldapmodify utility binds to the server and prepares it to add information to the configuration file.

Next, you add the indirect CoS definition to the dc=siroe,dc=com root suffix as follows:

dn: cn=indirectCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosIndirectDefinition
cosIndirectSpecifier: manager
cosAttribute: departmentNumber

Next, you create the template entry for the manager Carla Fuentes as follows:

dn:cn=Carla Fuentes,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
departmentNumber: 318842

You create a second template entry for the manager Sue Jacobs as follows:

dn:cn=Sue Jacobs,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
departmentNumber: 71776

The definition entry looks in the target entries (the entries under dc=siroe,dc=com) for entries containing the manager attribute (because this attribute is specified in the cosIndirectSpecifier attribute of the definition entry). The manager attribute of the target entry can point to one of two templates, cn=Carla Fuentes,cn=data,dc=siroe,dc=com and cn=Sue Jacobs,cn=data,dc=siroe,dc=com. The department number is different depending upon the manager.


Example of a Classic CoS

You want to create a classic CoS that automatically generates postal codes using a combination of the template DN and the attribute specified in the cosSpecifier attribute.

First, you add a new classic CoS definition entry to the dc=siroe,dc=com suffix, using ldapmodify as follows:

ldapmodify -a -D "cn=directory manager" -w secret -h host -p 389

The ldapmodify utility binds to the server and prepares it to add information to the configuration file.

Next, you add the indirect CoS definition to the dc=siroe,dc=com root suffix as follows:

dn: cn=classicCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: cn=siroeUS,cn=data,dc=siroe,dc=com
cosSpecifier: employeeType
cosAttribute: postalCode override

Next, you create the template entries for the sales and marketing departments as follows:

dn: cn=sales,cn=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 44438

dn: cn=marketing,cn=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 99111

The classic CoS definition entry applies to all entries under the dc=siroe,dc=com suffix. Depending upon the combination of employeeType 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.


Creating Role-Based Attributes

You can create classic CoS schemes that generate attribute values for an entry based on the role possessed by the entry. For example, you could use role-based attributes to set the server look through limit on an entry-by-entry basis.

To create a role-based attribute, use the nsRole attribute as the cosSpecifier in the CoS definition entry of a classic CoS. Because the nsRole attribute can be multivalued, you can define CoS schemes that have more than one possible template entry. To resolve the ambiguity of which template entry to use, you can include the cosPriority attribute in your CoS template entry.

For example, you can create a CoS that allows members of the manager role to exceed the standard mailbox quota. The manager role exists as follows:

dn: cn=ManagerRole,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: ManagerRole
nsRoleFilter: o=managers
Description: filtered role for managers

The classic CoS definition entry would look as follows:

dn: cn=managerCOS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectlass: cosClassicDefinition
cosTemplateDn: cn=managerCOS,dc=siroe,dc=com
cosSpecifier: nsRole
cosAttribute: mailboxquota override

The cosTemplateDn attribute provides a value that, in combination with the attribute specified in the cosSpecifier attribute (in the example, the nsRole attribute of the target entry), identifies the CoS template entry. The CoS template entry provides the value for the mailboxquota attribute. An additional qualifier of override tells the CoS to override any existing mailboxquota attributes values in the target entry.

The corresponding CoS template entry looks as follows:

dn:cn="cn=ManagerRole,ou=people,dc=siroe,dc=com",cn=managerCOS,
 dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectlass: cosTemplate
mailboxquota: 1000000

The template provides the value for the mailboxquota attribute, 1000000.


Note The role entry and the CoS definition and template entries should be located at the same level in the directory tree.



Access Control and CoS

The server controls access to attributes generated by a CoS in exactly the same way as regular stored attributes. However, access control rules depending upon the value of attributes generated by CoS will not work.


Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated March 23, 2001