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 の例では、プロバイダ組織が 1 つ示されています。ただし、1 つのディレクトリに複数のプロバイダ組織を格納できます。
この例では、管理作業は以下のように委任されます。
SPA は、VIS プロバイダ組織およびその下にあるすべての組織を管理する権限を持っています。SPA のロールは、DEF 組織の user1 に割り当てられています。
組織管理者 OA1 は、共有組織である DEF を管理します。この OA のロールは、DEF 組織の user2 に割り当てられています。
OA2 は共有組織 HIJ を管理します。この OA のロールは、HIJ 組織の user4 に割り当てられています。
OA3 は完全な組織 SESTA を管理します。この OA のロールは、SESTA 組織の user1 に割り当てられています。
SESTA は 1 つの完全な組織で、固有の名前空間を持っています。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 は、これらの組織のユーザーも管理できます。
TLA はユーザーから SPA のロールを削除することはできますが、コンソールから SPA のロールを割り当てることはできません。このリリースの Delegated Administrator の制約については、「このリリースに関する注意点」を参照してください。
TLA によって実行される管理作業の詳細については、第 1 章「Delegated Administrator の概要」の 「管理者のロールとディレクトリ階層」を参照してください。
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 ディレクトリでは、プロバイダ組織をメールドメインの下に置く必要があります。この付録で後述する「サービスプロバイダ組織のサンプルデータ」に例を示します。
プロバイダ組織はユーザーエントリを格納できません。その代わり、ユーザーはプロバイダ組織下に作成された組織でプロビジョニングされます。
プロバイダ組織は、プロバイダ組織下に作成された組織に関するディレクトリ情報を格納します。次に例を示します。
プロバイダ組織下に格納される組織の種類、すなわち共有組織、完全な組織、両方の組織のいずれか。
このプロバイダ組織内で作成された共有組織が使用できるドメイン名。
このプロバイダ組織内で作成された組織が利用できる、サービスクラスパッケージのタイプと数。
プロバイダ組織の SPA が所属する組織。
プロバイダ組織の下位組織であり、SPA により作成されます。
ユーザーは完全な組織でプロビジョニングされます。
図 A–1 に示す例では、user2 は sesta.com ドメインに所属し、user2@sesta.com というメールアドレスを持ちます。
完全な組織は、ほかの組織が共有することができない独自のドメインと固有の名前空間を持っています。
図 A–1 に示す例では、完全な組織である SESTA のドメイン名は sesta.com です。
プロバイダ組織の下位組織であり、SPA により作成されます。
ユーザーは共有組織でプロビジョニングされます。
図 A–1 に示す例では、 user5 は siroe.com ドメインに所属し、user5@siroe.com というメールアドレスを持ちます。
プロバイダ組織が提供するリストの 1 つまたは複数の共有ドメイン名を使用します。
図 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 のロールを割り当てられる下位組織のユーザー1名。
完全な組織を作成できるプレースホルダのノード。プロバイダ組織の SPA がこの完全な組織を管理します。
図 A–2 に、テンプレートのインストール時に作成されるエントリの例を示します。これを組織のディレクトリ情報ツリー (DIT) と呼びます。
図 A–2 は一例です。組織名、SPA ユーザー名、DIT 構成は組織によって異なります。
図 A–2 に示す例のノードは次のとおりです。
o=usergroup - ユーザー/グループデータのルートサフィックス。
o=siroe.com - プロバイダ組織が使用するメールドメイン。
o=MyProviderOrg - プロバイダ組織のノード。
o=MySPAUserOrg - プロバイダ組織のユーザー (SPA のロールが割り当てられるユーザーを含む) が所属する下位の共有組織。
ou=people - ユーザーの格納に必要な標準 LDAP 組織単位。
uid=user1 - MySPAUserOrg 組織で SPA になるユーザーの uid。
o=MyProviderOrgDomainsRoot - MyProviderOrg プロバイダ組織の下位にある完全な組織を保持するプレースホルダノード。
プロバイダ組織、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」を参照してください。
プロバイダ組織と下位組織を作成するには、次のパラメータを編集します。
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 ファイルの「Provider Organization」の項には、次の属性があります。
sunIncludeServices: <servicepackage>
プロバイダ組織にサービスパッケージを含めるときは、属性 sunIncludeServices のインスタンス 1 つとパラメータ servicepackage を追加します。下位組織のユーザーには、ここに記述したサービスパッケージのみ割り当てられます。
例
sunIncludeServices: gold sunIncludeServices: platinum sunIncludeServices: ruby sunIncludeServices: silver |
属性 sunIncludeServices を使用しない場合 (パラメータ servicepackage が含まれている行を削除した場合) は、ディレクトリ内のすべてのサービスパッケージを割り当てることができます。
domain_name
プロバイダ組織の下位組織に割り当てられるドメイン名。これは、多値パラメータです。
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 |
provider_sub_org
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 |
preferredmailhost
SPA ユーザーが所属するプロバイダ組織の、下位組織のメールホストにするマシンの名前。必ず完全修飾ドメイン名 (FQDN) を使用します。
da.provider.skeleton.ldif ファイルの「Shared Subordinate Organization」の項には、次の属性があります。
preferredMailHost: <preferredmailhost>
例
preferredMailHost: mail.siroe.com
available_domain_name
特定の下位組織のユーザーに割り当てられるドメイン名。これは、多値パラメータです。
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 |
available_services
特定の下位組織で使用可能なサービスパッケージ。これは、多値パラメータです。
下位組織に割り当てるサービスパッケージは、属性 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: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 のパラメータとして設定したドメイン値の中の 1 つになります。すなわち、必ず 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 Service 管理者のパスワードです。
<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)
3 層ディレクトリ階層では、ディレクトリ情報ツリー (DIT) は 図 A–1 に示される論理図とは厳密には一致しません。組織は部分的に異なる階層の DIT で実装されます。
たとえば、DIT では完全なドメインはルートサフィックス直下に存在する必要があります。したがって、ドメインノードはルートサフィックスの下に追加され、共有ドメイン (共有組織で使用) と、完全な組織 (独自のドメインを保有) の LDAP 情報を格納します。
図 A–3 に、サンプル組織データのディレクトリ情報ツリー (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 は、次のとおりです。
DEF 組織に所属するユーザー user1_def
dn: uid=user1_def,ou=People,o=DEF,o=VIS,o=siroe.com, o=SharedDomainsRoot,o=Business,ugldapbasedn |
SESTA 組織に所属するユーザー user1
dn: uid=user1,ou=People,o=SESTA,o=VISDomainsRoot, o=Business,ugldapbasedn |