第 5 章   高级条目管理


除在目录中建立数据层次结构外，管理诸如用户等条目通常还需要创建组和共享公用属性值。iPlanet Directory Server 通过组、角色和服务类 (CoS) 提供高级条目管理功能。

组是以成员列表方式或成员过滤器方式命名其它条目的条目。角色不仅提供相同的功能，而且通过一种机制生成有关每个角色成员的 nsrole 属性。CoS 还生成一种虚拟属性，从而允许条目共享公用属性值，而无需将该属性值存储在各个条目中。

本章介绍下列分组机制及其操作过程：

• 管理组

• 分配角色

• 定义服务类 (CoS)

为充分利用角色和服务类的功能，最好在目录部署的规划阶段就确定目录的拓扑结构。有关详细信息，请参阅 iPlanet Directory Server 部署指南。

管理组

---

组是一种建立条目关联以便于管理的机制，例如定义 ACI。该机制在先前版本的 iPlanet Directory Server 已经提供，主要用于与旧服务器版本实现兼容。有关创建同等角色定义的过程，请参阅“分配角色”。

下面部分将介绍静态组和动态组的管理。有关组的概念性说明，请参阅 iPlanet Directory Server 部署指南。有关管理组的详细信息，请参阅通过 Directory Console 管理服务器 。

组定义是特殊的条目，用于在静态列表中命名组成员，或者提供定义一组动态条目的过滤器。一个组所能包含的成员的范围是整个目录，而不管组定义项在什么位置。为简化管理，所有组定义项通常储存在一个位置，一般是根后缀下的 ou=Groups。

定义静态组的条目继承 groupOfUniqueNames 对象类。组成员按它们的 DN 列出，作为 uniqueMember 属性的多个值。

定义动态组的条目继承 groupOfUniqueNames 和 groupOfURLs 对象类。组成员资格由 memberURL 属性指定的过滤器定义。动态组的成员是每次评估过滤器时与过滤器匹配的条目。

“条目编辑器”管理组条目的两种类型。该对话框用于给组命名，然后创建或修改成员列表或成员过滤器。本部分包含下列创建和修改组的操作步骤：

• “添加新静态组”

• “添加新动态组”

• “修改组定义”

• “删除组定义”

添加新静态组

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 右键单击目录树中想要添加新组的条目。选择“新建”>“组”。

   也可转到“对象”菜单，选择“新建”>“组”。

3. 单击左侧窗口中的“常规”。在“组名”字段中，键入新组的名称。

   组名为必需项。

4. 在“说明”字段中输入对新组的说明。

5. 单击左侧窗口中的“成员”。在右侧窗口中，选择“静态组”选项卡。单击“添加”以将新成员添加到组中。

   此时显示标准的“搜索用户和组”对话框。

6. 在“搜索”下拉列表中，选择所要搜索的条目类型（用户、组或上述二者），然后单击“搜索”。在搜索结果中选择一个或多个条目，然后单击“确定”。

   
   

   ---

   注意	由于链接原因，静态组成员可能在远程位置上。可以使用参照完整性插件来确保所删除的成员条目也将自动从静态组条目中删除。有关将参照完整性与链接配合使用的信息，请参阅“配置链接策略”。

   ---

   
   

7. 单击左侧窗口中的“语言”，从而为组添加特定语言的信息。

8. 单击“确定”以创建新组。它将作为创建位置上的一个子项出现。

添加新动态组

1. 执行“添加新静态组”中的步骤 1-4。

2. 单击左侧窗口中的“成员”。在右侧窗口中，选择“动态组”选项卡。单击“添加”以创建用于数据库查询的 LDAP URL。

   此时显示标准的“构造及测试 LDAP URL”对话框。

3. 在文本字段中输入一个 LDAP URL，或者选择“构造”，从而在引导下完成一个包含组过滤器的 LDAP URL 的构造。构造 URL 后单击“确定”。

4. 单击左侧窗口中的“语言”，从而为组添加特定语言的信息。

5. 单击“确定”以创建新组。

   新组出现在目录树中。

修改组定义

1. 在 Directory Server Console 上，选择“目录”选项卡。

2. 在目录树中，双击要修改的组条目，或者从“对象”菜单中选择“打开”。

   用于修改组定义项的“编辑项目”对话框出现。

3. 在“常规”、“成员”或“语言”类别中修改组信息。单击“确定”。

   要查看更改结果，请转到“视图”菜单，选择“刷新”。

删除组定义

要删除任一类型的组，只需删除定义该组的条目即可。

分配角色

---

角色是一种新的分组机制，设计用于提高效率和便于应用程序使用。角色的定义和管理都与组相似，但此外，角色成员条目还有一个生成的属性，该属性指明其担任的角色。例如，应用程序可以直接读取条目的角色，而不用先选择组然后再浏览成员列表。

本部分包含下列主题：

• “关于角色”

• “角色限制”

• “使用控制台管理角色”

• “使用命令行管理角色”

• “安全使用角色”

关于角色

每个角色都有自己的成员，即拥有该角色的条目。与组一样，角色成员可以明确指定，也可以动态指定。角色机制自动生成 nsRole 属性，它包含该条目所属的所有角色定义项的 DN。

指定角色成员资格的方式与所要使用的角色类型有关。iPlanet Directory Server 支持三类角色：

• 受管理的角色 — 明确向成员条目分配角色。

• 已过滤的角色 — 如果条目与指定的 LDAP 过滤器相匹配，则条目为角色成员。因此，该角色与每个条目中包含的属性有关。

• 嵌套角色 — 用于创建包含其它角色的角色。

在受管理的角色中，管理员通过将 nsRoleDN 属性添加到条目来分配角色。属性的值就是该角色定义项的 DN。受管理的角色相当于一个静态组，不同之处在于静态组的成员资格在每个条目中定义，而不在角色定义项中定义。

