test

Sun Java System Directory Server Enterprise Edition 6.3 管理指南

第 10 章 目录服务器组、角色和 CoS

管理代表用户的条目时，除了在目录中使用数据的分层结构之外，通常还需要创建共享公用属性值的组。目录服务器通过组、角色和服务类 (Class of Service, CoS) 提供了高级条目管理功能。

本章包含以下主题：

关于组、角色和服务类

组、角色和 CoS 的定义如下：

目录服务器可以基于角色、组和 CoS 已计算属性的值来执行搜索。任何操作中使用的过滤字符串都可以包含 nsRole 属性或由 CoS 定义生成的任何属性。还可以使用过滤字符串对此属性的值执行任何比较操作。但是无法为 CoS 已计算属性编制索引。因此，涉及 CoS 已生成属性的任何搜索都可能会消耗大量资源（从时间和内存上）。

为了充分利用角色、组和服务类所提供的功能，请在目录部署的规划阶段确定分组策略。有关这些功能及其如何简化拓扑的描述，请参阅《Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide》中的“Grouping Directory Data and Managing Attributes”。

要想更深入地了解角色和组的工作方式，请参见《Sun Java System Directory Server Enterprise Edition 6.3 Reference》中的第 8  章 “Directory Server Groups and Roles”。有关 CoS 的详细描述，请参见《Sun Java System Directory Server Enterprise Edition 6.3 Reference》中的第 9  章 “Directory Server Class of Service”。

管理组

通过使用组，您可以关联条目以简化管理。例如，使用组可以更轻松地定义访问控制指令 (Access Control Instruction, ACI)。组定义是一些特殊条目，可以在静态列表中指定其成员，也可以提供用于定义一组动态条目的过滤器。

无论组定义条目的位置如何，组的可能成员范围都是整个目录。为了简化管理，所有组定义条目通常都存储在一个位置，一般是根后缀下的 ou=Groups。

组可以分为静态组和动态组两种类型。

Procedure创建新的静态组

无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。

  1. 使用 ldapmodify 命令创建新的静态组。

    例如，要创建名为 System Administrators 的新静态组并添加一些成员，可以使用以下命令：


    $ 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

  2. 检查是否已创建新组以及是否已添加成员。

    例如，要检查 Kirsten Vaughan 是否在新的 System Administrators 组中，请键入：


    $ 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

Procedure创建新的动态组

无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。

  1. 使用 ldapmodify 命令创建新的动态组。

    例如，要创建一个名为 "3rd Floor" 的新动态组（它包含所有房间号以 3 开头的员工），您可以使用以下命令：


    $ 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*)

管理角色

角色是一种备用组机制，在设计上可以使应用程序使用起来更加轻松有效。虽然角色的定义和管理方式与组类似，但是每个成员条目中生成的角色属性将自动表示条目的角色。例如，应用程序可以读取条目的角色，而不必选择组并浏览成员列表。

默认情况下，角色的范围被限定为定义该范围时所在的子树。但是，您可以扩展嵌套角色的范围。可以允许范围嵌套其他子树中的角色，并包含位于目录中任意位置的成员。有关详细信息，请参见扩展角色的范围和嵌套角色定义的示例。

本部分介绍如何安全地使用角色，以及如何从命令行管理角色。

安全地使用角色

要安全地使用角色，必须设置访问控制指令 (Access Control Instruction, ACI) 以保护相应的属性。例如，用户 A 具有受管理角色 MR。受管理角色相当于静态组，通过将 nsRoleDN 属性添加到每个成员条目来为该条目明确指定角色。已通过命令行使用帐户去活锁定了 MR 角色。这意味着用户 A 无法绑定到服务器，因为该用户 nsAccountLock 属性的计算结果为 "true"。但是，假定该用户已经绑定，并发现自己现在因 MR 角色而被锁定。如果没有相应的 ACI 来阻止用户具有 nsRoleDN 属性的写入访问权限，则该用户可以从自己的条目中删除 nsRoleDN 属性并解除锁定。

要阻止用户删除 nsRoleDN 属性，必须应用 ACI。使用过滤角色时，必须保护过滤器中可阻止用户通过修改属性放弃过滤角色的部分。应禁止用户添加、删除或修改过滤角色所使用的属性。同理，如果已计算过滤属性的值，则必须保护可以修改过滤属性值的所有属性。由于嵌套角色可以包含过滤角色和受管理角色，因此对于嵌套角色中包含的每个角色，都应考虑上述几点。

