Oracle® Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28972-01 |
|
|
PDF · Mobi · ePub |
Beyond the hierarchical structure of data in a directory, managing entries that represent users often requires creating groups that share common attribute values. Directory Server provides advanced entry management functionality through groups, roles, and class of service (CoS).
This chapter covers the following topics:
Groups, roles, and CoS are defined as follows:
Groups are entries that name other entries, either as a list of members or as a filter for members. For groups that consist of a list of members, Directory Server generates values for the isMemberOf
attribute on each user entry. The isMemberOf
attribute on a user entry thus shows all the groups to which that entry belongs.
Roles provide the same functionality as groups, and more, through a mechanism that generates the nsrole
attribute on each member of a role.
CoS generates a computed attribute, which allows entries to share a common attribute value without having to store the attribute in each entry.
You cannot use the isMemberOf
attribute to make all the members of static groups automatically inherit from a common computed attribute value.
Directory Server provides the ability to perform searches that are based on the values of the roles, and groups and the CoS computed attributes. Filter strings used in any operation can include the nsRole
attribute or any attribute generated by a CoS definition. Filter strings can also be used to perform any of the comparison operations on the value of this attribute. However, computed CoS attributes cannot be indexed. Therefore, any search that involves a CoS-generated attribute might consume a large amount of resources in terms of time and memory.
To take full advantage of the features offered by roles, groups, and class of service, determine your grouping strategy in the planning phase of your directory deployment. Refer to Chapter 11, Directory Server Groups and Roles, in the Reference for Oracle Directory Server Enterprise Edition for a description of these features and how they can simplify your topology.
To gain a deeper understanding of how roles and groups work, see Chapter 11, Directory Server Groups and Roles, in the Reference for Oracle Directory Server Enterprise Edition. For a detailed description of CoS, see Chapter 12, Directory Server Class of Service, in the Reference for Oracle Directory Server Enterprise Edition.
Groups enable you to associate entries for ease of administration. For example, using groups makes it easier to define access control instructions (ACIs). Group definitions are special entries that either name their members in a static list or provide a filter that defines a dynamic set of entries.
The scope of possible members of a group is the entire directory, regardless of where the group definition entries are located. To simplify administration, all group definition entries are usually stored in a single location, usually ou=Groups
under the root suffix.
The two types of groups are static groups and dynamic groups.
Static groups. The entry that defines a static group inherits from either the groupOfNames
or groupOfUniqueNames
object class. Group members are listed by their DN as multiple values of the member
or uniqueMember
attribute.
Alternatively, you can use the isMemberOf
attribute for static groups. The isMemberOf
attribute is calculated and added to the user entry at the start of the search. It is then removed again after the search has finished. This functionality provides easy management of groups, and fast read access.
Dynamic groups. The entry that defines a dynamic group inherits from the groupOfURLs
object class. Group membership is defined by one or more filters that are specified in the multivalued memberURL
attribute. The members in a dynamic group are the entries that match any one of the filters whenever the filters are evaluated.
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
Create a new static group using the ldapmodify
command.
For example, to create a new static group called System Administrators and to add some members, you could use this command:
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=System Administrators, ou=Groups, dc=example,dc=com changetype: add cn: System Administrators objectclass: top objectclass: groupOfNames ou: Groups member: uid=kvaughan, ou=People, dc=example,dc=com member: uid=rdaugherty, ou=People, dc=example,dc=com member: uid=hmiller, ou=People, dc=example,dc=com
Check to see that the new group has been created and that the members have been added.
For example, to check that Kirsten Vaughan is in the new System Administrators group, type:
$ ldapsearch -b "dc=example,dc=com" uid=kvaughan isMemberOf uid=kvaughan,ou=People,dc=example,dc=com isMemberOf: cn=System Administrators, ou=Groups, dc=example,dc=com isMemberOf: cn=HR Managers,ou=groups,dc=example,dc=com
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
Create a new dynamic group by using the ldapmodify
command.
For example, to create a new dynamic group called "3rd Floor", which includes all employees whose room numbers start with 3, you could use this command:
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=3rd Floor, ou=Groups, dc=example,dc=com changetype: add cn: 3rd Floor objectclass: top objectclass: groupOfUrls ou: Groups memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)
A role is an alternate grouping mechanism that is designed to be more efficient and easier for applications to use. While roles are defined and administered like groups, a generated role attribute in each member entry automatically indicates the roles of an entry. For example, an application can read the roles of an entry, rather than having to select a group and browse the members list.
By default, the scope of a role is limited to the subtree where the scope is defined. However, you can extend scoping of the nested role. You can allow the scope to nest roles located in other subtrees and to have members anywhere in the directory. For details see To Extend the Scope of a Role and Example of a Nested Role Definition.
This section explains how to use roles securely, and how to manage roles from the command line.
To use roles securely, you must set access control instructions (ACIs) to protect appropriate attributes. For example, user A possesses the managed role, MR. Managed roles are equivalent to static groups, and explicitly assign a role to each member entry by adding the nsRoleDN
attribute to the entry. 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 no ACI exists to prevent the user from having write access to the nsRoleDN
attribute, the user can remove the nsRoleDN
attribute from his own entry and unlock himself.
To prevent users from removing the nsRoleDN
attribute, you must apply ACIs. With filtered roles, you must protect the part of the filter that would prevent the user from being able to relinquish the filtered role by modifying an attribute. Users should not be allowed to add, delete, or modify the attribute used by the filtered role. In the same way, if the value of the filter attribute is computed, all the attributes that can modify the value of the filter attribute need to be protected. As nested roles can contain filtered and managed roles, the preceding points should be considered for each of the roles that are contained in the nested role.
For detailed instructions on setting ACIs for security, see Chapter 6, "Directory Server Access Control".
Roles are defined in entries that the Directory Administrator can access through command-line utilities. After you create a role, you assign members to the role 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 that are specified in the nsRoleDN
attributes of the nested role definition entry.
All role definitions inherit from the LDAPsubentry
and nsRoleDefinition
object classes. The following example shows additional object classes and associated attributes specific to each type of role.
To create a role for all marketing staff, use the following ldapmodify
command:
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Marketing,ou=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 who is named Bob by updating his entry as follows:
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Bob Arnold,ou=marketing,ou=People,dc=example,dc=com changetype: modify add: nsRoleDN nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com
The nsRoleDN
attribute indicates that the entry is a member of a managed role. The managed role is identified by the DN of its role definition. To allow users to modify their own nsRoleDN
attribute, but to prevent users from adding or removing the nsManagedDisabledRole
, add the following ACI:
aci: (targetattr="nsRoleDN")(targattrfilters="add=nsRoleDN: (!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example, dc=com)") (version3.0;aci "allow mod of nsRoleDN by self except for critical values"; allow(write) userdn="ldap:///self";)
To set up a filtered role for sales managers, assuming that they all have the isManager
attribute, use the following ldapmodify
command:
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerFilter nsRoleFilter: (isManager=True) 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 a filter that finds all employees in the ou=sales
organization that have subordinates, for example:
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)" dn: cn=Carla Fuentes,ou=sales,ou=People,dc=example,dc=comcn: Carla Fuentes isManager: TRUE... nsRole: cn=ManagerFilter,ou=sales,ou=People, dc=example,dc=com
Note:
The filter string of a filtered role can be based on any attribute, except computed attributes that are generated by the CoS mechanism.
When filtered role members are user entries, you can choose to restrict their ability to add or remove themselves from the role. Protect the filtered attributes with ACIs.
The roles that are nested within the nested role are specified by using the nsRoleDN
attribute. Use the following command to create a role that contains both the marketing staff and sales manager members of the roles created in the previous examples:
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=MarketingSales,ou=marketing,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsNestedRoleDefinition cn: MarketingSales nsRoleDN: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com nsRoleScopeDN: ou=sales,ou=People,dc=example,dc=com
Notice that 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 Carla, would be members of this new nested role.
The scope of this filter includes the default scope, which is the subtree where the filter is located, and the subtree below any values of the nsRoleScopeDN
attribute. In this case, the ManagerFilter
is in the ou=sales,ou=People,dc=example,dc=com
subtree. This subtree must be added to the scope.
Directory Server provides an attribute that allows the scope of a role to be extended beyond the subtree of the role definition entry. This single-valued attribute, nsRoleScopeDN
, contains the DN of the scope to be added to an existing role. The nsRoleScopeDN
attribute can only be added to a nested role. See Example of a Nested Role Definition.
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
The nsRoleScopeDN
attribute enables you to extend the scope of a role in one subtree to include an entry in another subtree. For example, imagine two main subtrees in the example.com directory tree: o=eng,dc=example,dc=com
( the engineering subtree) and o=sales,dc=example,dc=com
(the sales subtree.) A user in the engineering subtree requires access to a sales application governed by a role in the sales subtree (SalesAppManagedRole
). To extend the scope of the role, do the following:
Create a role for the user in the engineering subtree.
For example, create the role EngineerManagedRole.
This example uses a managed role, but it could just as well have been a filtered or nested role.
Create a nested role, for example, SalesAppPlusEngNestedRole
, in the sales subtree to house the newly created EngineerManagedRole
and the initial SalesAppManagedRole
.
Add the nsRoleScopeDN
attribute to the SalesAppPlusEngNestedRole
, with the DN of the engineering subtree scope that you want to add, in this case, o=eng,dc=example,dc=com
.
The necessary permissions must be granted to the engineering user so that he can access the SalesAppPlusEngNestedRole
role and, in turn, the sales application. In addition, the entire scope of the role must be replicated.
Note:
The restriction of extended scope to nested roles means that an administrator who previously managed roles in one domain only has rights to use the roles that already exist in the other domain. The administrator is not able to create an arbitrary role in the other domain.
The class of service (CoS) mechanism generates computed attributes as an entry is retrieved for a client application, which simplifies entry management and reduces storage requirements. The CoS mechanism allows attributes to be shared between entries, and as with groups and roles, CoS relies on helper entries.
For an explanation of how you can use CoS in your deployment, see Chapter 12, Directory Server Class of Service, in the Reference for Oracle Directory Server Enterprise Edition.
Note:
Any search operation can test the existence of a CoS-generated attribute or compare the value of the attribute. The names of the computed attributes may be used in any filter string from a client search operation, except in an internal filter used in a filtered role.
You must restart the Directory Server instance to consider the new CoS definitions.
The following sections describe the general principles for read and write protection of data in each of the CoS entries. The detailed procedure for defining individual access control instructions (ACIs) is described in Chapter 6, "Directory Server Access Control".
Although the CoS definition entry does not contain the value of the generated attribute, it does provide the information to find that value. Reading the CoS definition entry reveals how to find the template entry that contains the value. Writing to this entry modifies how the computed attribute is generated.
You should therefore define both read and write ACIs for the CoS definition entries.
The CoS template entry contains the value of the generated CoS attribute. Therefore, at a minimum, the CoS attribute in the template must be protected by an ACI for both reading and updating.
In the case of pointer CoS, the single template entry should not be allowed to be renamed. In most cases, it is simplest to protect the entire template entry.
With classic CoS, all template entries have a common parent specified in the definition entry. If only templates are stored in this parent entry, access control to the parent entry protects the templates. However, if other entries beneath the parent require access, the template entries must be protected individually.
In the case of indirect CoS, the template can be any entry in the directory, including user entries that might still need to be accessed. Depending on your needs, you can either control access to the CoS attribute throughout the directory or ensure that the CoS attribute is secure in each entry that is used as a template.
All entries in the scope of a CoS definition, for which the computed CoS attribute is generated, also contribute to computing its value.
When the CoS attribute already exists in a target entry, by default, the CoS mechanism does not override this value. If you do not want this behavior, define your CoS to override the target entry, or protect the CoS attribute in all potential target entries.
Both indirect and classic CoS also rely on a specifier attribute in the target entry. This attribute specifies the DN or RDN of the template entry to use. You should use an ACI to protect this attribute either globally throughout the scope of the CoS or individually on each target entry where it is needed.
Computed CoS attributes can be defined in terms of other generated CoS attributes and roles. You must understand and protect these dependencies to ensure that your computed CoS attribute is protected.
For example, the CoS specifier attribute in a target entry could be nsRole
. Therefore the role definition must also be protected by an ACI.
In general, any attribute or entry that is involved in the computation of the computed attribute value should have an ACI for both read and write access control. For this reason, complex dependencies should be well planned or simplified to reduce subsequent complexity of access control implementation. Keeping dependencies on other computed attributes to a minimum improves directory performance and reduces maintenance.
Because all configuration information and template data are stored as entries in the directory, you can use the LDAP command-line tools to configure and manage CoS definitions. This section shows how to create CoS definition entries and CoS template entries from the command line.
All CoS definition entries have the LDAPsubentry
object class and inherit from the cosSuperDefinition
object class. In addition, each type of CoS inherits from specific object classes and contains the corresponding attributes. The following table lists the object classes and attributes that are associated with each type of CoS definition entry.
Table 9-1 Object Classes and Attributes in CoS Definition Entries
CoS Type | CoS Definition Entry |
---|---|
Pointer CoS |
|
Indirect CoS |
|
Classic CoS |
|
In all cases, cosAttribute
is multivalued. Each value defines an attribute that is generated by the CoS mechanism.
You can use the following attributes in CoS definition entries. For more information about each of these attributes, see the individual attributes in the Man Page Reference for Oracle Directory Server Enterprise Edition.
Table 9-2 CoS Definition Entry Attributes
Attribute | Purpose Within the CoS Definition Entry |
---|---|
attributeName override merge |
Defines the name of the computed attribute for which you want to generate a value. This attribute is multivalued, and each value represents the name of an attribute whose value is generated from the template. The override and merge qualifiers specify how the CoS attribute value is computed in special cases described following this table. The attributeName cannot contain any subtypes. Attribute names with subtypes are ignored, but other values of |
attributeName |
Defines the name of the attribute in target entries whose value is used by indirect CoS to identify the template entry. The named attribute is called the specifier and must contain a full DN string in each target entry. This attribute is single-valued, but the attributeName can be multivalued to designate multiple templates. |
attributeName |
Defines the name of the attribute in target entries whose value is used by classic CoS to identify the template entry. The named attribute is called the specifier and must contain a string that can be found in the RDN of template entries. This attribute is single-valued, but the attributeName can be multivalued to designate multiple templates. |
DN |
Provides the full DN of the template entry for a pointer CoS definition or the base DN of the template entry for classic CoS. This attribute is single-valued. |
Note:
You cannot use the isMemberOf
attribute as a CosSpecifier
to make all the members of static groups automatically inherit from a common computed attribute value.
The cosAttribute
attribute allows two qualifiers following the name of the CoS attribute, the override qualifier and the merge qualifier.
The override qualifier describes the behavior when an attribute that is dynamically generated by CoS already physically exists in the entry. The override qualifier can be one of the following:
default
(or no qualifier) - Indicates that the server does not override a real attribute value stored in the entry when the attribute is of the same type as the computed attribute.
override
- Indicates that the server always returns the value generated by the CoS, even when a value is stored with the entry.
operational
- 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 to be returned. The operational
qualifier has the same behavior as the override
qualifier.
You can only make an attribute operational if the attribute is also defined as operational in the schema. For example, if your CoS generates a value for the description
attribute, you cannot use the operational
qualifier because the description
attribute is not marked operational in the schema.
The merge qualifier is either absent or merge-schemes
. This qualifier allows the computed CoS attribute to be multivalued, either from multiple templates or multiple CoS definitions. For more information, see Multivalued CoS Attributes.
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: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=exampleUS,cn=data cosAttribute: postalCode override
This pointer CoS definition entry indicates that the entry is associated with the template entry cn=exampleUS,cn=data
that generates the value of the postalCode
attribute. The override
qualifier indicates that this value takes precedence over the value of the postalCode
attribute if the attribute exists in a target entry.
Note:
If the CoS attribute is defined with the operational
or override
qualifiers, you cannot perform write operations on the "real" value of that attribute in any entry in the CoS scope.
When you specify the merge-schemes
qualifier, the generated CoS attribute can be multivalued in two ways:
With indirect or classic CoS, the specifier attributes in target entries can be multivalued. In this case, each value determines a template, and the value from each template is part of the generated value.
Multiple CoS definition entries of any type can contain the same attribute name in their cosAttribute
. In this case, if all definitions contain the merge-schemes
qualifier, the generated attribute contains all values computed by each definition.
The two situations can occur together and define even more values. However, in all cases, duplicate values will only be returned one time in a generated attribute.
In the absence of the merge-schemes
qualifier, the cosPriority
attribute of the template entry is used to determine a single value among all templates for the generated attribute. This scenario is described in the next section.
The merge-schemes
qualifier never merges a "real" value that is defined in the target with generated values from the templates. The merge qualifier is independent of the override qualifier. All pairings are possible, and the behaviors implied by each are complimentary. Also, the qualifiers can be specified in any order after the attribute name.
Note:
When there are multiple CoS definitions for the same attribute, the definitions must all have the same override and merge qualifiers. When different pairs of qualifiers occur in CoS definitions, one of the combinations is selected arbitrarily among all definitions.
If multiple CoS definitions or multivalued specifiers exist, but no merge-schemes
qualifier, Directory Server uses a priority attribute to select a single template that defines the single value of the computed attribute.
The cosPriority
attribute represents the global priority of a particular template among all those being considered. A priority of zero is the highest priority. Templates that contain no cosPriority
attribute are considered the lowest priority. When two or more templates provide an attribute value but have the same or no priority, a value is chosen arbitrarily.
Template priorities are not taken into account when using the merge-schemes
qualifier. When merging, all templates being considered define a value regardless of any priority that the templates define. The cosPriority
attribute is defined on CoS template entries as described in the following section.
Note:
The cosPriority
attribute must not have a negative value. Also, attributes generated by indirect CoS do not support priority. Do not use cosPriority
in template entries of an indirect CoS definition.
When using pointer CoS or classic CoS, the template entry contains the LDAPsubentry
and cosTemplate
object classes. This entry must be created specifically for the CoS definition. Making the CoS template entry an instance of the LDAPsubentry
object class allows ordinary searches to be performed unhindered by the configuration entries.
The template of the indirect CoS mechanism is an arbitrary, existing entry in the directory. The target does not need to be identified ahead of time or given the LDAPsubentry
object class, but the target must have the auxiliary cosTemplate
object class. The indirect CoS template is accessed only when the CoS is evaluated to generate a computed attribute and its value.
In all cases, the CoS template entry must contain the attribute and the value that is generated by the CoS on the target entries. The attribute name is specified in the cosAttribute
attribute of the CoS definition entry.
The following example shows a template entry of the highest priority for a pointer CoS that generates the postalCode
attribute:
dn: cn=ZipTemplate,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate postalCode: 95054 cosPriority: 0
The following sections provide examples of template entries along with examples of each type of CoS definition entry.
The following command creates a pointer CoS definition entry that has the cosPointerDefinition
object class. This definition entry uses the CoS template entry that is stated in the example in the previous section to share a common postal code among all entries in the ou=People,dc=example,dc=com
tree.
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=pointerCoS,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=ZipTemplate,ou=People,dc=example,dc=com cosAttribute: postalCode
The CoS template entry (cn=ZipTemplate,ou=People,dc=example,dc=com
) supplies the value stored in its postalCode
attribute to all entries located under the ou=People,dc=example,dc=com
suffix. If you search for any entry that does not have a postal code in the same subtree, you will see the value of the generated attribute:
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... postalCode: 95054
Indirect CoS names an attribute in the cosIndirectSpecifier
attribute to locate the template specific to each target. The template entry for indirect CoS may be any entry in the directory, including other user entries. This example indirect CoS uses the manager
attribute of the target entry to identify the CoS template entry. The template entry is the manager's user entry. The manager's user entry contains the value of the attribute to generate. The value is that of departmentNumber
in this case.
The following command creates the indirect CoS definition entry, which contains the cosIndirectDefinition
object class:
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=generateDeptNum,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: manager cosAttribute: departmentNumber
Next, add the cosTemplate
object class to the template entries, and make sure that they define the attribute to be generated. In this example, all manager entries are templates:
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Carla Fuentes,ou=People,dc=example,dc=com changetype: modify add: objectclass objectclass: cosTemplate - add: departmentNumber departmentNumber: 318842
With this CoS, target entries (the entries under ou=People,dc=example,dc=com
) that contain the manager
attribute automatically have the department number of their manager. The departmentNumber
attribute is computed on the target entries because it does not exist in the server. However, the departmentNumber
attribute is returned as part of the target entry. For example, if Babs Jensen's manager is defined to be Carla Fuentes, her department number is the following:
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... manager: cn=Carla Fuentes,ou=People,dc=example,dc=com departmentNumber: 318842
This example shows how to generate a postal address with a classic CoS. The generated value is specified in a template entry that is located by a combination of the cosTemplateDN
in the CoS definition and the value of the cosSpecifier
attribute in the target entry. The following command creates the definition entry by using the cosClassicDefinition
object class:
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=classicCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: ou=People,dc=example,dc=com cosSpecifier: building cosAttribute: postalAddress
Using the same command, create the template entries that give the postal address for each building:
dn: cn=B07,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate postalAddres: 7 Old Oak Street, Anytown, CA 95054
With this CoS, target entries (the entries under ou=People,dc=example,dc=com
) that contain the building
attribute will automatically have the corresponding postal address. The CoS mechanism searches for a template entry that has the specifier attribute value in its RDN. In this example, if Babs Jensen is assigned to building B07, her postal address is generated as follows:
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... building: B07 postalAddress: 7 Old Oak Street, Anytown, CA 95054
You can create classic CoS schemes that generate attribute values for an entry that is 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 is as follows:
dn: cn=ManagerRole,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerRole nsRoleFilter: (isManager=True) Description: filtered role for managers
The classic CoS definition entry is created as follows:
dn: cn=generateManagerQuota,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=managerCOS,ou=People,dc=example,dc=com cosSpecifier: nsRole cosAttribute: mailboxquota override
The CoS template name must be a combination of the cosTemplateDn
and the value of nsRole
, which is the DN of the role. For example:
dn:cn="cn=ManagerRole,ou=People,dc=example,dc=com",\ cn=managerCOS,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate mailboxquota: 1000000
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. Target entries that are members of the role will have computed attributes generated by the role and by the CoS, for example:
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -\ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)" dn: cn=Carla Fuentes,ou=People,dc=example,dc=comcn: Carla Fuentes isManager: TRUE...nsRole: cn=ManagerRole,ou=People,dc=example,dc=com mailboxquota: 1000000
Note:
The role entry and the CoS definition entry should be located in the same place in the directory tree so that they have the same target entries in their scope. The CoS target entry should also be located in the same place so that it is easy to find and maintain.
Directory Server enables you to monitor certain aspects of the CoS plug-in. CoS monitoring attributes are stored in the cn=monitor,cn=Class of Service,cn=plugins,cn=config
entry. For details of the each attribute under this entry and the information that they provide, see the Man Page Reference for Oracle Directory Server Enterprise Edition.
Directory Server logs warning messages when it is forced to make an arbitrary distinction among multiple applicable definition entries. Such warning messages takes this form:
Definition /defDN1/ and definition /defDN2/ compete to provide attribute '/type/' at priority /level/
You can also configure Directory Server to log informational messages when the server is forced to make an arbitrary distinction among multiple, potentially applicable definition entries. To do so, set the error log to include messages from plug-ins.
Note:
Because setting additional log levels can result in a heavy logging load, you might not want to set logging on a production server.
The content of informational messages takes the following form:
Definition /defDN1/ and definition /defDN2/ potentially compete to provide attribute '/type/' at priority /level/
You can then choose whether to resolve such cases of CoS ambiguity by setting CoS priorities appropriately on the definition entries.
Referential integrity is a plug-in mechanism that ensures that relationships between entries are maintained. Several types of attributes, such as those for group membership, contain the DN of another entry. Referential integrity can be used to ensure that when an entry is removed, all attributes that contain its DN are also removed.
For example, if a user's entry is removed from the directory and referential integrity is enabled, the server also removes the user from any groups of which the user is a member. If referential integrity is not enabled, the user must be manually removed from the group by the administrator. This is an important feature if you are integratingDirectory Server with other Sun products that rely on the directory for user and group management.
When the referential integrity plug-in is enabled it performs integrity updates on specified attributes immediately after a delete, rename, or move operation. By default, the referential integrity plug-in is disabled.
Whenever you delete, rename, or move a user or group entry in the directory, the operation is logged to the referential integrity log file:
instance-path/logs/referint
After a specified time, known as the update interval, the server performs a search on all attributes for which referential integrity is enabled, and matches the entries resulting from that search with the DNs of deleted or modified entries present in the log file. If the log file shows that the entry was deleted, the corresponding attribute is deleted. If the log file shows that the entry was changed, the corresponding attribute value is modified accordingly.
When the default configuration of the referential integrity plug-in is enabled, it performs integrity updates on the member
, uniquemember
, owner
, seeAlso
, and nsroledn
attributes immediately after a delete, rename, or move operation. You can, however, configure the behavior of the referential integrity plug-in to suit your own requirements. The following behavior can be configured:
Record referential integrity updates in a different file.
Modify the update interval.
If you want to reduce the impact that referential integrity updates has on your system, you might want to increase the amount of time between updates.
Select the attributes to which you apply referential integrity.
If you use or define attributes containing DN values, you might want the referential integrity plug-in to monitor them.
Note:
All attributes in all databases that are used by the referential integrity plug-in must be indexed. The indexes need to be created in the configuration of all the databases. When the retro changelog is enabled, the cn=changelog
suffix must be indexed. For information, see Chapter 12, "Directory Server Indexing".
Certain limitations are associated with using the referential integrity plug-in in a replicated environment. For a list of these limitations, see Replication and Referential Integrity.
You can use the web interface Directory Service Control Center (DSCC) to perform this task.
Make sure that all replicas are configured and that all replication agreements are defined.
Determine the set of attributes for which you will maintain referential integrity and the update interval that you want to use on your master servers.
Enable the referential integrity plug-in on all master servers using the same set of attributes and the same update interval.
To define the attributes for referential integrity, use this command:
$ dsconf set-server-prop -h host -p port ref-integrity-attr:attribute-name \ ref-integrity-attr:attribute-name
To add a referential integrity attribute to an existing list of attributes, use this command:
$ dsconf set-server-prop -h host -p port ref-integrity-attr+:attribute-name
To define the referential integrity update interval, use this command:
$ dsconf set-server-prop -h host -p port ref-integrity-check-delay:duration
To enable referential integrity, use this command:
$ dsconf set-server-prop -h host -p port ref-integrity-enabled:on
Ensure that the referential integrity plug-in is disabled on all consumer servers.