![]() | |
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 は次の作業を実行できます。
図 A-1 に示す例では、VIS プロバイダ組織の SPA は次のことができます。
図 A-1 の例では、 SPA が OA のロールを SESTA 組織のuser2 に割り当てると、user2 は SESTA 組織のユーザーを管理できるようになります。
SPA はユーザーから OA のロールを削除することもできます。
サービスクラスパッケージの詳細は、第 1 章「Delegated Administrator の概要」の「サービスパッケージ」を参照してください。
SPA は指定されたタイプのサービスクラスパッケージを組織に割り当て、各パッケージについて、その組織で使用できる数の上限を決定できます。
たとえば、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 ディレクトリでは、プロバイダ組織をメールドメインの下に置く必要があります。例については、この付録の後半にある「サービスプロバイダ組織のサンプルデータ」を参照してください。
プロバイダ組織はユーザーエントリを格納できません。その代わり、ユーザーはプロバイダ組織下に作成された組織でプロビジョニングされます。
プロバイダ組織は、プロバイダ組織下に作成された組織に関するディレクトリ情報を格納します。
例:完全な組織
完全な組織には次の特徴があります。
図 A-1 に示す例では、ユーザー user2 は sesta.com ドメインに属し、メールアドレス user2@sesta.com を持ちます。
図 A-1 に示す例では、完全な組織 SESTA はドメイン名 sesta.com を持っています。
共有組織
共有組織には次の特徴があります。
図 A-1 に示す例では、ユーザー user5 は siroe.com ドメインに属し、メールアドレス user5@siroe.com を持ちます。
図 A-1 に示す例では、共有組織 DEF はドメイン名 siroe.com を持ちます。
図 A-1 に示す例では、DEF と HIJ のいずれの組織も siroe.com ドメインに属します。
プロバイダ組織とサービスプロバイダ管理者の作成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 を作成するには、改めてサービスプロバイダのカスタムテンプレートを使用する必要があります。
ここで説明する内容は次のとおりです。
- テンプレートによって作成されるエントリ: テンプレートのコピーを編集しディレクトリにインストールして作成した組織のサンプルを示しています。
- プロバイダ組織、下位組織、SPA を作成するために必要な情報: プロバイダ組織、下位の共有組織、SPA を作成するために必要なテンプレートのパラメータを定義します。
- プロバイダ組織とサービスプロバイダ管理者を作成する手順: テンプレートの編集方法とディレクトリへのインストール方法を説明します。
- サービスプロバイダのカスタムテンプレート: テンプレートのリストです。
テンプレートによって作成されるエントリ
サービスプロバイダのカスタムテンプレートのコピーを編集してディレクトリにインストールすると、次のエントリが作成されます。
図 A-2 は、テンプレートをインストールすることによって作成されたエントリの例を示しています。これが組織のディレクトリ情報ツリー (DIT) 図です。
図 A-2 は一例です。組織名、SPA ユーザー名、DIT 構成は組織によって異なります。
図 A-2 サービスプロバイダのカスタムテンプレートディレクトリ情報ツリー図
サンプルとしてインストールしたサービスプロバイダのカスタムテンプレートのノード
図 A-2 に示したノードは次のとおりです。
- o=usergroup - ユーザー/グループデータのルートサフィックス。
- o=siroe.com - プロバイダ組織が使用するメールドメイン。
- o=MyProviderOrg - プロバイダ組織のノード。
- o=MySPAUserOrg - プロバイダ組織のユーザー (SPA のロールが割り当てられるユーザーを含む) が所属する下位の共有組織。
- ou=people - ユーザーの格納に必要な標準 LDAP 組織単位。
- uid=user1 - MySPAUserOrg 組織で SPA になるユーザーの uid。
- o=MyProviderOrgDomainsRoot - MyProviderOrg プロバイダ組織の下位にある完全な組織を保持するプレースホルダノード。
プロバイダ組織、下位組織、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」を参照してください。
プロバイダ組織と下位組織を定義するパラメータ
プロバイダ組織と下位組織を作成するには、次のパラメータを編集します。
プロバイダ組織の下位組織のユーザーに割り当てるサービスパッケージの名前。これは、多値パラメータです。
da.provider.skeleton.ldif ファイルの "Provider Organization" の項には、次の属性があります。
sunIncludeServices: <servicepackage>
プロバイダ組織にサービスパッケージを含めるときは、属性 sunIncludeServices のインスタンス 1 つとパラメータ servicepackage を追加します。下位組織のユーザーには、ここに記述したサービスパッケージのみ割り当てられます。
例:
sunIncludeServices: gold
sunIncludeServices: platinum
sunIncludeServices: ruby
sunIncludeServices: silver属性 sunIncludeServices を使用しない場合 (servicepackage が含まれている行を削除した場合) は、ディレクトリ内のすべてのサービスパッケージを割り当てることができます。
プロバイダ組織の下位組織に割り当てられるドメイン名。これは、多値パラメータです。
da.provider.skeleton.ldif ファイルの "Provider Organization" の項には、次の属性があります。
sunAssignableDomains: <domain_name>
属性 sunAssignableDomains のドメイン名は、メールドメイン組織の属性 sunPreferredDomain と属性 associatedDomain に記述した名前の一部 (または全部) です。メールドメイン組織の下にプロバイダ組織が作成されます。
プロバイダ組織にドメイン名を含めるときは、属性 sunAssignableDomains のインスタンス 1 つと、パラメータ domain_name を追加します。下位組織には、ここに記述したドメイン名だけが割り当てられます。
例:
sunAssignableDomains: siroe.com
sunAssignableDomains: siroe.net
sunAssignableDomains: varrius.com
sunAssignableDomains: sesta.com
sunAssignableDomains: sesta.net
SPA ユーザーが所属する共有組織の名前。編集した ldif の情報をディレクトリにインストールすると、プロバイダ組織の下に共有組織が作成されます。この組織は、SPA ユーザーが所属する組織として指定されます。プロバイダ組織の SPA になるほかのユーザーも、すべてこの共有組織に所属する必要があります。
da.provider.skeleton.ldif ファイルの "Provider Organization" の項には、次の属性があります。
sunProviderOrgDN:
o=<provider_sub_org>,o=<providerorg>,<maildomain_dn>属性 sunProviderOrgDNは、プロバイダ組織ユーザーの中でも、特に SPA ユーザーが所属する組織を識別します。
例:
sunProviderOrgDN:
o=MySPAUserOrg,o=MyProviderOrg,o=siroe.com,o=usergroup
特定の下位組織のユーザーに割り当てられるドメイン名。これは、多値パラメータです。
available_domain_name の値は、属性とパラメータ sunAssignableDomains: <domain_name> の値の一部です。domain_name がプロバイダ組織全体に適用されるのに対し、available_domain_name は 1 つの下位組織に適用されます。
da.provider.skeleton.ldif ファイルの "Shared Subordinate Organization" の項には、次の属性があります。
sunAvailableDomainNames: <available_domain_name>
プロバイダ組織の属性 sunAssignableDomains から下位組織に継承するドメイン名ごとに、属性 sunAvailableDomains のインスタンス 1 つとパラメータ available_domain_name を追加します。下位組織には、ここに記述したドメイン名だけが割り当てられます。
例:
sunAvailableDomainNames: siroe.com
sunAvailableDomainNames: siroe.net
sunAvailableDomainNames: varrius.com
特定の下位組織で使用可能なサービスパッケージ。これは、多値パラメータです。
下位組織に割り当てるサービスパッケージは、属性 sunIncludeServices でプロバイダ組織全体に割り当てたパッケージの一部です。
da.provider.skeleton.ldif ファイルの "Shared Subordinate Organization" の項には、次の属性があります。
sunAvailableServices: <available_services>
パラメータ available_services の形式は次のとおりです。
Service package name: count
countは整数で指定します。数を指定しないと、無制限になります。
プロバイダ組織の属性 sunIncludeServices から下位組織に継承するサービスパッケージごとに、属性 sunAvailableServices のインスタンス 1 つとパラメータ available_services を追加します。
例:
sunAvailableServices: gold:1500
sunAvailableServices: platinum:2000
sunAvailableServices: silver:5000SPA を定義するパラメータ
SPA を作成するには、次のパラメータを編集します。
SPA ユーザーに割り当てられたサービスパッケージ。サービスパッケージの詳細は、第 1 章「Delegated Administrator の概要」の「サービスパッケージ」を参照してください。
例:
inetCos:platinum
SPA ユーザーの電子メールアドレス。メールアドレスのドメイン部分は、必ず available_domain_name のパラメータとして設定したドメイン値の中の 1 つになります。すなわち、必ず SPA ユーザーが所属する下位組織に割り当てられたドメインになります。詳細については、「available_domain_name」を参照してください。
例:
mail: user1@siroe.com
サービスプロバイダのカスタムテンプレートを編集し、その情報をディレクトリにインストールする方法については、「プロバイダ組織とサービスプロバイダ管理者を作成する手順」を参照してください。
プロバイダ組織とサービスプロバイダ管理者を作成する手順
プロバイダ組織とサービスプロバイダ管理者を作成するには、次の手順に従います。
- ディレクトリにメールドメインを作成します。
まだメールドメインを作成していない場合は、ディレクトリにメールドメインを作成します。プロバイダ組織と下位の共有組織は、このメールドメインを使用します。
- 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 (Schema 2) で使用されるクラスと属性」と第 3 章「Attributes」を参照してください。
- 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 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 は、次のとおりです。