已过滤的角色相当于动态组：它们都在其 nsRoleFilter 属性中定义过滤器字符串。但是，已过滤的角色涵盖的范围是其所在的子树，即在其定义项的父项的下面。每当服务器返回一个在过滤角色范围内的条目时（即它与过滤器字符串相匹配），则该条目将包含标识角色的 nsRole 生成属性。

nsRole 属性属于计算属性，它并不与条目一起存储，而是作为操作结果中的常规属性返回到客户机应用程序。但由于是服务器为客户机应用程序执行的操作，因此评估角色比评估组需要占用更大量的资源。然而，检查角色成员资格的方法是一致的，且在服务器端透明进行。

---

注意	1. nsRole 属性只供角色机制使用，并且受到保护以防被修改。但是，该属性可以被读取，您可以定义访问控制从而保护其不被读取。 2. nsRole 属性不可用于搜索过滤器。如果希望某个应用程序读取 nsRole 属性，必须使用其它过滤器执行搜索，然后在搜索操作返回的条目中读取 nsRole 属性的值。

---

有关如何在目录中使用角色的详细信息，请参阅 iPlanet Directory Server 部署指南。

角色限制

创建用于支持目录服务的角色时，需要注意下列限制条件：

角色和链接。如果目录树是利用链接功能在多个服务器上分布的，则定义角色的条目必须与拥有这些角色的条目位于同一服务器上。如果一个服务器（比如服务器 A）通过链接功能接收另一个服务器（比如服务器 B）的条目，则这些条目将包含在 B 上定义的角色，但不会被分配 A 上定义的任何角色。

已过滤的角色不可使用 CoS 的生成属性。已过滤的角色的过滤器字符串不可基于 CoS 虚拟属性的值（请参阅“关于 CoS”）。但是，Cos 定义中的说明符属性可以引用由角色定义生成的 nsRole 属性（请参阅“创建基于角色的属性”）。

使用控制台管理角色

本部分包含下列创建和修改角色的操作步骤：

• “创建受管理的角色”

• “创建过滤角色”

• “创建嵌套角色”

• “查看和编辑条目的角色”

• “修改角色项”

• “去活角色”

• “重新激活角色”

• “删除角色”

创建角色时，需要决定用户能否将自身添加到角色中，以及能否从角色中删除自身。有关角色和访问控制的详细信息，请参阅“安全使用角色”。

创建受管理的角色

受管理的角色允许您创建明确枚举的成员列表。向条目中添加受管理的角色可通过为条目添加 nsRoleDN 属性来完成。

要创建成员并将其添加到受管理的角色中：

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 浏览目录树，选择新角色的父项。

3. 转到“对象”菜单，然后选择“新建”>“角色”。也可右键单击条目并选择“新建”>“角色”。

   此时显示“创建新角色”对话框。

4. 单击左侧窗口中的“常规”。在“角色名”字段中，键入新角色的名称。

   角色名为必需项。

5. 在“说明”字段中输入新角色的说明。

6. 单击左侧窗口中的“成员”。

7. 在右侧窗口中，选择“受管理的角色”。单击“添加”，将新条目添加到成员列表中。

   此时显示标准的“搜索用户和组”对话框。

8. 在“搜索”下拉列表中，选择“用户”，然后单击“搜索”。选择所返回的条目之一，然后单击“确定”。

9. 完成向角色中添加条目后，单击“确定”。

   新的角色将显示在目录中，并带有已过滤的角色的图标。

创建已过滤的角色

根据各个条目所含的特定属性，可以将条目分配给已过滤角色。这是通过指定 LDAP 过滤器来实现的。与过滤器相匹配的条目即被视为拥有该角色。

要创建成员并将其添加到已过滤角色中：

1. 执行“创建受管理的角色”的步骤 1-5。

2. 单击左侧窗口中的“成员”。

3. 在右侧窗口中，选择“已过滤的角色”。

4. 在文本字段中输入一个 LDAP 过滤器，或者单击“构造”，从而在指导下完成一个 LDAP 过滤器的构造过程。

5. 如果单击“构造”，则会显示标准 LDAP URL 构造对话框。忽略 LDAP 服务器主机、端口、基本 DN 和搜索等字段（因为无法为过滤角色的定义指定搜索范围）。
   1. 从“搜索内容”下拉列表中选择要过滤的条目类型。

      可以选择用户、组或选择两者。

   2. 从“搜索范围”下拉列表中选择属性。后面的两个字段可用于精简搜索过程，方法是从下拉列表中选择限定符（例如包含、不包含、是、非）并在文本框中输入属性名称。要添加其它过滤器，请单击“更多”。要删除不必要的过滤器，请单击“较少”。

   3. 单击“确定”以保存过滤器。

6. 单击“测试”可试用过滤器。

   “过滤器测试结果”对话框将显示与过滤器相匹配的条目。

7. 单击“确定”。

   新的角色将显示在目录中，并带有已过滤的角色的图标。

创建嵌套角色

嵌套角色用于创建包含其它角色的角色。创建嵌套角色前，必须已经存在另一个角色。创建嵌套角色时，控制台将显示可用于嵌套的角色列表。嵌套角色中所嵌套的角色是用 nsRoleDN 属性指定的。

要创建成员并将其添加到嵌套角色中：

1. 执行“创建受管理的角色”的步骤 1-5。

2. 单击左侧窗口中的“成员”。

3. 在右侧窗口中，选择“嵌套角色”。

4. 单击“添加”，将角色添加到列表中。嵌套角色的成员是其它现有角色的成员。

   此时显示“角色选择器”对话框。

5. 从“可用角色”列表中选择角色，然后单击“确定”。

6. 单击“确定”。

   新的角色将显示在目录中，并带有嵌套角色的图标。

