Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Communications Services 6 2005Q1 Delegated Administrator 管理ガイド 

付録 A
サービスプロバイダ管理者とサービスプロバイダ組織

Delegated Administrator コンソールは、ディレクトリで作成できる新しいタイプの組織のほかに、新しい管理のロール、サービスプロバイダ管理者 (SPA) を提供します。

この付録では次の項目について説明します。

この付録では、サービスプロバイダ管理者のロールと新しい組織のタイプ、および Delegated Administrator でそれらを作成する方法について説明します。


サービスプロバイダ管理者

Delegated Administrator コンソールでは、新しいロールであるサービスプロバイダ管理者 (SPA) に管理作業を委任できます。SPA は下位組織と呼ばれる新しいタイプの組織を作成し、管理できます。

SPA の権限範囲は、最上位管理者 (TLA) から組織管理者 (OA) までの間です。

SPA を使用することで、第 1 章「Delegated Administrator の概要」の「3 層階層」で説明した 3 層管理階層を作成できます。

この第 2 レベルの委任により、大規模な LDAP ディレクトリでサポートされる大規模な顧客ベースの管理が軽減される場合があります。たとえば、ISP はそれぞれ独自の組織を必要とする数百または数千の小規模ビジネスにサービスを提供できます。毎日、数十の新しい組織をディレクトリに追加する必要も生じます。

2 層階層を使用する場合、TLA がこのような組織の新規作成をすべて担当することになります。3 層階層では TLA がこれらの作業を SPA に委任できます。

SPA は新規顧客のために下位組織を作成し、その下位組織のユーザーを管理する OA を割り当てられます。

図 A-1 に、3 層の組織階層の論理図を示します。

図 A-1 サービスプロバイダ管理者を使用するディレクトリ: 論理図

サービスプロバイダ管理者を使用するディレクトリ (論理図)

図 A-1 の例では、プロバイダ組織が 1 つ示されています。ただし、1 つのディレクトリに複数のプロバイダ組織を格納できます。

この例では、管理作業は以下のように委任されます。

プロバイダと下位組織の定義については、「サービスプロバイダ管理者で管理される組織」を参照してください。

サービスプロバイダ管理者のロール

SPA は次の作業を実行できます。

SPA は Delegated Administrator コンソールを使用して上記のタスクを実行できます。このリリースでは、Delegated Administrator ユーティリティには上記のタスクを実行するコマンドオプションは含まれていません。


TLA は既存の共有組織、または完全な組織の変更や削除ができます。TLA は、これらの組織のユーザーも管理できます。

TLA はユーザーから SPA のロールを削除することはできますが、コンソールから SPA のロールを割り当てることはできません。Delegated Administrator の今回のリリースの制約については、「このリリースに関する注意点」を参照してください。

TLA で実行される管理作業の詳細については、第 1 章「Delegated Administrator の概要」の「管理者のロールとディレクトリ階層」を参照してください。


ユーザーに SPA のロールを割り当てる

SPA のロールは、SPA に指定された組織で、その SPA が管理するプロバイダ組織の下位組織のユーザーに割り当てる必要があります。

図 A-1 の例では、VIS という名前のプロバイダ組織に SPA を作成する必要があるとします。ここでは、DEF 組織のuser1に SPA のロールを割り当てています。

プロバイダ組織のノードにはユーザーが含まれていないため、SPA は下位組織に存在している必要があります。

したがって、SPA がプロバイダ組織を管理するためには、その下に少なくとも 1 つの組織を作成する必要があります。この組織を、SPA のロールを割り当てるユーザーが所属する組織として指定します。詳細については、この付録の後半にある「プロバイダ組織とサービスプロバイダ管理者の作成」を参照してください。

このリリースに関する注意点

Delegated Administrator の今回のリリースでは、Delegated Administrator コンソールまたはユーティリティを使用して SPA やプロバイダ組織を作成できません。

SPA やプロバイダ組織を作成するには、サービスプロバイダのカスタムテンプレートであるda.provider.skeleton.ldifを手動で変更する必要があります。

サービスプロバイダのカスタムテンプレートの使用方法については、この付録の後半のと「プロバイダ組織とサービスプロバイダ管理者の作成」を参照してください。


サービスプロバイダ管理者で管理される組織