有关设置 ACI 来确保安全性的详细说明，请参见第 7 章，目录服务器访问控制。

从命令行管理角色

角色是在目录管理者可以通过命令行实用程序访问的条目中定义的。创建角色之后，可按以下方式为角色指定成员：

所有角色定义都是从 LDAPsubentry 和 nsRoleDefinition 对象类继承来的。以下示例显示了特定于每类角色的其他对象类和关联属性。

受管理角色定义的示例

要为所有营销人员创建角色，请使用以下 ldapmodify 命令：


$ 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

请注意，nsManagedRoleDefinition 对象类是从 LDAPsubentry、nsRoleDefinition 和 nsSimpleRoleDefinition 对象类继承来的。

通过更新营销人员 Bob 的条目，可以为该成员指定角色，如下所示：


$ 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

nsRoleDN 属性指示该条目是受管理角色的成员。受管理角色由角色定义的 DN 标识。要允许用户修改自己的 nsRoleDN 属性，但阻止用户添加或删除 nsManagedDisabledRole，请添加以下 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";)

过滤角色定义的示例

要为销售经理设置过滤角色（假定这些销售经理都具有 isManager 属性），请使用以下ldapmodify 命令：


$ 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

请注意，nsFilteredRoleDefinition 对象类是从 LDAPsubentry、nsRoleDefinition 和 nsComplexRoleDefinition 对象类继承来的。nsRoleFilter 属性会指定一个过滤器，用于查找 ou=sales 组织中拥有下属的所有员工，例如：


$ 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
注 –

过滤角色的过滤字符串可以基于任何属性，由 CoS 机制生成的已计算属性除外。

如果过滤角色成员是用户条目，您可以选择限制他们在角色中添加或删除自身的能力。可以使用 ACI 保护过滤属性。

嵌套角色定义的示例

嵌套在嵌套角色中的角色是通过 nsRoleDN 属性指定的。可以使用以下命令创建一个角色，该角色同时包含前面示例中所创建的营销人员和销售经理角色的成员：


$ 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

请注意，nsNestedRoleDefinition 对象类是从 LDAPsubentry、nsRoleDefinition 和 nsComplexRoleDefinition 对象类继承来的。nsRoleDN 属性包含营销受管理角色和销售经理过滤角色的 DN。前面示例中的用户 Bob 和 Carla 都将成为此新嵌套角色的成员。

此过滤器的范围包括默认范围（该过滤器所在的子树），以及任何 nsRoleScopeDN 属性值下的子树。在本案例中，ManagerFilter 位于 ou=sales,ou=People,dc=example,dc=com 子树中。必须将此子树添加到该范围。

扩展角色的范围

目录服务器提供了一个属性，该属性允许将角色的范围扩展到角色定义条目的子树之外。此单值属性 nsRoleScopeDN 包含要添加到现有角色的范围的 DN。只能将 nsRoleScopeDN 属性添加到嵌套角色。请参见嵌套角色定义的示例。

Procedure扩展角色的范围

无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。

nsRoleScopeDN 属性允许您扩展某个子树中的角色范围，以包含另一个子树中的条目。例如，假定 example.com 目录树中有两个主要子树：o=eng,dc=example,dc=com（工程子树）和 o=sales,dc=example,dc=com（销售子树）。工程子树中的用户需要访问由销售子树中的角色 (SalesAppManagedRole ) 管理的销售应用程序。要扩展该角色的范围，请执行以下操作：

  1. 在工程子树中为用户创建一个角色。

    例如，创建角色 EngineerManagedRole。此示例使用受管理角色，但也可以是过滤角色或嵌套角色。

  2. 在销售子树中创建一个嵌套角色（例如 SalesAppPlusEngNestedRole），以存储新创建的 EngineerManagedRole 和初始的 SalesAppManagedRole。

  3. 使用要添加的工程子树范围的 DN（在本案例中为 o=eng,dc=example,dc=com）将 nsRoleScopeDN 属性添加到 SalesAppPlusEngNestedRole 中。

    必须为工程用户授予必要的权限，以便该用户可以访问 SalesAppPlusEngNestedRole 角色，进而可以使用销售应用程序。此外，还必须复制角色的整个范围。

    注 –

    对嵌套角色扩展范围的限制意味着，以前在某个域中管理角色的管理员只有权使用其他域中已存在的角色。该管理员无法在其他域中创建任意角色。