查看和编辑条目的角色

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 浏览目录树，然后选择要查看或编辑其角色的条目。选择“对象”菜单中的“设置角色”。

   此时显示“角色”对话框。

3. 选择“受管理的角色”选项卡，显示该条目所属的受管理角色。

4. 要添加新的受管理角色，请单击“添加”，然后从“角色选择器”窗口中选择可用的角色。单击“确定”。

   要删除某个受管理角色，请将其选定，然后单击“删除”。

   要编辑与条目相关联的受管理角色，请单击“编辑”。此时显示“编辑项目”对话框。对常规信息或成员进行更改，然后单击“确定”。

5. 选择“其它角色”选项卡，查看该条目所属的已过滤角色或嵌套角色。

6. 单击“编辑”可对与条目相关联的已过滤角色或嵌套角色进行更改。单击“确定”按钮，保存修改结果。

7. 修改完角色并保存好更改结果后，单击“确定”。

修改角色项

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 浏览导航树，查找现有角色的定义项。角色是创建该角色所在的条目的子项。双击角色。

   此时显示“编辑项目”对话框。

3. 单击左侧窗口中的“常规”以更改角色名和说明。

4. 单击左侧窗口中的“成员”以更改受管理角色和嵌套角色的成员，或者更改已过滤角色的过滤器。

5. 单击“确定”按钮，保存修改结果。

去活角色

通过去活成员所属的角色，可以临时禁用角色的成员。去活角色将去活角色所拥有的条目，而非角色本身。如果角色成员条目代表目录用户，则在去活用户条目时，他们将无法访问目录。

要临时禁用角色的成员：

1. 在 Directory Server Console 上，选择“目录”选项卡。

2. 浏览导航树，查找角色的定义项。角色是创建该角色所在的条目的子项。

3. 选择角色。选择“对象”菜单中的“去活”。

   也可以右键单击角色并选择菜单中的“去活”。

   角色被去活。

   要查看去活的条目，请从菜单中选择“视图”>“去活状态”。贯穿角色成员图标的红色斜杠表明这些成员已处于去活状态。

重新激活角色

1. 在 Directory Server Console 上，选择“目录”选项卡。

2. 浏览导航树，查找角色的定义项。角色是创建该角色所在的条目的子项。

3. 选择角色。选择“对象”菜单中的“激活”。

   也可右键单击角色，然后选择菜单中的“激活”。

   角色随即被重新激活。

   要查看被重新激活的条目，请选中“视图”菜单中的“去活状态”。正常显示的角色图标指示角色处于活动状态。

删除角色

删除角色将仅删除角色的定义项，而不会删除角色的成员。

要删除角色：

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 浏览导航树，查找角色的定义项。角色是创建该角色所在的条目的子项。

3. 右键单击角色，然后选择“删除”。

   此时显示的对话框将要求对删除予以确认。单击“是”。

4. 此时显示“已删除的项目”对话框，通知用户已成功删除角色。单击“确定”。

   
   

   ---

   注意	删除角色将仅删除角色条目，而不会为每个角色成员删除 nsRoleDN 属性。要删除该属性，请启用参照完整性插件并将其配置为管理 nsRoleDN 属性。有关详细信息，请参阅“保持参照完整性”。

   ---

   
   

使用命令行管理角色

在目录管理员可以通过命令行实用程序访问的条目中定义角色。创建角色后，按如下所示分配成员：

• 对于受管理角色的成员，其条目中有 nsRoleDN 属性。

• 已过滤角色的成员是与 nsRoleFilter 属性中所指定的过滤器相匹配的条目。

• 嵌套角色的成员是嵌套角色定义项的 nsRoleDN 属性中所指定的角色成员。

所有角色定义继承 LDAPsubentry 和 nsRoleDefinition 对象类。下表列出了针对每种角色类型的附加对象类和关联属性。

角色类型	对象类	属性
受管理的角色	nsSimpleRoleDefinition nsManagedRoleDefinition	Description（可选）
已过滤的角色	nsComplexRoleDefinition nsFilteredRoleDefinition	nsRoleFilter Description（可选）
嵌套角色	nsComplexRoleDefinition nsNestedRoleDefinition	nsRoleDN Description（可选）

---

注意	有些情况下需要用 ACI 来保护 nsRoleDN 属性的值，因为该属性是可写的。有关安全性和角色的信息，请参阅“安全使用角色”。

---

受管理的角色定义示例

要创建将分配给所有营销人员的角色，请运行以下 ldapmodify 命令：

ldapmodify -a -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=Marketing,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsSimpleRoleDefinition
objectclass: nsManagedRoleDefinition
cn: Marketing
description: managed role for marketing staff

注意：nsManagedRoleDefinition 对象类继承 LDAPsubentry、nsRoleDefinition 和 nsSimpleRoleDefinition 对象类。

要将该角色分配给营销人员 Bob，请用以下 ldapmodify 命令更新其条目：

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

条目中的 nsRoleDN 属性指示该条目是某个受管理角色的成员，该角色由其角色定义的 DN（cn=Marketing,ou=people,dc=siroe,dc=com）标识。

已过滤的角色定义示例

要为销售经理设置已过滤的角色，请运行以下 ldapmodify 命令：

ldapmodify -a -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=SalesManagerFilter,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: SalesManagerFilter
nsRoleFilter: o=sales managers
Description: filtered role for sales managers

注意：nsFilteredRoleDefinition 对象类继承 LDAPsubentry、nsRoleDefinition 和 nsComplexRoleDefinition 对象类。nsRoleFilter 属性指定在同一子树中其 o（organization，组织）属性的属性值为 sales managers 的所有条目都将是该角色的成员。

嵌套角色定义示例

如果要创建一个角色，该角色同时包含上面示例中创建的角色中的营销人员和销售经理，请使用以下 ldapmodify 命令：

