|
| |
| Sun Java System Communications Services 6 2005Q1 Delegated Administrator 管理ガイド | |
第 1 章
Delegated Administrator の概要Communications Services Delegated Administrator のユーティリティとコンソールでは、Messaging Server などの Communications Services アプリケーションで使用される LDAP ディレクトリでユーザー、グループ、ドメイン、リソースをプロビジョニングできます。
この章では次の項目について説明します。
はじめにDelegated Administrator を使用した場合、LDAP ディレクトリの特定の組織を管理する権限を持つ下位の管理者に、プロビジョニング作業を分散することができます。ユーザー管理を委任できることにより、次の利点がもたらされます。
Delegated Administrator では、2 種類のインタフェースを使用してディレクトリのユーザーおよび組織をプロビジョニングします。
以降の項で、これらのインタフェースについてまとめています。
Delegated Administrator ユーティリティ
Delegated Administrator ユーティリティは、Messaging Server と Calendar Server のユーザーをプロビジョニングするためのコマンド行ツールセットです。以前のリリースでは、Delegated Administrator ユーティリティは User Management Utility と呼ばれていました。
Delegated Administrator ユーティリティを使用すると、組織、ユーザー、グループ、カレンダリソースをプロビジョニングできます。
このユーティリティは commadmin コマンドを使用して起動します。
commadmin ユーティリティで使用できる構文とオプションの詳細については、第 5 章「コマンド行ユーティリティ」を参照してください。
Delegated Administrator コンソール
Delegated Administrator コンソールは、Messaging Server のユーザーと組織をプロビジョニングするためのグラフィカルユーザーインタフェース (GUI) です。
グループとカレンダリソースのプロビジョニングは、Delegated Administrator ユーティリティを使って行います。Delegated Administrator コンソールは使用しないでください。Delegated Administrator の今回のリリースでは、コンソールを使ってグループとカレンダリソースのプロビジョニングを行うことはできません。
コンソールの使用方法については、Delegated Administrator コンソールのオンラインヘルプを参照してください。
Delegated Administrator と LDAP ディレクトリ
Delegated Administrator では、LDAP ディレクトリを変更してユーザーをプロビジョニングできます。ディレクトリを直接変更する必要はありません。ただし、ディレクトリのユーザーエントリと高位のノードに追加される Delegated Administrator の属性を理解しておくと役に立つ場合があります。
Delegated Administrator をサポートする LDAP スキーマのオブジェクトクラスと属性については、『Sun Java System Communications Services Schema Reference』の第 5 章「Communications Services Delegated Administrator (Schema 2) で使用されるクラスと属性」を参照してください。
ユーザーのプロビジョニングのシナリオビジネス上のニーズに応じて、1 人の管理者で管理される簡単なディレクトリ構造、またはプロビジョニング作業および管理作業が下位の管理者に委任される多層ディレクトリ階層を作成できます。
この項では複雑さが増す 3 つのシナリオをまとめています。次に、これらのシナリオの要件をサポートするために Delegated Administrator が提供する管理者のロールとディレクトリ構造を説明します。
単層階層
このシナリオでは、企業または組織が数百または数千の従業員またはユーザーをサポートしている場合を想定しています。すべてのユーザーは 1 つの組織にグループ化されます。単一の管理者のロールでグループ全体が表示され、管理されます。管理作業の委任は起こりません。
図 1-1 に単一組織、単層階層における管理者のロールの例を示します。
図 1-1 単層階層の管理者のロール
この単層階層では、管理者は最上位管理者 (Top-Level Administrator) (TLA) と呼ばれます。
図 1-1 に示す例では、TLA はユーザー (User1、User2 〜 Usern) を直接管理し、プロビジョニングします。
ディレクトリの組織が 1 つの場合、必要な管理者はTLA だけです。
詳細は、次の項を参照してください。
2 層階層
このシナリオでは、インターネットサービスプロバイダ (ISP) などの大企業がビジネス向けにサービスを提供しています。各ビジネスには数千、数万のユーザーを抱える固有のドメインがあります。
すべてのドメインの管理およびプロビジョニングを単一の最上位管理者 (TLA) に依存するのではなく、このシナリオでは下位の管理者への作業の委任をサポートしています。
2 層階層では、ディレクトリに複数の組織が含まれています。各ホストドメインに個別の組織が作成されます。
各組織に組織管理者 (Organization Administrator) (OA) が割り当てられます。OA はその組織のユーザーに対する責任を負います。OA はその OA の組織の外部のディレクトリ情報を表示したり、変更したりすることはできません。
図 1-2 に 2 層階層における管理者のロールの例を示します。
図 1-2 2 層階層の管理者のロール
図 1-2 に示す例では、TLA は OA1、OA2 〜 OAn を作成し、管理します。各 OA は 1 つの組織のユーザーを管理します。
ディレクトリに複数の組織が必要になる場合、TLA と OA を作成し組織とそのユーザーを管理します。
詳細は、次の項を参照してください。
3 層階層
このシナリオでは、ISP などの企業がそれぞれ独自の組織を必要とする何百または何千の小規模ビジネスにサービスを提供しています。
ISP はメールサービスを必要とする数百万のエンドユーザーをサポートする場合があります。さらに、ISP はエンドユーザーのビジネスを管理するサードパーティ再販業者と連携して作業する場合があります。
毎日、数十の新しい組織をディレクトリに追加する必要も生じます。
2 層階層では、TLA がこのような組織の新規作成を担当します。
3 層階層では、管理タスクは第 2 レベルの管理者に委任されます。この第 2 レベルの委任により、大規模な LDAP ディレクトリでサポートされる大規模な顧客ベースの管理が軽減される場合があります。
この階層をサポートするために、Delegated Administrator は新しいロールであるサービスプロバイダ管理者 (SPA) を導入します。
SPA の権限範囲は、最上位管理者 (TLA) から組織管理者 (OA) までの間です。
図 1-3 に 3 層階層における管理者のロールの例を示します。
図 1-3 3 層階層の管理者のロール
3 層階層では、TLA は管理権限をサービスプロバイダ管理者 (SPA) に委任します。SPA は新規顧客のためにビジネス組織を作成し、そのビジネス組織のユーザーを管理する組織管理者 (OA) を割り当てます。
サブグループまたは組織に分割される複数の組織が必要になる場合、TLA、SPA、OA の各ロールを実装する 3 層階層を使用できます。
SPA のロールについては、付録 A 「サービスプロバイダ管理者とサービスプロバイダ組織」を参照してください。
管理者のロールとディレクトリ階層この項では単層階層および 2 層階層を実装するディレクトリ情報ツリーの例を示します。次に最上位管理者と組織管理者で実行できるタスクについて説明します。
単層階層をサポートするディレクトリ構造
設定プログラム config-commda を実行して Delegated Administrator を設定するときに、最上位管理者 (TLA) とデフォルト組織を作成します。
単層階層: ルートサフィックス下のデフォルト組織
デフォルトでは、設定プログラムによりデフォルト組織はルートサフィックスの下に置かれます。
ディレクトリ情報ツリーは、図 1-4 のような形式になります。
図 1-4 に単層階層で編成されたディレクトリ情報ツリーの例を示します (デフォルト設定)。
図 1-4 単層階層: ディレクトリ情報ツリー (デフォルト) の例
単層階層: ルートサフィックスのデフォルト組織
設定プログラム (config-commda) を実行する場合、ルートサフィックスの下ではなく、ルートサフィックスと同じレベルでデフォルト組織を作成できます。設定の詳細については、第 3 章「Delegated Administrator の設定」の手順 6、「組織識別名 (DN)」参照してください。
この場合、ディレクトリ情報ツリーは、図 1-5 に示すような構成になります。
ただし、ルートサフィックスのレベルでデフォルト組織を作成する場合、この設定の LDAP ディレクトリは複数のホストドメインをサポートできません。複数のホストドメインをサポートする場合、デフォルト組織をルートサフィックスの下に置く必要があります。
図 1-5 に、デフォルト組織がルートサフィックスのレベルに作成された単層階層の例を示します。
図 1-5 単層階層: ルートサフィックスのデフォルト組織
2 層階層をサポートするディレクトリ構造
config-commda プログラムで Delegated Administrator を設定した後、図 1-6 に示すように、TLA が新たな組織を作成できます。
図 1-6 に 2 層階層で編成されたディレクトリ情報ツリーの例を示します。
図 1-6 2 層階層: ディレクトリ情報ツリーの例
最上位管理者のロール
TLA には次の作業を実行する権限があります。
図 1-6 に示す例では、TLA は siroe.com または sesta.com を変更または削除できます。また新たな組織を作成できます。
この例では、2 つの組織も一意のホストドメインであることに注意してください。
サービスパッケージの詳細については、この章の後半で説明する「サービスパッケージ」を参照してください。
TLA は指定されたタイプのサービスパッケージを組織に割り当て、各パッケージについて、その組織で使用できる回数の上限を決定できます。
たとえば、TLA は次のサービスパッケージを割り当てられます。
TLA が上記のタスクを実行するには、Delegated Administrator コンソールを使用するか、Delegated Administrator ユーティリティ (commadmin) のコマンドを実行します。
commadmin コマンドの詳細については、第 5 章「コマンド行ユーティリティ」の表 5-1、「Delegated Administrator のコマンド行インタフェース」を参照してください。
組織管理者のロール
OA には次の作業を実行する権限があります。
図 1-6 に示す例では、ユーザー johna に組織 siroe.com の OA のロールが割り当てられている場合、johna は siroe.com のユーザーを管理できます。
OA が上記のタスクを実行するには、Delegated Administrator コンソールを使用するか、Delegated Administrator ユーティリティ (commadmin) コマンドを実行します。
OA で使用できる commadmin コマンドの詳細については、第 5 章「コマンド行ユーティリティ」の表 5-1、「Delegated Administrator のコマンド行インタフェース」を参照してください。
以前の iPlanet Delegated Administrator ユーザーについてCommunications Services Delegated Administrator は、LDAP Schema 2 ディレクトリのユーザーのプロビジョニング向けに設計されています。
LDAP Schema 1 ディレクトリを持つ以前のバージョンの Messaging Server のユーザーは、非推奨ツールである iPlanet Delegated Administrator を使用している場合があります。現在も Shema 1 ディレクトリが存在する場合、iPlanet Delegated Administrator を使用してユーザーをプロビジョニングすることをお勧めします。
iPlanet Delegated Administrator で使用する管理者のロールについての用語は、Communications Service Delegated Administrator で現在使用されているものとは多少異なります。
表 1-1 に各バージョンの Delegated Administrator の管理者のロールを示し、定義しています。
サービスパッケージサービスクラスメカニズムは、LDAP ディレクトリにサービスパッケージを実装します。このメカニズムにより、Delegated Adminsitrator を設定したときにディレクトリにインストールされる定義済みの属性に値を設定できます。サービスパッケージは、ユーザーエントリにサービスの特徴を追加します。
Delegated Administrator コンソールで、次のサービスパッケージのタスクを行います。
1 ユーザーに 1 つのサービスパッケージを割り当てる場合、そのサービスパッケージのすべての属性および値が自動的にユーザーに割り当てられます。
サービスクラスの定義
今回のリリースでは、Messaging Server ユーザーに対するサービスクラスが 1 つ定義されています。表 1-2 にメールユーザーに定義された LDAP 属性を示します。
これらの属性の詳細については、『Sun Java System Communications Services Schema Reference』の第 3 章「Attributes」を参照してください。
これらのメールサービス属性は、standardMail というサービスクラス定義で定義されます。Delegated Administrator を設定すると、ディレクトリに standardMail 定義がインストールされます。
standardMail Class-of-Service の定義は次のとおりです。
メール属性に加え、standardMail 定義は、属性 daServiceType でメールユーザーとしてのサービスタイプを定義します。
拡張サービスパッケージの表示に関する制限
Delegated Administrator サービスパッケージの定義は、定義エントリに属性を追加することによって拡張できます。
ただし、Delegated Administrator の今回のリリースでは、Delegated Administrator を設定するときコンソールに表示できるのは定義済みの属性だけです。Delegated Administrator コンソールに、サービスパッケージ定義に追加した属性は表示されません。
このリリースでは、Delegated Administrator が提供する standardMail Class-of-Service 定義から定義済み属性を削除しないでください。
サービスクラステンプレート
サービスクラス定義で使用できる属性に基づき、各ユーザーに異なるレベルのサービスを定義する独自のサービスパッケージを作成できます。
デフォルトサービスクラステンプレート
デフォルトでは、Delegated Administrator の設定プログラム (config-commda) がディレクトリに ldif ファイル、cos.default.ldif をインストールします。この ldif ファイルは defaultmail と呼ばれる汎用サービスクラステンプレートを提供します。
次のサービスクラステンプレートは、cos.default.ldif ファイル内にあります。
dn: cn=defaultmail,o=cosTemplates,<ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
mailquota: -2
cn: defaultmail
注意: Delegated Administrator 構成プログラムがディレクトリに defaultmail テンプレートをインストールすると、前述の <ugldapbasedn> 変数 がユーザーのルートサフィックスに置き換えられます (例: o=usergroup)。
デフォルトのサービスクラステンプレート (defaultmail) では、メールサービス属性として mailquota のみが定義されています。その値は -2 で、このサービスのメール制限容量がシステムデフォルトであることを示しています。
サンプルサービスクラステンプレート
Delegated Administrator の設定プログラム config-commda を実行する場合、サンプルサービスパッケージを追加してロードできます。設定プログラムを実行するときに、「Service Package and Organization Samples」パネルで「Load sample service packages」を選択してください。設定プログラムは cos.sample.ldif ファイルを LDAP ディレクトリツリーに追加します。
cos.sample.ldif ファイルには、次のサンプルサービスクラステンプレートが収められています。
各テンプレートには、サービスクラス定義の 1 つまたは複数の属性に対する特定の値が含まれています。テンプレートはサービスパッケージのプロトタイプサンプルです。
たとえば、platinum サービスクラステンプレートは、cos.sample.ldif ファイル内にあります。
dn: cn=platinum,o=cosTemplates,$rootSuffix
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: platinum
mailMsgMaxBlocks: 800
mailQuota: 4000000000
mailMsgQuota: 6000
mailAllowedServiceAccess: +imap:ALL$+pop:ALL$+smtp:ALL$+http:ALL
注意: Delegated Administrator 構成プログラムがディレクトリにサンプルサー ビスクラステンプレートをインストールすると、前述の $rootSuffix 変数がユー ザーのルートサフィックスに置き換えられます (例: o=usergroup)。
すべてのサンプルサービスクラステンプレートのメールサービスの値のリストについては、この章の最後の「サンプルサービスクラステンプレートのメールサービスレベル」を参照してください。
独自のサービスパッケージの作成
この章で説明するサービスクラステンプレートは、一例です。実際のインストールにあたっては、適切な属性値で独自のサービスパッケージを作成する必要があります。
独自のサービスパッケージは、da.cos.skeleton.ldif ファイルに保存されているサービスクラステンプレートを使用して作成します。このファイルは、サービスパッケージのテンプレートとして使用するために作成されたものです。Delegated Administrator を設定するときには、このファイルは LDAP ディレクトリにインストールされません。
da.cos.skeleton.ldif ファイルをコピーして編集し、ldapmodify などの LDAP ディレクトリツールを使用するとサービスパッケージをディレクトリにインストールできます。
da.cos.skeleton.ldif ファイルを使って独自のサービスパッケージを設定する方法については、第 3 章「Delegated Administrator の設定」の「サービスパッケージの作成」を参照してください。
LDAP ユーザーエントリに割り当てられるサンプルサービスパッケージ
Delegated Administrator を使用してユーザーにサービスパッケージを割り当てる場合、LDAP ディレクトリのユーザーエントリに 1 つの属性 (inetCOS) が追加されます。属性 inetCOS の値により、ユーザーにサービスパッケージ全体が割り当てられます。inetCOS は多値属性です。
たとえば、platinum パッケージをユーザーに割り当てる場合を想定してください。次の属性がユーザーエントリに追加されます。
platinum パッケージには、メールサービス属性の次の値が指定されます。この場合、platinum パッケージを割り当てることで、ユーザーエントリにこれらの属性が追加されるという効果があります。
サービスクラス定義とパッケージの場所
LDAP ディレクトリ情報ツリー (DIT) では、Service はルートサフィックス直下のノードで定義されます。サービスパッケージは DIT のトップに置かれるため、ディレクトリの全ユーザーエントリに割り当てられます。
図 1-7 に、Service の定義とパッケージの DIT における位置を示します。2 つのパッケージ、Gold と Silver を例として示しています。
図 1-7 サービスクラス定義とパッケージのディレクトリツリー内の場所
Delegated Administrator は標準的なサービスクラス定義を使用します。
サービスクラスの仕組みについての詳細は、『Sun Java System Directory Server 管理ガイド』を参照してください。特に第 5 章「ID とロールの管理」の「サービスクラス (CoS) の定義」を参照してください。
『Directory Server 管理ガイド』では、サービスパッケージで定義されユーザーに割り当てられた属性が、すでにその個々のユーザーエントリ内にある場合の、優先されるサービス属性の値の判断など、関連項目も説明しています。
サンプルサービスクラステンプレートのメールサービスレベル
この項では、サンプルサービスクラステンプレートが提供するメールサービスのレベルを示します。このテンプレートの属性値はサンプルで、実際のインストールに基づくものではありません。
Platinum
mailMsgMaxBlocks: 800
mailquota: 10000000
mailmsgquota: 6000
mailAllowedServiceAccess: +imap:ALL$+pop:ALL$+smtp:ALL$+http:ALLGold
mailMsgMaxBlocks: 700
mailquota: 8000000
mailmsgquota: 3000
mailAllowedServiceAccess: +imap:ALL$+pop:ALL$+smtp:ALL$+http:ALLSilver
mailMsgMaxBlocks: 300
mailquota: 6291456
mailmsgquota: 2000
mailAllowedServiceAccess:+pop:ALL$+imap:ALL$+smtp:ALL$+http:ALLBronze
mailMsgMaxBlocks: 700
mailquota: 5242288
mailmsgquota: 3000
mailAllowedServiceAccess:+pop:ALL$+imap:ALL$+smtp:ALL$+http:ALLRuby
mailMsgMaxBlocks: 600
mailquota: 1048576
mailmsgquota: 2000
mailAllowedServiceAccess:+pop:ALL$+smtp:ALL$+http:ALLEmerald
mailMsgMaxBlocks: 600
mailquota: 2097152
mailmsgquota: 2000
mailAllowedServiceAccess:+pop:ALL$+smtp:ALL$+http:ALLDiamond
mailMsgMaxBlocks: 5000
mailquota: 3145728
mailmsgquota: 3000
mailAllowedServiceAccess:+imap:ALL$+smtp:ALL$+http:ALLTopaz
mailMsgMaxBlocks: 3000
mailquota: 4194304
mailmsgquota: 2000
mailAllowedServiceAccess:+imap:ALL$+smtp:ALL$+http:ALL
