test

Sun Java System Communications Services 6 2005Q4 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 は次の作業を実行できます。

注 –

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

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

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

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

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

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

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

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

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

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

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

サービスプロバイダのカスタムテンプレートを使用してこれらの作業を実行する手順については、この付録で後述する 「プロバイダ組織とサービスプロバイダ管理者の作成」を参照してください。

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

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

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

プロバイダ組織

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

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

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

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

完全な組織

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

共有組織

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

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

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

注 –

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

ただし、サンプル組織のテンプレート (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 Classes and Attributes (Schema 2)」および第 3 章「Messaging Server and Calendar Server Attributes」を参照してください。

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

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

SPA を定義するパラメータ

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

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

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

ldif ファイルの da.provider.skeleton.ldif を使用して、次の手順を実行します。

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

手順

  1. ディレクトリにメールドメインを作成します。

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

  2. da.provider.skeleton.ldif ファイルをコピーし、名前を変更します。

    Delegated Administrator をインストールすると、da.provider.skeleton.ldif ファイルが次のディレクトリにインストールされます。

    da_base /lib/config-templates

  3. 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」を参照してください。

  4. LDAP ディレクトリツール ldapmodify を使用して、プロバイダ組織と SPA をディレクトリにインストールします。

    コマンド実行の例を次に示します。


    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 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 コンソールのオンラインヘルプを参照してください。

Procedure共有または完全な下位組織を作成する

手順

  1. Delegated Administrator コンソールを起動します。

    次の URL に進みます。

    http://host: port/da/DA/Login

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

    host は Web コンテナのホストマシンです。

    port は Web コンテナのポートです。

    次に例を示します。

    http://siroe.com:8080/da/DA/Login

    Delegated Administrator コンソールのログインウインドウが表示されます。

  2. SPA のログイン ID とパスワードを使用して Delegated Administrator コンソールにログインします。

    SPA の作成方法については、すでに「プロバイダ組織とサービスプロバイダ管理者の作成」で説明しています。

    「サービスプロバイダ管理者」ページが表示されます。デフォルトで「組織」タブが選択されています。このページには、SPA のプロバイダ組織の下位組織が表示されます。

  3. 「新規組織」をクリックします。

    「新しい組織を作成」ウィザードが表示されます。「新しい組織を作成」ウィザードでの情報の入力方法と選択方法については、Delegated Administrator コンソールのオンラインヘルプを参照してください。

  4. 「組織情報」パネルに情報を入力し、「次へ」をクリックします。

    「連絡先情報」パネルが表示されます。

  5. 「連絡先情報」パネルに情報を入力し、「次へ」をクリックします。

    「アカウント情報」パネルが表示されます。

  6. 共有組織または完全な組織を作成するかどうかを選択します。

    「アカウント情報」パネルで、新しい組織を共有組織とするか完全な組織とするかを決定します。

    共有組織は、ほかの組織と共有される既存のドメインを使用します。

    完全な組織は独自の固有ドメインを持ちます。

    • 共有組織を作成するには、「利用可能なドメインから選択」ラジオボタンをクリックします。

      ドロップダウンリストからドメインを選択します。

      注 –

      共有組織の作成時には、カレンダサービスの詳細が既存の親ドメインから継承されます。したがって、新しい組織のためにカレンダサービスの情報を入力することはありません。「新しい組織を作成」ウィザードに「カレンダサービスの詳細」パネルは表示されません。さらに、共有組織の作成後は、「カレンダサービスの詳細」は組織の「プロパティー」ページに表示されません。

    • 完全な組織を作成するには、「新しいドメイン」ラジオボタンをクリックします。

      テキストボックスに新しいメールドメイン名を入力します。例 : siroe.com

      必要に応じて、「新しいドメインのエイリアス名」テキストボックスに新しいドメインのエイリアス名を入力します。

  7. 「新しい組織を作成」ウィザードの残りのパネルで情報を入力します。

    後続のパネルの詳細については、Delegated Administrator コンソールのオンラインヘルプを参照してください。

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

Delegated Administrator 設定プログラム config-commda の実行時に、サンプル組織データ (ldif ファイルで定義) をディレクトリにインストールすることを選択できます。設定プログラムを実行するときに、「サービスパッケージと組織のサンプル」パネルで「サンプル組織を読み込む」を選択してください。設定プログラムによって、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 の論理図と同様に次の組織が含まれます。

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

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

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

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

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

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