服务类

为客户端应用程序检索到条目时，服务类 (Class of Service, CoS) 机制会生成已计算属性，这可以简化条目管理并降低存储要求。CoS 机制允许在条目之间共享属性，并且与组和角色一样，CoS 也依赖于帮助应用程序条目。

有关如何在部署中使用 CoS 的说明，请参见《Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide》中的“Managing Attributes With Class of Service”。

有关如何在目录服务器中实现 CoS 的说明，请参见《Sun Java System Directory Server Enterprise Edition 6.3 Reference》中的第 9  章 “Directory Server Class of Service”。

注 –

任何搜索操作都可以测试 CoS 已生成属性是否存在，或者比较属性值。可以在客户端搜索操作的任何过滤字符串中使用已计算属性的名称，过滤角色中使用的内部过滤器除外。

安全地使用 CoS

以下部分介绍每个 CoS 条目中数据读保护和写保护的一般准则。第 7 章，目录服务器访问控制中介绍了定义单个访问控制指令 (Access Control Instruction, ACI) 的详细过程。

保护 CoS 定义条目

虽然 CoS 定义条目不包含已生成属性的值，但它提供了用于查找该值的信息。读取 CoS 定义条目可了解如何查找包含该值的模板条目。对此条目执行写入操作可修改已计算属性的生成方式。

因此，应该为 CoS 定义条目定义读取 ACI 和写入 ACI。

保护 CoS 模板条目

CoS 模板条目包含 CoS 已生成属性的值。因此，模板中的 CoS 属性至少要受到 ACI 的读取和更新保护。

保护 CoS 的目标条目

CoS 定义范围中的所有条目（将为这些条目生成 CoS 已计算属性）都会参与属性值的计算。

默认情况下，当目标条目中已存在 CoS 属性时，CoS 机制不会覆盖此值。如果不希望如此，可以将 CoS 定义为覆盖目标条目，或保护所有潜在目标条目中的 CoS 属性。

间接 CoS 和传统 CoS 还依赖于目标条目中的说明符属性。此属性用于指定要使用的模板条目的 DN 或 RDN。应该使用 ACI 在整个 CoS 范围内全局保护此属性，或者在需要保护的每个目标条目上单独保护此属性。

保护其他相关性

可以根据其他已生成的 CoS 属性和角色来定义 CoS 已计算属性。您必须了解并保护这些相关性，以确保 CoS 已计算属性受到保护。

例如，目标条目中的 CoS 说明符属性可能是 nsRole。因此，角色定义也必须受 ACI 保护。

通常，计算已计算属性值时所用的任何属性或条目都应具有提供读取和写入访问控制的 ACI。因此，应合理规划或简化复杂的相关性，以降低后续访问控制实现的复杂性。将其他已计算属性上的相关性降至最低可提高目录性能并减少维护操作。

从命令行管理 CoS

由于所有配置信息和模板数据都作为条目存储在目录中，因此可以使用 LDAP 命令行工具配置和管理 CoS 定义。本部分说明如何从命令行创建 CoS 定义条目和 CoS 模板条目。

从命令行创建 CoS 定义条目

所有 CoS 定义条目都具有 LDAPsubentry 对象类，并且是从 cosSuperDefinition 对象类继承来的。此外，每种类型的 CoS 都从特定对象类继承而来，并包含相应属性。下表列出了与每种类型的 CoS 定义条目相关联的对象类和属性。

表 10–1 CoS 定义条目中的对象类和属性

CoS 类型 

CoS 定义条目 

指针 CoS 

objectclass: top

objectclass: LDAPsubentry

objectclass: cosSuperDefinition

objectclass: cosPointerDefinition

cosTemplateDN: DN

cosAttribute: attributeName override merge

间接 CoS 

objectclass: top

objectclass: LDAPsubentry

objectclass: cosSuperDefinition

objectclass: cosIndirectDefinition

cosIndirectSpecifier: attributeName

cosAttribute: attributeName override merge

传统 CoS 

objectclass: top

objectclass: LDAPsubentry

objectclass: cosSuperDefinition

objectclass: cosClassicDefinition

cosTemplateDN: DN

cosSpecifier: attributeName

cosAttribute: attributeName override merge

cosAttribute 始终为多值属性。每个值都定义一个由 CoS 机制生成的属性。