SPA は SPA のプロバイダ組織下にある次の組織の作成、変更、削除ができます。

プロバイダ組織、完全な組織、共有組織について次の各項で説明します。

プロバイダ組織

プロバイダ組織は、完全な組織および共有組織を論理的に格納している LDAP ディレクトリのノードです。プロバイダ組織のノードには、SPA による下位組織の管理を可能にする属性が備わっています。

LDAP ディレクトリでは、プロバイダ組織をメールドメインの下に置く必要があります。例については、この付録の後半にある「サービスプロバイダ組織のサンプルデータ」を参照してください。

プロバイダ組織はユーザーエントリを格納できません。その代わり、ユーザーはプロバイダ組織下に作成された組織でプロビジョニングされます。

プロバイダ組織は、プロバイダ組織下に作成された組織に関するディレクトリ情報を格納します。
例:

完全な組織

完全な組織には次の特徴があります。

共有組織

共有組織には次の特徴があります。


プロバイダ組織とサービスプロバイダ管理者の作成

Delegated Administrator の今回のリリースでは、独自のプロバイダ組織と SPA (複数) を作成するために、Delegated Administrator で提供されるサービスプロバイダのカスタムテンプレート (da.provider.skeleton.ldif) を使用する必要があります。


Delegated Administrator の設定プログラムを実行する際に、サンプルのプロバイダ組織 (下位組織を含む) とサンプルの SPA をディレクトリにインストールすることもできます。インストールは、設定プログラムの「Load Sample Organizations」を選択すると実行されます。

ただし、このサンプルの組織テンプレート (da.sample.data.ldif) はあくまでもサンプルであり、実際にプロバイダ組織を作成するときのテンプレートではありません。このサンプルの詳細については、この付録の後半にある「サービスプロバイダ組織のサンプルデータ」を参照してください。


プロバイダ組織と SPA を作成すると、その SPA はDelegated Administrator コンソールにログインして下位組織を作成および管理できます。また、その SPA の組織内のユーザーに SPA のロールを割り当てることができます。ただし、これらの SPA が管理できるのは同じプロバイダ組織だけです。

別のプロバイダ組織とそれを管理する SPA を作成するには、改めてサービスプロバイダのカスタムテンプレートを使用する必要があります。

ここで説明する内容は次のとおりです。

テンプレートによって作成されるエントリ

サービスプロバイダのカスタムテンプレートのコピーを編集してディレクトリにインストールすると、次のエントリが作成されます。

図 A-2 は、テンプレートをインストールすることによって作成されたエントリの例を示しています。これが組織のディレクトリ情報ツリー (DIT) 図です。

図 A-2 は一例です。組織名、SPA ユーザー名、DIT 構成は組織によって異なります。

図 A-2 サービスプロバイダのカスタムテンプレートディレクトリ情報ツリー図

サービスプロバイダのカスタムテンプレート (ディレクトリ情報ツリー図)

サンプルとしてインストールしたサービスプロバイダのカスタムテンプレートのノード

図 A-2 に示したノードは次のとおりです。

プロバイダ組織、下位組織、SPA を作成するために必要な情報

プロバイダ組織、1 つの下位組織、1 名の SPA を作成するには、組織の形態に応じてサービスプロバイダのカスタムテンプレートのパラメータを書き換える必要があります。

各パラメータについては、「サービスプロバイダのカスタムテンプレート」に示す da.provider.skeleton.ldif の一覧を参照してください。または、次のディレクトリにある ldif ファイルを開いてください。

da_base/lib/config-templates

これらのパラメータを伴う属性の定義については、『Sun Java System Communications Services Schema Reference』の第 5 章「Communications Services Delegated Administrator (Schema 2) で使用されるクラスと属性」と第 3 章「Attributes」を参照してください。

プロバイダ組織と下位組織を定義するパラメータ

プロバイダ組織と下位組織を作成するには、次のパラメータを編集します。

SPA を定義するパラメータ

SPA を作成するには、次のパラメータを編集します。

サービスプロバイダのカスタムテンプレートを編集し、その情報をディレクトリにインストールする方法については、「プロバイダ組織とサービスプロバイダ管理者を作成する手順」を参照してください。

プロバイダ組織とサービスプロバイダ管理者を作成する手順