ldapmodify -a -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=MarketingSales,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsNestedRoleDefinition
cn: MarketingSales
nsRoleDN: cn=SalesManagerFilter,ou=people,dc=siroe,dc=com
nsRoleDN: cn=Marketing,ou=people,dc=siroe,dc=com

注意：nsNestedRoleDefinition 对象类继承 LDAPsubentry、nsRoleDefinition 和 nsComplexRoleDefinition 对象类。 nsRoleDN 属性中包含受管理角色 marketing 和已过滤角色 sales managers 的 DN。

上例中的两个用户（Bob 和 Pat）将成为此新嵌套角色的成员。

安全使用角色

并非每个角色都适于在安全环境中使用。创建新角色时，不妨考虑如何简便地将角色分配给条目或从条目中删除角色。有时用户会倾向于能简便地向角色中添加自身或从角色中删除自身。例如，如果有一个名为“山地自行车”的兴趣小组角色，您可能希望感兴趣的用户能方便地将自己添加到其中，或者从角色中删除自身。

但在安全环境下，这样开放的角色并不适用。例如，请考虑帐户去活角色。默认情况下，帐户去活角色中包含为其后缀定义的 ACI（有关帐户去活的详细信息，请参阅“去活用户和角色”）。创建角色时，服务器管理员将决定用户是否能将自身分配给角色，或者从角色中删除自身。

例如，用户 A 拥有受管理角色 MR。MR 角色已通过命令行的帐户去活功能予以锁定。这就意味着用户 A 无法绑定到服务器，因为该用户的 nsAccountLock 属性将被计算为“真”。但是，假设该用户已经绑定且已通过 MR 角色予以锁定。如果没有相应的 ACI 进行阻止，该用户即可删除自己条目中的 nsRoleDN 属性并将自己解锁。

为防止用户删除 nsRoleDN 属性，根据所用角色的类型，请使用下列 ACI。

受管理的角色。对于作为受管理角色成员的条目，使用下列 ACI 可以防止用户通过删除相应的 nsRoleDN 而解锁自身：

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

已过滤的角色。应对作为过滤器一部分的属性进行保护，从而确保用户无法通过修改属性而丢弃已过滤的角色。用户不得添加、删除和修改已过滤角色所用的属性。如果过滤器属性的值为计算值，则应采取一定的方式对能修改过滤器属性值的所有属性加以保护。

嵌套角色。嵌套角色中包括已过滤的角色和受管理的角色，因此对构成嵌套角色的各个角色都应考虑上述几点。

定义服务类 (CoS)

---

服务类 (COS) 机制使您可以创建不存储在条目中的虚拟属性。相反，Cos 机制在条目被发送到客户机应用程序时生成虚拟属性。CoS 可以简化条目的管理，同时减少对存储空间的要求。

与组和角色一样，CoS 依赖于目录中的帮助程序条目，并可以通过控制台或通过命令行进行配置。以下部分将介绍 CoS，并提供通过上述两种途径来管理 CoS 的操作步骤：

• “关于 CoS”

• “CoS 限制”

• “使用控制台管理 CoS”

• “从命令行管理 CoS”

• “创建基于角色的属性”

• “保护 CoS 的安全”

关于 CoS

CoS 为其所有目标项（即 CoS 范围内的任何条目）定义虚拟属性及其属性值。每个 CoS 都由目录中的下列条目组成：

• CoS 定义项 — 标识所用的 CoS 类型和将要生成的 CoS 属性的名称。与角色定义项类似，它也继承 LDAPsubentry 对象类。CoS 的范围包括 CoS 定义项父项下面的整个子树。同一 CoS 属性存在多个定义，因此该属性为多值属性。

• 模板项 — 包含一个或多个虚拟属性的值。CoS 范围内的所有条目都将使用此处定义的值。可以有多个模板项，在这种情况下，生成的属性可以是多值属性。

CoS 有三种类型，每种类型分别对应于 CoS 定义项和模板项的不同交互作用：

• 指针 CoS — CoS 定义项使用模板 DN 直接标识模板项。对于 CoS 属性而言，所有目标项的属性值都与模板中给定的值相同。

• 间接 CoS — CoS 定义项标识称为间接说明符的属性，该属性在目标项中的值将决定用于该条目的模板。目标项中的属性必须包含 DN。利用间接 CoS，每个目标项可以使用不同的模板，因此有不同的 CoS 属性值。

• 典型 CoS — CoS 定义项标识模板的基本 DN 和作为目标项属性名称的说明符。包含 CoS 值的模板是由目标项中说明符属性的 RDN（相对域名）值和模板的基本 DN 的共同确定的。

  
  

  ---

  注意	对于 LDAP 搜索请求而言，如果其中所含的过滤器引用了 CoS 虚拟属性，则服务器不支持该搜索请求。LDAP 搜索过滤器只支持存储在条目中的实际属性，而不包含 CoS 或 nsRole 属性。决定利用 CoS 定义项生成哪些属性时，请务必小心。 要查找基于虚拟属性值的条目，目录客户机必须检索条目的超集（例如整个分支），然后筛选出感兴趣的条目。

  ---

  
  

以下部分将详细介绍 CoS 定义项和模板项，并给出每种 CoS 类型的示例。

CoS 定义项和模板项

CoS 定义项是 cosSuperDefinition 对象类的一个实例。CoS 定义项也继承下列其中一个对象类，以指定 CoS 类型：

• cosPointerDefinition

• cosIndirectDefinition

• cosClassicDefinition

CoS 定义项包含每种 CoS 类型的特定属性，用于根据需要命名目标项中的虚拟 CoS 属性、模板 DN 和说明符属性。默认情况下，CoS 机制不会覆盖与 CoS 属性同名的现有属性的值。但是，可以使用 CoS 定义项的语法来控制上述行为。