可以在 CoS 定义条目中使用以下属性。有关其中每个属性的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference》中的各个属性。

表 10–2 CoS 定义条目属性

属性 

在 CoS 定义条目中的用途 

cosAttribute

attributeName override merge

定义要生成值的已计算属性的名称。此属性为多值属性，每个值代表将通过模板生成值的属性的名称。override 和 merge 限定符指定在此表后面所述的特殊情况下如何计算 CoS 属性值。

attributeName 不能包含任何子类型。带有子类型的属性名称将被忽略，但会处理 cosAttribute 的其他值。

cosIndirectSpecifier

attributeName

定义目标条目中属性的名称，间接 CoS 将使用此属性的值标识模板条目。已命名的属性称为说明符，并且必须包含每个目标条目中的完整 DN 字符串。此属性为单值属性，但 attributeName 可以是多值属性，以指定多个模板。

cosSpecifier

attributeName

定义目标条目中属性的名称，传统 CoS 将使用此属性的值标识模板条目。已命名的属性称为说明符，并且必须包含可以在模板条目 RDN 中找到的字符串。此属性为单值属性，但 attributeName 可以是多值属性，以指定多个模板。

cosTemplateDN

DN

提供模板条目的完整 DN（对于指针 CoS 定义）或基 DN（对于传统 CoS）。此属性为单值属性。 

注 –

无法通过将 isMemberOf 属性用作 CosSpecifier，来使静态组的所有成员自动继承公用的已计算属性值。

cosAttribute 属性允许 CoS 属性名称后面有两个限定符，即 override 限定符和 merge 限定符。

override 限定符描述当条目中已实际存在 CoS 动态生成属性时的行为。override 可为以下任一选项：

merge 限定符要么不使用，要么为 merge-schemes 形式。此限定符允许 CoS 已计算属性成为多值属性，这些值可以来自多个模板或多个 CoS 定义 。有关详细信息，请参见多值 CoS 属性。

覆盖实际的属性值

可以创建包含 override 限定符的指针 CoS 定义条目，如下所示：


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

此指针 CoS 定义条目表示条目与生成 postalCode 属性值的模板条目 cn=exampleUS,cn=data 相关联。override 限定符表示此值优先于 postalCode 属性值（如果目标条目中存在该属性）。

注 –

如果 CoS 属性是使用 operational 或 override 限定符定义的，则无法对 CoS 范围内任何条目中的“实际”属性值执行写入操作。

多值 CoS 属性

指定 merge-schemes 限定符时，CoS 已生成属性在以下两种情况下可以成为多值属性：

这两种情况可以同时发生，并定义更多的值。但是，重复的值只会在生成的属性中返回一次。

如果不使用 merge-schemes 限定符，模板条目的 cosPriority 属性将用于确定已生成属性在所有模板中的单一值。下一部分将介绍此方案。

merge-schemes 限定符永远不会将目标中定义的“实际”值与通过模板生成的值进行合并。merge 限定符独立于 override 限定符。所有配对情况都可能出现，并且每种情况表示的行为是互补的。 此外，还可以在属性名称后按任意顺序指定这些限定符。

注 –

如果同一属性具有多个 CoS 定义，则这些定义必须具有相同的 override 和 merge 限定符。如果 CoS 定义中存在不同的限定符对，将从所有定义中任意选择一种组合。

CoS 属性优先级

如果存在多个 CoS 定义或多值说明符，但未使用 merge-schemes 限定符，目录服务器将使用优先级属性选择用于定义已计算属性单一值的单一模板。

cosPriority 属性表示纳入考虑的所有模板中某一特定模板的全局优先级。优先级为零代表最高优先级。不包含 cosPriority 属性的模板被视为优先级最低。如果两个或两个以上的模板提供一个属性值，但却具有相同的优先级或没有优先级，此时将任意选择一个值。

使用 merge-schemes 限定符时不会考虑模板优先级。在合并时，纳入考虑的所有模板将定义一个值，而不管这些模板定义的优先级如何。cosPriority 属性是在 CoS 模板条目上定义的，如以下部分所述。

注 –

cosPriority 属性不能具有负值。此外，由间接 CoS 生成的属性不支持优先级。不要在间接 CoS 定义的模板条目中使用 cosPriority。

从命令行创建 CoS 模板条目