プロバイダ組織とサービスプロバイダ管理者を作成するには、次の手順に従います。

  1. ディレクトリにメールドメインを作成します。
  2. まだメールドメインを作成していない場合は、ディレクトリにメールドメインを作成します。プロバイダ組織と下位の共有組織は、このメールドメインを使用します。

  3. da.provider.skeleton.ldif ファイルをコピーし、名前を変更します。
  4. Delegated Administrator をインストールすると、da.provider.skeleton.ldif ファイルが次のディレクトリにインストールされます。

    da_base/lib/config-templates

  5. da.provider.skeleton.ldif ファイルのコピーの次のパラメータを編集します。これらのパラメータを、インストールする値で書き換えます。
  6. パラメータの定義については、「プロバイダ組織、下位組織、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 (Schema 2) で使用されるクラスと属性」と第 3 章「Attributes」を参照してください。

  7. LDAP ディレクトリツール ldapmodify を使って、プロバイダ組織と SPA をディレクトリにインストールします。
  8. コマンド実行の例を次に示します。

    ldapmodify -D <directory manager> -w <password>
    -f <da.provider.finished.ldif>

    各表記の意味は次のとおりです。

    <directory manager> は Directory Server 管理者の名前です。

    <password> は、Directory Service 管理者のパスワードです。

    <da.provider.finished.ldif> は、新しいプロバイダ組織と SPA としてディレクトリにインストールする編集後の ldif ファイルの名前です。

サービスプロバイダのカスタムテンプレート

このテンプレート (da.provider.skeleton.ldif) には、新しいプロバイダ組織と SPA を作成するために書き換える必要があるパラメータが含まれています。

次に、ldif ファイルの中でパラメータを持つ部分を示します。これがファイルのすべてではありません。Access Manager 対応に必要なエントリとACIが、ここには含まれていません。

ldif ファイルの中のパラメータだけを変更してください。Access Manager に関連する項目は変更しないでください。

da.provider.skeleton.ldif File (関連項目)

#
# 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 users who is the Provider Administrator.
#
dn: o=<provider_sub_org>,o=<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>


サービスプロバイダ組織のサンプルデータ

Delegated Administrator 設定プログラム config-commda を実行する際に、オプションでディレクトリにサンプル組織データ (ldif ファイルで定義) をインストールできます。設定プログラムを実行する場合、「Service Package and Organization Samples」パネルで「Load sample organizations」を選択します。設定プログラムは da.sample.data.ldif ファイルを LDAP ディレクトリツリーに追加します。

この ldif ファイルはサンプルであり、実際にプロバイダ組織を作成するためのテンプレートではありません。プロバイダ組織の新規作成については、「プロバイダ組織、下位組織、SPA を作成するために必要な情報」を参照してください。

サンプルデータで提供される組織

図 A-1 にサンプル ldif ファイルで提供される組織構造の論理図を示します。図 A-1 には、ファイルに存在しない共有組織 HIJ が追加されています。

サンプル ldif ファイルでは、ルートサフィックスノード内に次の組織が格納されます。

この ldif ファイルは、次のように組織の管理者のロールを定義します。

論理階層とディレクトリ情報ツリー

3 層ディレクトリ階層では、ディレクトリ情報ツリー (DIT) は図 A-1 に示す論理図と異なります。組織は部分的に異なる階層の DIT で実装されます。

たとえば、DIT では完全なドメインはルートサフィックス直下に存在する必要があります。したがって、ドメインノードはルートサフィックスの下に追加され、共有ドメイン (共有組織で使用) と、完全な組織 (独自のドメインを保有) の LDAP 情報を格納します。

サンプル組織データ: ディレクトリ情報ツリー図

図 A-3 にサンプル組織データのディレクトリ情報ツリー (DIT) 図を示します。

図 A-3 に示す例は、図 A-1 に示す論理図と同様に、次の組織を含みます。

サンプルディレクトリ情報ツリーのノード

サンプル組織ファイル (da.sample.data.ldif) のノードは次のとおりです。

サンプルディレクトリ情報ツリーのユーザー DN

図 A-3 に示すサンプル組織ファイルの一部のユーザー DN は、次のとおりです。



前へ      目次      索引      次へ     


Part No: 819-1101.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.