CoS 模板项是 cosTemplate 对象类的一个实例。COS 模板项中包含由 CoS 机制所所生成的一个或多个属性值。给定 CoS 的模板项存储在目录树中与 CoS 定义同级的位置上。

如有可能，定义、模板和模板项应位于同一位置以方便管理。并且，应使用暗示它们所提供的功能的名称来对它们进行命名。例如，定义项 DN "cn=classicCosGenerateEmployeeType,ou=People,dc=siroe,dc=com" 比 "cn=ClassicCos1,ou=People,dc=siroe,dc=com" 的说明性更强。

有关与每种 CoS 相关联的对象类和属性的详细信息，请参阅“从命令行管理 CoS”。

指针 CoS 示例

下例显示一个为存储在 dc=siroe,dc=com 下的所有条目定义共用邮政编码的 CoS。该示例中的三个条目如下图所示：

图 5-1    指针 CoS 定义和模板示例

本例中，模板项由 CoS 定义项中的 DN，cn=siroeUS,cn=data 标识。每次在位于 dc=siroe,dc=com 下的条目上查询 postalCode 属性时，iPlanet Directory Server 都会返回模板项 cn=siroeUS,cn=data 中可用的值。因此，邮政编码将与条目 uid=wholiday,ou=people,dc=siroe,dc=com 一起出现，但不存储在该条目中。当 CoS 为数千或数百万个条目生成多个共享属性时，该机制可以节省大量的存储空间。

间接 CoS 示例

该示例是一个使用目标项 manager 属性来标识模板项的间接 CoS。利用此方法，CoS 机制可以为某个部门的所有员工生成与他们的经理相同的部门号，并且确保不断对其更新。该示例中的三个条目如下图所示：

图 5-2    间接 CoS 定义和模板示例

间接 CoS 定义项命名说明符属性，在本例中，即为 manager 属性。William Holiday 的条目是此 CoS 的其中一个目标项，并且他的 manager 属性包含 cn=Carla Fuentes,ou=people,dc=siroe,dc=com 的 DN。因此，Carla Fuentes 的条目是模板项，该模板项反过来提供值 318842 作为 departmentNumber 属性的属性值。

通过间接说明符，间接 CoS 可使用目录中的任意条目作为其模板。出于安全和性能的原因，应小心使用这种类型的 CoS。 在许多情况下，利用典型 CoS 或使用不太灵活的指针 CoS 机制限制目标项的位置，也可以取得相同的结果。

典型 CoS 示例

典型 CoS 机制根据定义项中给定的基本 DN 以及目标项中的说明符确定模板 DN。说明符属性的属性值将当作模板 DN 中的 cn 值。因此，典型 CoS 的模板 DN 必须具有以下结构：

cn=specifierValue,baseDN

下图中的示例显示一个生成邮政编码属性值的典型 CoS 定义：

图 5-3    典型 CoS 定义和模板示例

本例中，Cos 定义项的 cosSpecifier 属性指定了 employeeType 属性。该属性与模板 DN 一起，将模板项标识为 cn=sales,cn=siroeUS,cn=data。模板项随即将 postalCode 属性的值提供给目标项。

CoS 限制

CoS 功能是一个复杂的机制，它在性能和安全方面受以下条件的约束。

受限制的子树。不可以在 cn=config 或 cn=schema 子树上创建 CoS 定义。因此，这些条目不可以包含虚拟属性。

受限制的属性类型。下列属性类型不应通过 CoS 机制生成，因为它们的行为与同名实际属性的行为不相同：

• userPassword — CoS 生成的口令值不可用于绑定到目录服务器。

• aci — 目录服务器将不会基于由 CoS 定义的虚拟 ACI 值的内容而应用任何访问控制。

• objectclass — 目录服务器将不会基于由 CoS 定义的虚拟对象类的值而执行模式检查。

• nsRoleDN — CoS 生成的 nsRoleDN 值将不会被服务器用来生成角色。

所有模板必须是本地模板 — 模板项 DN，无论是在 CoS 定义中还是在目标项的说明符中，都必须指向目录服务器中的本地条目。它们所包含的模板和值无法通过目录链接或引荐进行检索。

CoS 虚拟值不能和实际值组合。CoS 属性值永远都不能和条目中的实际值及模板中的虚拟值进行组合。当 CoS 覆盖实际属性值时，它将用模板中的虚拟值替换所有实际值（请参阅“覆盖实际属性值”）。但是，CoS 机制可以组合几个 CoS 定义项的虚拟值，有关信息见“多值的 CoS 属性”。

已过滤的角色不可使用 CoS 的生成属性。已过滤的角色的过滤器字符串不可基于 CoS 虚拟属性的值。但是，Cos 定义中的说明符属性可以引用由角色定义生成的 nsRole 属性（请参阅“创建基于角色的属性”）。

访问控制指令 (ACI)。对于由 CoS 生成的属性，服务器的访问控制方式与常规存储属性的完全相同。但是，如果访问控制规则与由 CoS 生成的属性值有关，则访问控制规则受“CoS 限制”中所述的条件的约束。

CoS 高速缓存等待时间。CoS 高速缓存是一个内部的 Directory Server 结构，它将所有 CoS 数据保存在内存中以提高性能。该高速缓存已被优化，以便检索用于计算虚拟属性的 CoS 数据，甚至是在 CoS 定义项和模板项被更新时。因此，一旦添加或修改定义项和模板项，在它们生效前可能会有少许的延迟。该延迟取决于 CoS 定义的数量和复杂程度以及当前的服务器负载，但通常为几秒钟。

使用控制台管理 CoS

本节介绍如何通过 iPlanet Directory Server Console 创建和编辑 CoS 定义。其中包含以下部分：

• “创建新 CoS”