使用指针 CoS 或传统 CoS 时，模板条目包含 LDAPsubentry 和 cosTemplate 对象类。必须专门为 CoS 定义创建此条目。如果将 CoS 模板条目作为 LDAPsubentry 对象类的实例，可以不受配置条目的限制而执行一般搜索。

间接 CoS 机制的模板是目录中任意的现有条目。不必提前对目标进行标识或为其提供 LDAPsubentry 对象类，但目标必须具有辅助 cosTemplate 对象类。只有将 CoS 评估为生成已计算属性及其值时，才会访问间接 CoS 模板。

CoS 模板条目必须始终包含 CoS 在目标条目上生成的属性和值。属性名称在 CoS 定义条目的 cosAttribute 属性中指定。

以下示例显示了指针 CoS（生成 postalCode 属性）最高优先级的模板条目：


dn: cn=ZipTemplate,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 95054
cosPriority: 0

以下部分提供了模板条目示例以及每种类型的 CoS 定义条目示例。

指针 CoS 的示例

以下命令创建一个指针 CoS 定义条目，它具有 cosPointerDefinition 对象类。此定义条目使用在上一部分示例中介绍的 CoS 模板条目，以便在 ou=People,dc=example,dc=com 树的所有条目之间共享公用的邮政编码。


$ 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

CoS 模板条目 (cn=ZipTemplate,ou=People,dc=example,dc=com ) 可将 postalCode 属性中存储的值提供给位于 ou=People,dc=example,dc=com 后缀下的所有条目。如果在同一子树中搜索没有邮政编码的任何条目，您将会看到已生成属性的值：


$ 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

间接 CoS 的示例

间接 CoS 命名 cosIndirectSpecifier 属性中的某个属性，以查找特定于每个目标的模板。间接 CoS 的模板条目可以是目录中的任何条目，包括其他用户条目。此间接 CoS 示例使用目标条目的 manager 属性标识 CoS 模板条目。模板条目是经理的用户条目。经理的用户条目包含要生成的属性的值。在本案例中，该值为 departmentNumber 的值。

以下命令将创建间接 CoS 定义条目，此条目包含 cosIndirectDefinition 对象类：


$ 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

接下来，将 cosTemplate 对象类添加到模板条目，并确保这些条目定义要生成的属性。在此示例中，所有经理条目都是模板：


$ 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

使用此 CoS，包含 manager 属性的目标条目（位于 ou=People,dc=example,dc=com 下的条目）将自动包含经理的部门编号。将在目标条目上计算 departmentNumber 属性，因为服务器中不存在该属性。但是，departmentNumber 属性将作为目标条目的一部分返回。例如，如果将 Babs Jensen 的经理定义为 Carla Fuentes，其部门编号如下所示：


$ 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

传统 CoS 的示例

此示例说明如何使用传统 CoS 生成邮政地址。生成的值是在模板条目中指定的，该模板条目的位置由 CoS 定义中的 cosTemplateDN 和目标条目中的 cosSpecifier 属性值共同确定。以下命令使用 cosClassicDefinition 对象类创建定义条目：


$ 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

使用相同的命令，可以创建提供每栋大楼邮政地址的模板条目：


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

使用此 CoS，包含 building 属性的目标条目（位于 ou=People,dc=example,dc=com 下的条目）将自动包含相应的邮政地址。CoS 机制将搜索在 RDN 中具有说明符属性值的模板条目。在此示例中，如果将 Babs Jensen 分配到大楼 B07，则生成的通讯地址如下：


$ 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

创建基于角色的属性

您可以创建传统 CoS 模式，以便为基于条目角色的条目生成属性值。例如，可以使用基于角色的属性将服务器浏览限制设置为逐个条目浏览。

要创建基于角色的属性，请将 nsRole 属性作为传统 CoS 的 CoS 定义条目中的 cosSpecifier。由于 nsRole 属性可以是多值属性，因此可以定义具有多个可能模板条目的 CoS 模式。在确定要使用的模板条目时，为了避免出现模棱两可的情况，可以在 CoS 模板条目中包含cosPriority 属性。

例如，可以创建一个允许经理角色成员超过标准邮箱配额的 CoS。该经理角色如下：


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

传统 CoS 定义条目的创建方式如下：


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

CoS 模板名称必须是 cosTemplateDn 和 nsRole 值（角色的 DN）的组合。例如：


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

CoS 模板条目提供了 mailboxquota 属性值。附加的限定符 override 指示 CoS 覆盖目标条目中的任何现有 mailboxquota 属性值。属于该角色的目标条目将具有由该角色和 CoS 生成的已计算属性，例如：


