Delegated Administrator 控制台提供了一种新的管理员职责—服务提供商管理员 (Service Provider Administrator, SPA),以及可以在目录中创建的新组织类型。
本附录介绍了以下主题:
本附录介绍了服务提供商管理员职责以及新的组织类型,并说明了如何在 Delegated Administrator 中创建这些组织。
Delegated Administrator 控制台允许您将管理任务委托给一种新职责—服务提供商管理员 (Service Provider Administrator, SPA),SPA 可以创建和管理新的从属组织类型。
SPA 的权限范围介于顶级管理员 (Top-Level Administrator, TLA) 与组织管理员 (Organization Administrator, OA) 的权限范围之间。
具有了 SPA 权限,您就可以创建三层管理结构,如第 1 章,Delegated Administrator 概述中的三层结构所述。
这种二级委托可以使得对大型 LDAP 目录所支持的大型客户库的管理容易一些。例如,ISP 可以向数百或数千家小公司提供服务,每家小公司都需要具有各自的组织。每天都可能需要向目录中添加许多新组织。
如果您使用了两层结构,那么 TLA 必须创建所有这些新组织。现在,TLA 就可以将这些任务委托给 SPA。
SPA 可以为新客户创建从属组织并指派 OA 来管理这些组织中的用户。
图 A–1 显示了一个样例三层组织结构的逻辑视图。
图 A–1 中的示例显示了一个提供商组织。但实际上目录中可以包含多个提供商组织。
在此示例中,管理任务的委托方式如下:
SPA 有权管理 VIS 提供商组织及其包含的所有组织。SPA 职责被指派给 DEF 组织中的 user1。
名为 OA1 的组织管理员可管理共享组织 DEF。此 OA 职责被指派给 DEF 组织中的 user2。
OA2 可管理共享组织 HIJ。此 OA 职责被指派给 HIJ 组织中的 user4。
OA3 可管理完整组织 SESTA。此 OA 职责被指派给 SESTA 组织中的 user1。
SESTA 是一个完整的组织,具有其自己的唯一名称空间。SESTA(在 sesta.com 域中)中的 user1 具有唯一用户 ID。
有关提供商和从属组织的定义,请参见由服务提供商管理员管理的组织。
在 SPA 有权管理的提供商组织中创建、删除和修改共享组织和完整组织。
在图 A–1 显示的示例中,VIS 提供商组织的 SPA 可以
修改或删除 DEF、HIJ 和 SESTA 组织
在 VIS 提供商组织下创建其他组织。
在提供商组织下的任意组织中创建、删除和修改用户。
在提供商组织下的任意组织中创建、删除和修改组。
在提供商组织下的任意组织中创建、删除和修改日历资源。
将 OA 职责指派给用户。
例如,在图 A–1 显示的样例组织中,SPA 可以将 OA 职责指派给 SESTA 组织中的 user2。这样,user2 就可以管理 SESTA 组织中的用户。
SPA 还可以撤消用户的 OA 职责。
将 SPA 职责指派给提供商组织下的其他合法用户(以及撤消 SPA 职责)。
将服务包分配给各个组织。
有关服务包的信息,请参见第 1 章,Delegated Administrator 概述中的服务包。
SPA 可以将指定类型的服务包分配给一个组织并确定可以在该组织中使用的每种包的最大数量。
例如,SPA 可以分配以下服务包:
在 DEF 组织中:
1,000 个 gold 包 500 个 platinum 包 |
在 HIJ 组织中:
2,500 个 topaz 包 500 个 platinum 包 500 个 emerald 包 1,000 个 ruby 包 |
在 SESTA 组织中:
2,000 个 silver 包 1,500 个 gold 包 100 个 platinum 包 |
SPA 可以使用 Delegated Administrator 控制台来执行这些任务。在此版本中,Delegated Administrator 实用程序不包含执行这些任务的命令选项。
TLA 可以修改或删除任何现有的共享组织或完整组织,还可以管理这些组织中的用户。
TLA 可以撤消用户的 SPA 职责,但不能通过控制台指派 SPA 职责。有关此版本的 Delegated Administrator 中的约束列表,请参见此版本的注意事项。
有关由 TLA 执行的管理任务的完整说明,请参见第 1 章,Delegated Administrator 概述中的管理员职责与目录分层结构 。
要将 SPA 职责指派给某个组织中的用户,该组织必须是为 SPA 指定的并且从属于 SPA 将管理的提供商组织。
在图 A–1 显示的示例中,假设需要为名为 VIS 的提供商组织创建 SPA。可以将 SPA 职责指派给组织 DEF 中的 user1。
SPA 必须位于从属组织中,因为提供商组织节点不包含任何用户。
因此,必须至少在提供商组织下创建一个组织,SPA 才能管理该提供商组织。应指定此组织来包含被指派为 SPA 职责的用户。有关详细信息,请参见创建提供商组织和服务提供商管理员。
在此版本的 Delegated Administrator 中,无法使用 Delegated Administrator 控制台或实用程序来创建 SPA 或提供商组织。
要创建 SPA 或提供商组织,必须手动修改自定义服务提供商模板 da.provider.skeleton.ldif。
有关使用自定义服务提供商模板来执行这些任务的说明,请参见本附录后面的创建提供商组织和服务提供商管理员。
SPA 可以创建、修改和删除从属于该 SPA 的提供商组织的以下组织类型:
以下几节介绍了提供商组织、完整组织和共享组织。
提供商组织是 LDAP 目录中的一个节点,在逻辑上包含完整组织和共享组织。 提供商组织节点具有一些属性,这些属性使得 SPA 可以管理从属组织。
在 LDAP 目录中,提供商组织必须位于邮件域下。有关示例,请参见本附录后面的样例服务提供商组织数据。
提供商组织不能包含用户条目,而应在提供商组织下所创建的组织中置备用户。
提供商组织可存储有关在其下创建的组织的目录信息。 例如:
此提供商组织是否可以包含共享组织、完整组织或两者都包含
在此提供商组织下创建的共享组织可以使用的域名
可供在此提供商组织下创建的组织使用的服务等级包类型和数量
被指定为此提供商组织的 SPA 所在位置的组织
它从属于提供商组织并由 SPA 创建。
可以在完整组织中置备用户。
在图 A–1 显示的示例中,user2 属于 sesta.com 域,其邮件地址为 user2@sesta.com。
完整组织拥有其自己的域(其他组织不能共享该域),并且拥有自己的唯一名称空间。
在图 A–1 显示的示例中,完整组织 SESTA 具有域名 sesta.com。
它从属于提供商组织并由 SPA 创建。
可以在共享组织中置备用户。
在图 A–1 显示的示例中,user5 属于 siroe.com 域,其邮件地址为 user5@siroe.com。
它使用提供商组织所提供的列表中的一个或多个共享域名。
在图 A–1 显示的示例中,共享组织 DEF 使用域名 siroe.com。
其他共享组织可以共享此组织所使用的域名。
在图 A–1 显示的示例中,DEF 和 HIJ 组织都属于 siroe.com 域。
共享组织不具有唯一名称空间。
在此版本的 Delegated Administrator 中,必须使用 Delegated Administrator 所提供的自定义服务提供商模板 (da.provider.skeleton.ldif) 来创建您自己的提供商组织和 SPA。
运行 Delegated Administrator 配置程序后,还可以在目录中安装样例提供商组织(带有从属组织)和样例 SPA。可通过在配置程序中选择装入样例组织来执行此操作。
但样例组织模板 (da.sample.data.ldif) 只是一个示例,并不是用来创建您自己的提供商组织的模板。有关此示例的详细信息,请参见本附录后面的样例服务提供商组织数据。
创建了提供商组织和 SPA 之后,SPA 就可以登录到 Delegated Administrator 控制台,创建和管理从属组织,并将 SPA 职责指派给该 SPA 的组织中的其他用户。但是,这些 SPA 只能管理同一个提供商组织。
要创建另一个提供商组织和管理该组织的 SPA,应再次使用自定义服务提供商模板。
本节包含以下主题:
模板创建的条目显示了在目录中安装经过编辑的模板副本后所创建的组织示例。
创建提供商组织、从属组织和 SPA 所需的信息定义了在模板中创建提供商组织、从属共享组织和 SPA 所需的参数。
创建提供商组织和服务提供商管理员的步骤说明了如何编辑模板以及如何在目录中安装信息。
自定义服务提供商模板是模板列表。
在目录中安装经过编辑的自定义服务提供商模板副本后,就创建了以下条目:
提供商组织
指定来包含 SPA 用户的从属共享组织
从属组织中被指派为 SPA 职责的一个用户
可以在其下创建完整组织的占位符节点。 这些完整组织将由此提供商组织的 SPA 来管理。
图 A–2 显示了通过安装模板而创建的条目示例。它是各个组织的目录信息树 (Directory Information Tree, DIT) 视图。
图 A–2 只是一个示例。组织名称、SPA 用户名以及 DIT 结构应该特定于您自己的安装。
图 A–2 显示的示例中的节点如下:
o=usergroup—用户/组数据的根后缀。
o=siroe.com—提供商组织所使用的邮件域。
o=MyProviderOrg—提供商组织节点。
o=MySPAUserOrg—指定来包含提供商组织用户(包括被指派为 SPA 职责的用户)的从属共享组织。
ou=people—必需的标准 LDAP 组织单元,用于包含用户。
uid=user1—MySPAUserOrg 组织中被指派为 SPA 的用户的 ID。
o=MyProviderOrgDomainsRoot—占位符节点,用于包含从属于 MyProviderOrg provider 组织的完整组织。
要创建提供商组织、一个从属组织和 SPA,需要将自定义服务提供商模板中的参数替换为特定于您的安装的信息。
当您读取这些参数时,可以看到自定义服务提供商模板中显示的 da.provider.skeleton.ldif 列表。或者打开位于以下目录的实际 ldif 文件:
da_base/lib/config-templates
有关与这些参数相关联的属性的定义,请参见 Sun Java System Communications Services Schema Reference 中的第 5 章 "Communications Services Delegated Administrator Classes and Attributes (Schema 2)" 和第 3 章 "Messaging Server and Calendar Server Attributes" 。
要创建提供商组织和从属组织,请编辑以下参数:
ugldapbasedn
目录中的用户/组数据的根后缀。
示例:
o=usergroup
dc=red,dc=iplanet,dc=com
maildomain_dn
将在其下创建提供商组织的邮件域的完整 DN。
示例:
o=siroe.com, o=usergroup
o=sesta.com,o=SharedDomainsRoot,o=Business,dc=red, \ dc=iplanet,dc=com |
maildomain_dn_str
将所有逗号 (,) 均替换为下划线 (_) 的邮件域 DN。
例如,如果邮件域 DN 为
o=siroe.com,o=SharedDomainsRoot,o=Business,dc=red, \ dc=iplanet,dc=com |
则邮件域 DN 字符串将为
o=siroe.com_o=SharedDomainsRoot_o=Business_dc=red_ \ dc=iplanet_dc=com |
providerorg
提供商组织的名称。将为提供商组织所位于的目录节点给定此名称。
此参数在 da.provider.skeleton.ldif 模板中会多次用到。
示例:
sunProviderOrgDN: o=MyProviderOrg,o=siroe.com,o=usergroup
o=MyProviderOrg
sunBusinessOrgBase: o=MyProviderOrgdomainsroot, o=usergroup
servicepackage
服务包名称,服务包可以被指派给从属于提供商组织的各个组织中的用户。这是一个多值参数。
在 da.provider.skeleton.ldif 文件中的“提供商组织”部分,您将看到以下属性:
sunIncludeServices: <servicepackage>
针对要包括在提供商组织中的每个服务包,均应添加一个 sunIncludeServices 属性实例和一个 servicepackage 参数实例。只有在此列出的这些服务包才可以被指派给从属组织中的用户。
示例:
sunIncludeServices: gold sunIncludeServices: platinum sunIncludeServices: ruby sunIncludeServices: silver |
如果不使用 sunIncludeServices 属性(即,如果删除包含 servicepackage 参数的行),则可以指派目录中的所有服务包。
domain_name
可以指派给提供商组织中的从属组织的域名。这是一个多值参数。
在 da.provider.skeleton.ldif 文件中的“提供商组织”部分,您将看到以下属性:
sunAssignableDomains: <domain_name>
sunAssignableDomains 属性中的域名是邮件域组织的 sunPreferredDomain 和 associatedDomain 属性中的名称列表的子集(部分或全部)。(邮件域就是在其下创建了此提供商组织的组织。)
针对要包括在提供商组织中的每个域名,均应添加一个 sunAssignableDomains 属性实例和一个 domain_name 参数实例。只有在此列出的域名才可以被指派给从属组织。
示例:
sunAssignableDomains: siroe.com sunAssignableDomains: siroe.net sunAssignableDomains: varrius.com sunAssignableDomains: sesta.com sunAssignableDomains: sesta.net |
provider_sub_org
SPA 用户所位于的共享组织的名称。在目录中安装经过编辑的 ldif 信息后,就创建了此组织来作为共享组织,它从属于提供商组织。它被指定为包含 SPA 用户的组织。其他被指派为此提供商组织的 SPA 职责的用户都必须位于此从属共享组织。
在 da.provider.skeleton.ldif 文件中的“提供商组织”部分,您将看到以下属性:
sunProviderOrgDN: o=<provider_sub_org>,o=<providerorg>,<maildomain_dn> |
sunProviderOrgDN 属性标识了为提供商组织用户(尤其是 SPA 用户)指定的组织。
示例:
sunProviderOrgDN: o=MySPAUserOrg,o=MyProviderOrg,o=siroe.com,o=usergroup |
preferredmailhost
作为提供商组织从属组织(SPA 用户位于其中)的首选邮件主机的计算机名。必须使用全限定域名 (Fully Qualified Fomain Name, FQDN)。
在 da.provider.skeleton.ldif 文件中的 “共享从属组织”部分,您将看到以下属性:
preferredMailHost: <preferredmailhost>
示例:
preferredMailHost: mail.siroe.com
available_domain_name
可以指派给特定从属组织中的用户的域名。这是一个多值参数。
available_domain_name 的值是为 sunAssignableDomains: <domain_name> 属性和参数给定的值的相应部分。其中 domain_name 适用于整个提供商组织,available_domain_name 适用于单个从属组织。
在 da.provider.skeleton.ldif 文件中的“共享从属组织”部分,您将看到以下属性:
sunAvailableDomainNames: <available_domain_name>
针对您希望此从属组织从提供商组织的 sunAssignableDomains 属性中的域名列表中继承的每个域名,均应添加一个 sunAvailableDomains 属性实例和一个 available_domain_name 参数实例。只有在此列出的域名才可以被指派给此从属组织。
示例:
sunAvailableDomainNames: siroe.com sunAvailableDomainNames: siroe.net sunAvailableDomainNames: varrius.com |
available_services
可供特定从属组织使用的服务包。这是一个多值参数。
指派给从属组织的服务包是使用 sunIncludeServices 属性指派给整个提供商组织的服务包的子集。
在 da.provider.skeleton.ldif 文件中的“共享从属组织”部分,您将看到以下属性:
sunAvailableServices: <available_services>
available_services 参数的格式是
service package name: count |
其中 count 是一个整数。如果未指定数量,则默认值为无限数。
针对您希望此从属组织从提供商组织的 sunIncludeServices 属性中可用的服务包中继承的每个服务包,均应添加一个 sunAvailableServices 属性实例和一个 available_services 参数实例。
示例:
sunAvailableServices: gold:1500 sunAvailableServices: platinum:2000 sunAvailableServices: silver:5000 |
要创建 SPA,请编辑以下参数:
spa_uid
SPA 用户的用户 ID。
示例:
uid: user1
spa_password
SPA 用户的密码。
示例:
userPassword: x12P3&qrS
spa_firstname
SPA 用户的名字。
示例:
givenname: John
spa_lastname
SPA 用户的姓。
示例:
sn: Smith
spa_servicepackage
指派给 SPA 用户的服务包。有关服务包的信息,请参见第 1 章,Delegated Administrator 概述中的服务包。
示例:
inetCos: platinum
spa_mailaddress
SPA 用户的邮件地址。邮件地址的域部分必须是替换 available_domain_name 参数的域值中的一个。即,它必须是可以在 SPA 用户所位于的从属组织中使用的域。有关详细信息,请参见定义提供商组织和从属组织的参数。
示例:
mail: user1@siroe.com
有关如何编辑自定义服务提供商模板以及如何在目录中安装信息的说明,请参见创建提供商组织和服务提供商管理员的步骤。
使用 ldif 文件 da.provider.skeleton.ldif 来执行以下过程。
在目录中创建一个邮件域。
如果您尚未创建邮件域,请在目录中创建一个。提供商组织及其从属共享组织将使用此邮件域。
复制并重命名 da.provider.skeleton.ldif 文件。
当您安装 Delegated Administrator 后,da.provider.skeleton.ldif 文件会安装在以下目录中:
da_base /lib/config-templates
编辑 da.provider.skeleton.ldif 文件副本中的以下参数。将这些参数替换为针对您的安装的相应值。
有关这些参数的定义,请参见创建提供商组织、从属组织和 SPA 所需的信息。
某些参数在 ldif 文件中多次用到。您必须搜索并替换每个参数的所有实例。
少数参数代表多值属性的值。可以复制并编辑这些参数及其相关联的属性名称,以便允许这些属性在 ldif 文件中出现多次。以下标出了多值参数。
<ugldapbasedn>
<maildomain_dn>
<maildomain_dn_str>
<providerorg>
<servicepackage>(多值)
<domain_name>(多值)
<provider_sub_org>
<preferredmailhost>
<available_domain_name>(多值)
<available_services>(多值)
<spa_uid>
<spa_password>
<spa_firstname>
<spa_lastname>
<spa_servicepackage>
<spa_mailaddress>
有关与这些参数相关联的属性的定义,请参见 Sun Java System Communications Services Schema Reference 中的第 5 章 "Communications Services Delegated Administrator Classes and Attributes (Schema 2)" 和第 3 章 "Messaging Server and Calendar Server Attributes" 。
使用 LDAP 目录工具 ldapmodify 在目录中安装提供商组织和 SPA。
例如,可以运行以下命令:
ldapmodify -D <directory manager> -w <password> \ -f <da.provider.finished.ldif> |
其中
<directory manager> 是 Directory Server 管理员的用户名。
<password> 是 Directory Server 管理员的密码。
<da.provider.finished.ldif> 是要在目录中作为新提供商组织和 SPA 安装的、经过编辑的 ldif 文件的名称。
该模板 (da.provider.skeleton.ldif) 包含一些参数,您必须修改这些参数才能创建新的提供商组织和 SPA。
以下列表显示了 ldif 文件中具有参数的部分。此列表没有包含整个文件。此处不包含支持 Access Manager 所需的条目和 ACI。
您只能在 ldif 文件中修改这些参数。请勿修改文件中与 Access Manager 相关的部分。
# # The following parameterized values must be replaced. # # <ugldapbasedn> :: Root suffix for user/group data # <maildomain_dn> :: Complete dn of the mail domain underneath # which the provider organization will be # created. # <maildomain_dn_str> :: The maildomain dn with all ',' replaced # by '_'. E.g. # dn --\> o=siroe.com,o=SharedDomainsRoot, # o=Business,dc=red,dc=iplanet,dc=com # dn_str --> o=siroe.com_o=SharedDomainsRoot_ # o=Business_dc=red_dc=iplanet_dc=com # <providerorg> : Organization value for provider node. # <servicepackage> :: One for each service package to include. # All service packages in the system # may be assigned by leaving this value empty. # <domain_name> :: One for each DNS name which may be assigned # to a subordinate organization. # These names form a proper subset (some or # all) of the names listed in the <maildomain> # organization's sunpreferreddomain # and associateddomain attributes. # <provider_sub_org> :: Organization value for the shared subordinate # organization in which the Provider # Administrator resides. # <preferredmailhost> :: Name of the preferred mail host for the # provider's subordinate organization. # <available_domain_name> :: one for each DNS name that an organization # allows an organization admin to use when # creating a user's mail address. This is # a proper subset of the values given for # <domain_name> (sunAssignableDomains attribute). # <available_services> :: One for each service packags available to an # organization (sunAvailableServices attribute). # These service packages form a proper subset # of the ones assigned to a provider organization # - <servicepackage> (sunIncludeServices # attribute). Form is # <service package name>:<count> # where count is an integer. If count is absent # then default is unlimited. # <spa_uid> :: The uid for the service provider administrator. # <spa_password> :: The password for the service provider # administrator. # <spa_firstname> :: First name of the service provider # administrator. # <spa_lastname> :: Last name of the service provider # administrator. # <spa_servicepackage> :: Service package assigned to the service # provider administrator. # <spa_mailaddress> :: The spa's mail address. The domain part of the # mail address must be one of the values used for # <available_domain_name>. # # # Provider Organization # dn: o=<providerorg>,<maildomain_dn> changetype: add o: <providerorg> objectClass: top objectClass: sunismanagedorganization objectClass: sunmanagedorganization objectClass: organization objectClass: sunManagedProvider sunAllowBusinessOrgType: full sunAllowBusinessOrgType: shared sunBusinessOrgBase: o=<providerorg>domainsroot,<ugldapbasedn> sunIncludeServices: <servicepackage> sunAssignableDomains: <domain_name> sunAllowMultipleDomains: true sunAllowOutsideAdmins: false sunProviderOrgDN: o=<provider_sub_org>,o=<providerorg>,<maildomain_dn> # . # . # [Entries and ACIs required by Access Manager] # . # . # # Full Organizations node # dn: o=<providerorg>DomainsRoot,<ugldapbasedn> changetype: add o: <providerorg>DomainsRoot objectClass: top objectClass: organization objectClass: sunmanagedorganization # . # . # [Entries and ACIs required by Access Manager] # . # . # # Provider Admin Role shared organizations # dn: cn=Provider Admin Role,o=<providerorg>,<maildomain_dn> changetype: add cn: Provider Admin Role objectClass: ldapsubentry objectClass: nssimpleroledefinition objectClass: nsroledefinition objectClass: nsmanagedroledefinition objectClass: iplanet-am-managed-role objectClass: top iplanet-am-role-description: Provider Admin # # Provider Admin Role full organizations # dn: cn=Provider Admin Role,o=<providerorg>DomainsRoot,<ugldapbasedn> changetype: add cn: Provider Admin Role objectClass: ldapsubentry objectClass: nssimpleroledefinition objectClass: nsroledefinition objectClass: nsmanagedroledefinition objectClass: iplanet-am-managed-role objectClass: top iplanet-am-role-description: Provider Admin # # Shared Subordinate Organization. Includes 1 user who is # the Provider Administrator. # dn: o=<provider_sub_org>,=<providerorg>,<maildomain_dn> changetype: add preferredMailHost: <preferredmailhost> sunNameSpaceUniqueAttrs: uid o: <provider_sub_org> objectClass: inetdomainauthinfo objectClass: top objectClass: sunismanagedorganization objectClass: sunnamespace objectClass: sunmanagedorganization objectClass: organization objectClass: sunDelegatedOrganization objectClass: sunMailOrganization sunAvailableDomainNames: <available_domain_name> sunAvailableServices: <available_services> sunOrgType: shared sunMaxUsers: -1 sunNumUsers: 1 sunMaxGroups: -1 sunNumGroups: 0 sunEnableGAB: true sunAllowMultipleServices: true inetDomainStatus: active sunRegisteredServiceName: GroupMailService sunRegisteredServiceName: DomainMailService sunRegisteredServiceName: UserMailService sunRegisteredServiceName: iPlanetAMAuthService sunRegisteredServiceName: UserCalendarService sunRegisteredServiceName: iPlanetAMAuthLDAPService sunRegisteredServiceName: DomainCalendarService # . # . # [Entries and ACIs required by Access Manager] # . # . dn: ou=People,o=<provider_sub_org>,o=<providerorg>,<maildomain_dn> changetype: add ou: People objectClass: iplanet-am-managed-people-container objectClass: organizationalUnit objectClass: top dn: ou=Groups,o=<provider_sub_org>,o=<providerorg>,<maildomain_dn> changetype: add ou: Groups objectClass: iplanet-am-managed-group-container objectClass: organizationalUnit objectClass: top # . # . # [Entries and ACIs required by Access Manager] # . # . # # User - provider administrator # dn: uid=<spa_uid>,ou=People,o=<provider_sub_org>,o=<providerorg>, \ <maildomain_dn> changetype: add sn: <spa_lastname> givenname: <spa_firstname> cn: <spa_firstname> <spa_lastname> uid: <spa_uid> iplanet-am-modifiable-by: cn=Top-level Admin Role,<ugldapbasedn> objectClass: inetAdmin objectClass: top objectClass: iplanet-am-managed-person objectClass: iplanet-am-user-service objectClass: iPlanetPreferences objectClass: person objectClass: organizationalPerson objectClass: inetuser objectClass: inetOrgPerson objectClass: ipUser objectClass: inetMailUser objectClass: inetLocalMailRecipient objectClass: inetSubscriber objectClass: userPresenceProfile objectClass: icsCalendarUser mailhost: <preferredmailhost> mail: <spa_mailaddress> maildeliveryoption: mailbox mailuserstatus: active inetCos: <spa_servicepackage> inetUserStatus: Active nsroledn: cn=Provider Admin Role,o=<providerorg>,<maildomain_dn> userPassword: <spa_password>
当您创建了提供商组织和 SPA 之后,SPA 就可以创建并管理从属于该提供商组织的共享组织和完整组织。SPA 使用 Delegated Administrator 控制台来完成这些任务。
以下任务概述了创建共享组织或完整组织的关键步骤。 此任务没有说明如何输入使用“创建新组织”向导创建组织时所显示的全部信息。有关“创建新组织”向导的详细说明,请参见 Delegated Administrator 控制台联机帮助。
启动 Delegated Administrator 控制台。
转至以下 url:
http://host: port/da/DA/Login
其中
host 是 Web 容器主机
port 是 Web 容器端口
例如:
http://siroe.com:8080/da/DA/Login
Delegated Administrator 控制台登录窗口将会出现。
使用 SPA 登录 ID 和密码登录到 Delegated Administrator 控制台。
前面一节创建提供商组织和服务提供商管理员介绍了如何创建 SPA。
“服务提供商管理员”页将会出现。默认选中的是“组织”选项卡。此页显示了从属于该 SPA 的提供商组织的组织。
单击新建组织。
“创建新组织”向导将会出现。有关在“创建新组织”向导中输入和选择信息的详细信息,请参见 Delegated Administrator 控制台联机帮助。
在“组织信息”面板中输入信息,然后单击下一步。
“联系信息”面板将会出现。
在“联系信息”面板中输入信息,然后单击下一步。
“帐户信息”面板将会出现。
选择要创建共享组织还是完整组织。
在“帐户信息”面板中,确定新组织将是共享组织还是完整组织。
共享组织将使用与其他组织共享的现有域。
完整组织将拥有自己的唯一域。
要创建共享组织,请单击从可用的域中进行选择单选按钮。
从下拉式列表中选择一个域。
创建共享组织时,会从现有父域继承日历服务的详细信息。因此,不用为新组织输入日历服务信息。“日历服务详细信息”面板不会出现在“创建新组织”向导中。此外,创建了共享组织后,“日历服务详细信息”面板也不会出现在该组织的“属性”页中。
要创建完整组织,请单击新建域单选按钮。
在文本框中输入一个新的邮件域名。例如:siroe.com。
您可以根据需要在新域的别名文本框中为新域输入别名。
在“创建新组织”向导的其余面板中输入信息。
有关这些面板的详细信息,请参见 Delegated Administrator 控制台联机帮助。
运行 Delegated Administrator 配置程序 config-commda 后,您可以选择在目录中安装样例组织数据(在 ldif 文件中定义)。(运行配置程序时,在服务包和组织样例面板中选定装入样例组织。)配置程序会将 da.sample.data.ldif 文件添加到 LDAP 目录树。
此 ldif 文件只是一个示例,并不是用来创建您自己的提供商组织的模板。要创建新的提供商组织,请参见创建提供商组织、从属组织和 SPA 所需的信息。
图 A–1 显示了由样例 ldif 文件提供的组织结构的逻辑视图。(图 A–1 中增加了该文件中不存在的共享组织 HIJ。)
样例 ldif 文件在根后缀节点下包含以下组织:
VIS 提供商组织。以下组织由 VIS 提供商组织的 SPA 来管理:
SESTA,一个完整组织。SESTA 组织拥有自己的域,sesta.com。
DEF,一个共享组织。DEF 组织使用共享域,siroe.com。
ESG 提供商组织。没有为此提供商组织定义任何从属组织。
ldif 文件为这些组织定义了以下管理员职责:
VIS 提供商组织的 SPA (user2@abc.com)
ESG 提供商组织的 SPA (user2_def)
SESTA 组织的 OA (user1@abc.com)
DEF 组织的 OA (user1_def)
在三层目录结构中,目录信息树 (Directory Information Tree, DIT) 与图 A–1 中显示的逻辑视图不完全一样。该 DIT 中所实现的组织的分层结构有些不同。
例如,在 DIT 中,完整域必须直接位于根后缀下。因此,应在根后缀下添加域节点来存储有关共享域(由共享组织使用)和完整组织(拥有自己的域)的 LDAP 信息。
图 A–3 显示了样例组织数据的目录信息树 (Directory Information Tree, DIT) 视图。
图 A–3 中显示的示例(与图 A–1 中显示的逻辑视图相似)包含以下组织:
VIS 和 ESG(提供商组织)
DEF,一个从属于 VIS 提供商组织的共享组织
SESTA,一个从属于 VIS 提供商组织的完整组织
样例组织文件 (da.sample.data.ldif ) 中的节点如下:
ugldapbasedn—此参数表示根后缀。
o=business—包含目录中所有业务的节点。
o=SharedDomainsRoot—包含共享组织使用的域所需的节点。
在此目录信息树中,从属于不同服务提供商组织的共享组织可以使用同一个共享域。这是因为这两个提供商组织都具有 SharedDomainsRoot 节点下的节点。
o=ESGDomainsRoot 和 o=VISDomainsRoot—这些节点包含从属于 ESG 和 VIS 提供商组织的所有完整组织。
每个管理完整组织的提供商组织都必须具有此级(在根后缀下)节点。
ESGDomainsRoot 或 VISDomainsRoot 下可以存在多个完整组织(每个都具有自己的域)。
o=siroe.com—共享域。它由共享组织 DEF 使用。
o=VIS 和 o=ESG—这些提供商组织节点包含从属于 VIS 和 ESG 提供商组织的所有共享组织。
例如,共享组织 DEF 从属于 VIS 提供商组织。
o=SESTA—完整组织。它拥有自己的域,sesta.com。
o=DEF—共享组织。它使用域 siroe.com。
ou=people—必需的标准 LDAP 组织单元,用于包含用户。
图 A–3 中显示的样例组织文件中的某些用户 DN 如下:
对于名为 user1_def 的用户(该用户属于 DEF 组织):
dn: uid=user1_def,ou=People,o=DEF,o=VIS,o=siroe.com, o=SharedDomainsRoot,o=Business,ugldapbasedn |
对于名为 user1 的用户(该用户属于 SESTA 组织):
dn: uid=user1,ou=People,o=SESTA,o=VISDomainsRoot, o=Business,ugldapbasedn |