• “编辑现有 CoS”

• “删除 CoS”

创建新 CoS

在指针 CoS 和典型 CoS 情况下，必须在创建定义项之前先创建模板项：

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 浏览目录树，然后选择要在其下存储模板项的父项。

3. 从“对象”菜单或单击右键出现的上下文关联菜单中，选择“新建”>“其他”，然后从“新对象”对话框中的列表中选择 costemplate。

   “属性编辑器”对话框打开，并显示新模板中某些属性的默认值。

4. 按照下列方式编辑新模板对象：
   1. 将 LDAPsubentry 和 extensibleobject 值添加到 objectclass 属性中。

   2. 添加 cn 属性并赋予其一个用于标识模板的值，例如 cosTemplateForHeadquartersFax。

   3. 将命名属性更改为新的 cn 属性。

      您可以添加任何其它属性并将其用作命名属性，但使用 cn 是惯例。

   4. 通过将 cosPriority 属性设置为一个整数值对其进行修改，或者，如果不需要该优先属性，可将其删除。

   5. 添加希望在目标项上由 CoS 机制生成的属性及其属性值。

5. 在“属性编辑器”对话框中，单击“确定”以创建该模板项。

6. 如果要定义该模板的指针 CoS，则在目录树中选择这个新的模板项，然后从菜单中选择“编辑”>“复制 DN”。

对于所有类型的 CoS 而言，创建定义项的步骤都是相同的：

1. 浏览目录树，然后选择要使新服务类在其下生效的父项。

2. 从“对象”菜单或单击右键出现的上下文关联菜单中，选择“新建”>“服务类”。

   显示“创建新服务类”对话框。

3. 选择左侧窗口中的“常规”。在右侧窗口的“类名”字段中，输入新服务类的名称。该名称将出现在 CoS 定义项的 cn 命名属性中。在“说明”字段中输入类的说明。

4. 单击左侧窗口中的“属性”。右侧窗口将显示由 CoS 机制在目标项上生成的属性列表。

   单击“添加”可浏览可用属性列表并将属性添加到列表中。

5. 将属性添加到列表后，“服务类行为”栏中将显示一个下拉列表。单击以下单元格将选择相应的覆盖行为：
   • 不覆盖目标项属性 — 只有在没有相应的属性值存储于目标项的同一属性中时才会生成 CoS 属性值。

   • 覆盖目标项属性 — 由 CoS 生成的属性值将覆盖目标项中该属性的任何值。

   • 覆盖目标项属性并且是可操作的 — 该属性将覆盖任何目标值，并且是可操作属性。这样，除非有明确请求，否则该属性对于客户机应用程序而言不可见。

     
     

     ---

     注意	只有模式中也将属性定义为可操作的情况下，才能将该属性设置为可操作。

     ---

     
     

6. 单击左侧窗口中的“模板”。在右侧窗口中，选择模板项的标识方式，然后填写相应的字段。这将确定要定义的 CoS 类型。
   • 按照其 DN — 该选项将定义指针 CoS：在“模板 DN”字段中输入一个模板项的 DN。单击“浏览”从目录中选择模板 DN，或者按住 Ctrl-V 以粘贴在创建模板项后复制的模板 DN。

   • 使用其中一个目标项的属性值 - 该选项将定义间接 CoS：在“属性名称”字段中输入说明符属性的名称。请务必选择包含 DN 值的属性。单击“更改”，从列表中选择属性。

   • 使用一个 DN 以及其中一个目标项的属性值 - 该选项将定义一个典型 CoS：输入模板的基本 DN 和属性名称。单击“浏览”选择潜在目标项的父项，然后单击“更改”从列表中选择属性。

7. 单击“确定”以创建 CoS 定义项。

编辑现有 CoS

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 浏览目录树然后选择包含 CoS 定义的父项。CoS 条目作为该父项的子项出现。

3. 双击 CoS。

   此时显示“编辑项目”对话框。

4. 单击左侧窗口中的“常规”以更改 CoS 名称和说明。

5. 在左侧窗口中单击“属性”以添加或删除由 CoS 机制生成的虚拟属性。

6. 在左侧窗口中单击“模板”，重新定义模板说明符属性的名称或模板项 DN。该对话框也可用于重新定义 CoS 定义的类型。

7. 单击“确定”按钮，保存修改结果。

删除 CoS

1. 在 iPlanet Directory Server Console 中，选择“目录”选项卡。

2. 浏览目录树然后选择包含 CoS 定义的父项。CoS 条目作为该父项的子项出现。

3. 右键单击 CoS，然后选择“删除”。此时显示的对话框将要求对删除予以确认。单击“是”。

4. 此时显示“已删除的项目”对话框，通知用户已成功删除 CoS。单击“确定”。

从命令行管理 CoS

由于所有配置信息和模板数据均作为目录项进行存储，因此可以使用标准 LDAP 工具进行 CoS 的配置和管理。本部分包含下列主题：

• “从命令行创建 CoS 定义项”

• “从命令行创建 CoS 模板项”

• “指针 CoS 的示例”

• “间接 CoS 的示例”

• “典型 CoS 的示例”

从命令行创建 CoS 定义项

所有 CoS 定义项都继承 LDAPsubentry 和 cosSuperDefinition 对象类。此外，每种 CoS 都继承特定的对象类并包含相应的属性。下表列出了与每种 CoS 定义项相关联的对象类和属性：

表 5-1    CoS 定义项

CoS 类型	CoS 定义项
指针 CoS	objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDN: DN_string cosAttribute: list_of_attributes qualifier
间接 CoS	objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: attribute_name cosAttribute: list_of_attributes qualifier
典型 CoS	objectclass: top bbjectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: DN_string cosSpecifier: attribute_name cosAttribute: list_of_attributes qualifier