$ 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
注 –

角色条目和 CoS 定义条目应位于目录树中的相同位置，以便在其范围中具有相同的目标条目。CoS 目标条目也应位于相同的位置，以便于查找和维护。

监视 CoS 插件

目录服务器允许您对 CoS 插件的某些方面进行监视。CoS 监视属性存储在 cn=monitor,cn=Class of Service,cn=plugins,cn=config 条目中。有关此条目下每个属性及其所提供信息的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference》。

设置 CoS 日志记录

强制目录服务器在多个适用的定义条目之间进行任意区分时，目录服务器将记录警告消息。此类警告消息使用以下格式：


Definition /defDN1/ and definition /defDN2/ compete to provide attribute
 '/type/' at priority /level/

当强制目录服务器在多个可能适用的定义条目之间进行任意区分时，您也可以将该服务器配置为记录信息性消息。要执行此操作，请将错误日志设置为包含来自插件的消息。

注 –

由于设置其他日志级别可能会导致日志记录负载过重，因此您可能不希望在生产服务器上设置日志记录。

信息性消息的内容使用以下格式：


Definition /defDN1/ and definition /defDN2/ potentially compete 
to provide attribute '/type/' at priority /level/

然后，您可以选择是否通过在定义条目上适当设置 CoS 优先级来解决这种 CoS 不确定性问题。

维护引用完整性

引用完整性是一种插件机制，可确保条目之间的关系得到维护。有些类型的属性（如组成员身份属性）包含其他条目的 DN。使用引用完整性可确保在删除条目时同时删除包含该条目 DN 的所有属性。

例如，如果从目录中删除用户条目并启用了引用完整性，则服务器也会从该用户所属的所有组中删除该用户。如果未启用引用完整性，则必须由管理员从组中手动删除该用户。如果您要将目录服务器与依赖于目录进行用户和组管理的其他 Sun Java System 产品集成，则此功能十分重要。

引用完整性的工作方式

启用引用完整性插件之后，它将在删除、重命名或移动操作后立即对指定属性执行完整性更新。默认情况下，引用完整性插件处于禁用状态。

只要删除、重命名或移动目录中的用户或组条目，该操作都会记录到引用完整性日志文件中：

instance-path/logs/referint

在指定时间（称为更新时间间隔）过后，服务器将对已启用引用完整性的所有属性执行搜索，并将搜索结果中的条目与日志文件中存在的已删除或已修改条目的 DN 进行匹配。如果日志文件显示条目已被删除，则会删除相应的属性。如果日志文件显示条目已被更改，则会根据更改情况修改相应的属性值。

如果启用了引用完整性插件的默认配置，则在执行删除、重命名或移动操作后，它将立即对 member、uniquemember、owner、seeAlso 和 nsroledn 属性执行完整性更新。但是，您也可以根据自己的需求配置引用完整性插件的行为。可以配置以下行为：

Procedure配置引用完整性插件

注 –

必须为引用完整性插件使用的所有数据库中的所有属性编制索引。需要在所有数据库的配置中创建这些索引。启用追溯更改日志后，必须为 cn=changelog 后缀编制索引。有关信息，请参见第 13 章，目录服务器索引。

某些限制与在复制环境下使用引用完整性插件相关。有关这些限制的列表，请参见复制和引用完整性。

可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 确保已配置所有副本，并且已定义所有复制协议。

  2. 确定要维护引用完整性的属性集，以及要在主服务器上使用的更新时间间隔。

  3. 使用相同的属性集和相同的更新时间间隔在所有主服务器上启用引用完整性插件。

    • 要定义引用完整性的属性，请使用以下命令：


      $ dsconf set-server-prop -h host -p port ref-integrity-attr:attribute-name \
 ref-integrity-attr:attribute-name

    • 要在现有属性列表中添加引用完整性属性，请使用以下命令：


      $ dsconf set-server-prop -h host -p port ref-integrity-attr+:attribute-name

    • 要定义引用完整性更新时间间隔，请使用以下命令：


      $ dsconf set-server-prop -h host -p port ref-integrity-check-delay:duration

    • 要启用引用完整性，请使用以下命令：


      $ dsconf set-server-prop -h host -p port ref-integrity-enabled:on

  4. 确保在所有使用方服务器上禁用引用完整性插件。