Chapter 5
Advanced Entry Management
You can group the entries contained within your directory to simplify the management of user accounts. Red Hat Directory Server (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, determine your directory topology in the planning phase of your directory deployment. Refer to the Red Hat 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 Red Hat Directory Server Deployment Guide. For more information about administering groups, refer to Managing Servers with Red Hat 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:
If you have a user that is remote from the definition of the static group, then you can use the Referential Integrity Plug-in to ensure that deleted user entries are automatically deleted from the static group. For more information about using referential integrity with chaining, refer to "Configuring the Chaining Policy," on page 104. |
Adding a New Static Group
- In the Directory Server Console, select the Directory tab.
- In the left pane, right-click the entry under which you want to add a new group, and select New > Group.
- Enter a description of the new group in the "Description" field.
- Click Members in the left pane. In the right pane, select the Static Group tab. Click Add to add new members to the group.
- 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.
- Click Languages in the left pane to add language-specific information for your group.
- Click OK to create your new group. It appears in the right pane.
Modifying a Static Group
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
- Follow steps 1-4 of "Adding a New Static Group," on page 172.
- 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.
- Enter an LDAP URL in the text field or select Construct to be guided through the construction of an LDAP URL.
- Click Languages in the left pane to add language-specific information for your group.
- Click OK to create your new group.
Modifying a Dynamic Group
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
- Managing Roles Using the Console
- Managing Roles Using the Command-Line
- Using Roles Securely
About Roles
Roles unify the static and dynamic group concept supported by previous versions of Directory Server.
- Having an enumerated list of role members can be useful for resolving queries for role members quickly.
- 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.
With managed roles, you can do everything you would normally do with static groups, 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 attribute, which identifies to which roles an entry belongs; the nsRole attribute is not stored with the entry itself. 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 Red Hat Directory Server Deployment Guide.
The concept of activating/inactivating roles is introduced to enable you to activate/inactivate groups of entries in just one operation. That is, you can temporarily disable the members of a role by inactivating the role to which they belong.
When a role is said to be inactivated, it does not mean that you cannot bind to the server using that role entry. The meaning of an inactivated role is that you cannot bind to the server using any of the entries that belong to that role-the entries that belong to an inactivated role will have the nsaccountlock attribute set to true.
In the case of the nested role, an inactivated nested role means that you cannot bind to the server using an entry that belongs to a role that is a member of the nested role. All the entries that belong to a role that directly or indirectly are members of the nested role (one may have several levels of nested roles) will have nsaccountlock set to true.
Managing Roles Using the Console
This section contains the following procedures for creating and modifying roles:
- Creating a Managed Role
- Creating a Filtered Role
- Creating a Nested Role
- Viewing and Editing an Entry's Roles
- Modifying a Role Entry
- Making a Role Inactive
- Reactivating a Role
- Deleting a Role
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," on page 184, 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:
- In the Directory Server Console, select the Directory tab.
- Browse the tree in the left navigation pane, and select the parent entry for your new role.
- Go to the Object menu, and select New > Role.
- 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.
- When you have finished adding entries to the role, click OK.
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:
- Follow steps 1-5 of "Creating a Managed Role," on page 177.
- Click Members in the left pane.
- In the right pane, select Filtered Role.
- Enter an LDAP filter in the text field, or click Construct to be guided through the construction of an LDAP filter.
- If you click Construct, the standard LDAP URL construction dialog appears. Disregard the LDAP Server Host, Port, Base DN, and Search (as you cannot specify a search scope for filtered role definitions) fields.
- 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.
- Click OK to save your filter.
- Click Test to try your filter.
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:
- Follow steps 1-5 of "Creating a Managed Role," on page 177.
- Click Members in the left pane.
- In the right pane, select Nested Role.
- Click Add to add roles to the list.The members of the nested role are members of other existing roles.
Viewing and Editing an Entry's Roles
To view or edit a role associated with an entry from the Console:
- In the Directory Server Console, select the Directory tab.
- In the left navigation pane, browse the tree, and select the entry for which you want to view or edit a role.
- Select Set Roles from the Object menu.
- 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.
Modifying a Role Entry
- In the Directory Server Console, select the Directory tab.
- 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.
- Double-click the role.
- Click General in the left pane to change the role name and description.
- Click Members in the left pane to change the members of managed and nested roles or to change the filter of a filtered role.
- 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, not the role itself.
To temporarily disable the members of a role:
- In the Directory Server Console, select the Directory tab.
- 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.
- Select the role. Select Inactivate from the Object menu.
- The role is inactivated.
Reactivating a Role
To reactivate a disabled role:
- In the Directory Server Console, select the Directory tab.
- 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.
- Select the role. Select Activate from the Object menu.
- 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.
- In the Directory Server Console, select the Directory tab.
- 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.
- Right-click the role, and select Delete.
- The Deleted Entries dialog box appears to inform you that the role was successfully deleted. Click OK.
Deleting a role deletes the role entry but does not delete the nsRoleDN attribute for each role member. If you want to delete the nsRoleDN attribute for each role member, enable the Referential Integrity Plug-in, and configure it to manage the nsRoleDN attribute. For more information on the Referential Integrity Plug-in, see "Maintaining Referential Integrity," on page 75. |
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 inherit 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.
Table 5-1 lists the new object classes and attributes associated with each type of role.
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," on page 184. |
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=example,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=example,dc=com changetype: modify add: nsRoleDN nsRoleDN: cn=Marketing,ou=people,dc=example,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=example,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=example,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 managers), and, therefore, it is a member of this filtered role:
dn: cn=Pat,ou=people,dc=example,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 created using ldapmodify appears as follows:
dn: cn=MarketingSales,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsNestedRoleDefinition cn: MarketingSales nsRoleDN: cn=SalesManagerFilter,ou=people,dc=example,dc=com nsRoleDN: cn=Marketing,ou=people,dc=example,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 add or remove themselves easily 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. 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=example,dc =com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=exampl e,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, or 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 300.
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: with 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
- Managing CoS Using the Console
- Managing CoS from the Command-Line
- Creating Role-Based Attributes
- Access Control and CoS
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.
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 three 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," on page 194.
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, 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:
- This type of template is associated with a pointer CoS.
- 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 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.
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.
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 illustrated in Figure 5-2.
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.
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 illustrated in Figure 5-3:
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.
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
- In the Directory Server Console, select the Directory tab.
- Browse the tree in the left navigation pane, and select the parent entry for your new class of service.
- Go to the Object menu, and select New > Class of Service.
- 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.
- Click Attributes in the left pane. The right pane displays a list of attributes generated on the target entries.
- 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.
- Select "Does not override target entry attribute and is operational" to tell the directory to return a generated value only if there is no corresponding attribute value stored with the entry and to make the attribute operational (so that it is not visible to client applications unless explicitly requested).
- 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. This will be an exact DN; e.g., cn=CoS template,ou=People,dc=example,dc=com.
- 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. 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. The template DN in a classic CoS is more general than for a pointer CoS; set the suffix or subsuffix where you will place the template entries (there can be more than one template).
- Click OK.
Creating the CoS Template Entry
If you created a pointer CoS or a classic CoS, you need to create a template entry, according to the template DN you set when you created the class of service. Although you can place the template entries 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 you gave when you created the CoS. For a classic CoS, the template DN should be recursive, pointing back to the CoS entry itself as the base suffix for the template.
- In the Directory Server Console, select the Directory tab.
- Browse the tree in the left navigation pane, and select the parent entry that contains your class of service.
- The Properties Editor will appear.
- Select the object classes attribute, and hit "Add Value." Add the extensibleobject object class. This will allow you to add any attribute available in the directory.
- Click on the "Add Attribute" button. Add the cn attribute, and give it a value that will correspond to the attribute value in your target entry. For example, if you select the manager attribute to set the value for a classic CoS, give the cn a value of uid=bparker,ou=people,dc=example,dc=com. You can also set it to a role, such as cn=QA Role,dc=example,dc=com or a regular attribute value (if you selected the employeetype attribute, for example, it can be full time or temporary).
- Click the "Add Attribute" button, and add the attributes that you listed in the CoS. The values you use here will be used throughout the directory in the targeted entries.
- Set the cospriority. There may be more than one CoS that applies to a given attribute in an entry; the cospriority attribute ranks the importance of that particular CoS. The higher cospriority will take precedence in a conflict. The highest priority is 0.
The CoS will be visible in the left navigation pane once there are entries beneath it. For classic CoS, you can add multiple entries, according to the different potential values of the attribute specifier you set.
Editing an Existing CoS
The following procedure describes changing the description and attributes generated on the target entry of an existing class of service.
- In the Directory Server Console, select the Directory tab.
- Browse the tree in the left navigation pane, and select the parent entry that contains your class of service.
- Click General in the left pane to change the CoS name and description.
- Click Attributes in the left pane to add or remove attributes generated by the CoS.
- Click OK to save your changes.
Deleting a CoS
The following procedure describes deleting a CoS:
- In the Directory Server Console, select the Directory tab.
- Browse the tree in the left navigation pane, and select the parent entry that contains your class of service.
- Right-click the CoS, and select Delete. A dialog box appears asking you to confirm the deletion. Click Yes.
- 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
- Creating the CoS Template Entry from the Command-Line
- Example of a Pointer CoS
- Example of an Indirect CoS
- Example of a Classic CoS
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. Table 5-2 lists the object classes associated with each type of CoS definition entry.
Table 5-3 lists attributes that you can use in your CoS definition entries.
The cosAttribute attribute allows an additional qualifier after the attribute value. You can use the following qualifiers:
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=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.
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 Red Hat 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. Table 5-4 describes the CoS definition for each type of CoS.
Creating the CoS Template Entry from the Command-Line
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, 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. 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.
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.
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=example,dc=com tree.
To add a new pointer CoS definition entry to the dc=example,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=example,dc=com root suffix 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
Next, you create the template entry as follows:
dn: cn=exampleUS,ou=data,dc=example,dc=com objectclass: top objectclass: extensibleobject objectclass: cosTemplate postalCode: 44438
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.
Example of an Indirect CoS
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.
First, you add a new indirect CoS definition entry to the dc=example,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=example,dc=com root suffix as follows:
dn: cn=indirectCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: manager cosAttribute: departmentNumber
You do not need to add any additional entries to the directory or modify the manager entries as long as they already contain the departmentNumber attribute. 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.
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=example,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=example,dc=com root suffix, as follows:
dn: cn=classicCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=classicCoS,dc=example,dc=com cosSpecifier: businessCategory cosAttribute: postalCode override
Next, you create the template entries for the sales and marketing departments. Add the CoS attributes to the template entry. The cn of the template sets the value of the businessCategory attribute in the target entry, and then the attributes are added or overwritten according to the value in the template:
dn: cn=sales,cn=classicCoS,dc=example,dc=com objectclass: top objectclass: extensibleobject objectclass: cosTemplate postalCode: 44438 dn: cn=marketing,cn=classicCoS,dc=example,dc=com objectclass: top objectclass: extensibleobject objectclass: cosTemplate postalCode: 99111
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.
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 multi-valued, 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=example,dc=com objectclass: top 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=example,dc=com objectclass: top objectclass: cosSuperDefinition objectlass: cosClassicDefinition cosTemplateDn: cn=managerCOS,dc=example,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=example,dc=com",cn=managerCOS ,dc=example,dc=com objectclass: top objectclass: extensibleobject objectlass: cosTemplate mailboxquota: 1000000
The template provides the value for the mailboxquota attribute, 1000000.
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.