CoS 定义项中可以使用下列属性（有关这些属性的详细信息，请参阅 iPlanet Directory Server 配置、命令和文件参考指南。）：

表 5-2    CoS 定义项属性

属性	在 CoS 定义项内的用途
cosAttribute:  attribute_name override merge	定义要为其生成值的虚拟属性的名称。该属性为多值属性，每个值为将从模板生成其值的属性指定名称。限定符指定在特殊情况下计算 CoS 属性值的方式。
cosIndirectSpecifier:  attribute_name	定义目标项中其值被间接 CoS 用来标识模板项的属性的名称。已命名的属性被称为说明符，它在每个目标项中必须包含一个完整的 DN 字符串。该属性为单值属性，但说明符属性可以是多值属性以指定多个模板。
cosSpecifier:  attribute_name	定义目标项中其值被典型 CoS 用来标识模板项的属性的名称。已命名的属性被称为说明符，它必须包含一个可在目标项的 RDN 中找到的字符串。该属性为单值属性，但说明符属性可以是多值属性以指定多个模板。
cosTemplateDn:  DN_string	为指针 CoS 定义提供模板项的完整 DN，或为典型 CoS 提供模板项的基本 DN。

cosAttribute 属性允许在 CoS 属性的名称后使用两个限定符。override 限定符可以是下列值之一：

• default（或没有限定符） — 指示在实际属性与虚拟属性同属一个类型时，服务器将不覆盖存储在条目中的实际属性值。

• override — 指示即使该条目存储有属性值，服务器仍会一直返回由 CoS 生成的值。

• operational — 指示只有在搜索中明确请求某个属性时，才会返回该属性。要返回可操作属性时，无须通过模式检查。它还具有与 override 限定符相同的特性。

  只有模式中也将属性定义为可操作的情况下，才能将该属性设置为可操作。例如，如果 CoS 为 description 属性生成了值，则不可以使用 operational 限定符，因为该属性在模式中未被标记为可操作。

merge 限定符可能为空，也可能是下列值之一：

• merge-schemes — 允许通过多个模板或多个 CoS 定义使虚拟 CoS 属性成为多值属性。有关详细信息，请参阅“多值的 CoS 属性”。

覆盖实际属性值
可以创建包含 override 限定符的指针 CoS 定义项，如下所示：

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

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

---

注意	如果用 operational 或 override 限定符定义 CoS 属性，则无法手动在 CoS 范围内的任何条目中更新该属性，因为它作为常规属性出现。

---

多值的 CoS 属性
指定 merge-schemes 限定符时，生成的 CoS 属性可以是多值属性。使 CoS 属性成为多值属性有两种方法：

• 在间接或典型 CoS 中，目标项中的说明符属性可以是多值的。在这种情况下，每个值确定一个模板，并且每个模板的值都是生成的值的一部分。

• 在其 cosAttribute 属性中包含相同属性名的任何类型 CoS 都可以有多个 CoS 定义项。在这种情况下，如果所有定义都包含 merge-schemes 限定符，则生成的属性将包含用每个定义计算得到的所有值。

这两种情况可能会一起出现，从而需要定义更多的值。然而，在所有情况下，重复值在生成的属性中将只返回一次。

如果没有 merge-schemes 限定符，则模板项的 cosPriority 属性将被用于在所有模板间为生成属性确定单个值，有关说明见下一部分。

merge-schemes 限定符决不将目标中定义的“实际”值和模板生成的值合并。merge 限定符与 override 限定符彼此独立，因此各种配对都有可能，并且每种配对所暗示的行为都是可取的。另外，在属性名称后可以任意顺序指定限定符。

---

注意	当同一属性有多个 CoS 定义时，它们必须有相同的 override 和 merge 限定符。如果 CoS 定义中出现不同的限定符配对，则在所有定义之间随意选择其中一种组合。

---

Cos 属性优先级
如果有多个 CoS 定义或多值说明符但没有 merge-schemes 限定符，则 Directory Server 使用优先的属性选择单个模板，用于定义虚拟属性的单个值。

cosPriority 属性表示特定模板在所有备选模板中的全局优先性。优先级 0 代表最高的优先级。不含 cosPriority 属性的模板被视为优先级最低。当两个或更多模板都提供属性值，但它们有相同的优先级（或没有优先级设置），则值的选择具有任意性。

使用 merge-schemes 限定符时，将不考虑模板优先级。合并情况下，所有相关模板共同定义属性值，而不管它们的定义优先级。cosPriority 属性在 CoS 模板项中定义，有关说明见以下部分。

从命令行创建 CoS 模板项

使用指针 CoS 或典型 CoS 时，模板项将继承 LDAPsubentry 对象类，并且也是 cosTemplate 对象类的实例。模板项必须是为 CoS 定义专门创建的。将 CoS 模板项作为 LDAPsubentry 对象类的实例，即可进行正常搜索而避免受到配置项的干扰。

间接 CoS 机制指向目录中任意的现有模板项。它无需事先标识，也不需要提供给 LDAPsubentry 对象类。只有在评估 CoS 以生成虚拟属性及其属性值时才访问间接 CoS 模板。

在任何情况下，CoS 模板项都必须包含由 CoS 在目标项中生成的属性和属性值。属性名在 CoS 定义项的 cosAttribute 属性中指定。

下例显示一个生成 postalCode 属性的指针 CoS 的最高优先级模板项：

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

下列部分提供模板项的示例及每种 CoS 定义项的示例。

指针 CoS 的示例

要创建与 dc=siroe,dc=com 目录树中的所有条目共用同一邮政编码的指针 CoS，请运行以下 ldapmodify 命令：

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

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

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

CoS 模板项 (cn=siroeUS,dn=cata,dc=siroe,dc=com) 将其 postalCode 属性中存储的值提供给 dc=siroe,dc=com 后缀下的所有条目。

间接 CoS 的示例

该间接 CoS 使用目标项的 team 属性来标识 CoS 模板项。要将新的间接 CoS 定义项添加到 dc=siroe,dc=com 后缀，请运行以下 ldapmodify 命令：

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

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

然后，按如下所示为经理 Carla Fuentes 创建模板项：

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

按如下所示为经理 Sue Jacobs 创建另一个模板项：

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

对于包含 manager 属性的条目而言，定义项似乎位于目标项中（dc=siroe,dc=com 下的条目），因为该属性是在定义项的 cosIndirectSpecifier 属性中指定的。模板项的 manager 属性可以指向下列两个模板之一：cn=Carla Fuentes,cn=data,dc=siroe,dc=com 和 cn=Sue Jacobs,cn=data,dc=siroe,dc=com。根据经理的不同，部门号也将有所区别。

典型 CoS 的示例

在下例中，典型 CoS 利用模板 DN 及 cosSpecifier 属性中指定的属性自动生成邮政编码。要创建典型 CoS 定义项，请运行以下 ldapmodify 命令：

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

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

然后，按如下所示为销售部和营销部创建模板项：

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

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

典型 CoS 定义项将应用于 dc=siroe,dc=com 后缀下的所有条目。根据条目中找到的 employeeType 属性与 cosTemplate DN 的组合，它将到达两个模板之一：一个是 sales 模板，为销售部的员工提供特定的邮政编码；另一个是 marketing 模板，为营销部的员工提供特定的邮政编码。

创建基于角色的属性

您可以创建典型 CoS 模式，从而基于条目所拥有的角色为该条目生成属性值。例如，使用基于角色的属性可以逐条设置服务器的审核限制。

要创建基于角色的属性，请在典型 CoS 的 CoS 定义项中将 nsRole 属性用作 cosSpecifier。由于 nsRole 属性可以为多值属性，因此可以定义有多个可用模板项的 CoS 模式。为解决使用哪个模板项的不定性问题，可以在 COS 模板项中包含 cosPriority 属性。

例如，可以创建允许 manager 角色的成员超出标准邮箱限额的 CoS。manager 角色如下所示：

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

典型 CoS 定义项如下所示：

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

cosTemplateDn 属性所提供的值与 cosSpecifier 属性中指定的属性（例中就是目标项的 nsRole 属性）一起，可以标识该 COS 模板项。CoS 模板项为 mailboxquota 属性提供值。附加的限定符 override 告知 CoS 应覆盖目标项中任何现有的 mailboxquota 属性值。

按如下所示定义相应的 CoS 模板项：

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

该模板为 mailboxquota 属性提供属性值 1000000。

---

注意	角色条目和 CoS 定义项应位于目录树中的同一位置，这样在其范围内有相同的目标项。CoS 目标项也应位于同一位置，这样方便查找和维护。

---

保护 CoS 安全

读取操作的访问控制对条目的实际属性和虚拟属性都适用。由服务类 (CoS) 机制生成的虚拟属性的读取方式与常规属性相同，并且应给予相同的读取保护。

但是，为保护 CoS 值的安全，必须保护它所使用的所有信息源：定义项、模板项和目标项。对更新操作也有相同的要求：应控制对各个信息源的写入权限，以保护从这些信息源生成的值。

下列部分介绍在各种 CoS 条目中进行数据读写保护的一般原则。有关定义各个访问控制指令 (ACI) 的详细步骤，请参见第 6 章“管理访问控制”。

保护 CoS 定义项

虽然 CoS 定义项不包含生成属性的值，但它提供查找该值的信息。读取 CoS 定义项可以从中发现查找包含属性值的模板项的方法，而编写该定义项可以修改生成虚拟属性的方式。

因此，应在 CoS 定义项中定义读取和写入访问控制。

保护 CoS 模板项

CoS 模板项包含 CoS 生成属性的属性值。因此，至少应保护对模板中 CoS 属性的读取和更新。

在指针 CoS 情况下，应有一个模板项不允许重命名。在大多数情况下，最简单的方法是保护整个模板项。

在典型 CoS 中，所有模板项都有一个在定义项中指定的公共父项。如果只有模板存储在父项中，则对父项的访问控制将可以保护模板。否则，如果需要访问父项下的其它条目，则各模板项需要单独保护。

在间接 CoS 中，模板可以是目录中的任何条目，包括可能还需要访问的用户条目。根据需要，可以在整个目录范围内控制对 CoS 属性的访问，或者必须保证 CoS 属性在用作模板的各个条目中的安全。

保护 CoS 目标项

在 CoS 定义范围内的所有条目，除为其生成虚拟 CoS 属性外，还用于计算属性值。

当目标项中已经存在 CoS 属性时，默认情况下，CoS 机制将不覆盖该值。如果需要覆盖，则应定义 CoS 以覆盖目标项（参见“覆盖实际属性值”），或者应在所有潜在目标项中保护 CoS 属性。

间接 CoS 和典型 CoS 也都与目标项中的说明符属性相关。该属性提供要使用的模板项 DN 或 RDN。应在整个 CoS 范围内全局保护该属性，或者在需要的每个目标项中进行个别保护。

保护其它相关项

最后，可能需要用其它生成的 CoS 属性和角色来定义虚拟 CoS 属性。为确保对虚拟 CoS 属性的保护，需要理解并保护这些相关项。

例如，目标项中的 CoS 说明符属性可以是 nsRole，因此同时还需要保护角色定义。有关详细信息，请参见“安全使用角色”。

总之，计算虚拟属性值所涉及的任何属性或条目应具有读写访问控制。为此，应对复杂的相关项进行精心规划，或者进行简化以减少复杂性。保持与其它虚拟属性的最低限度的相关性还有利于提高目录性能和降低维护难度。