前へ 目次 索引 DocHome 次へ |
iPlanet Messaging Server 5.2 プロビジョニングガイド |
第 1 章 プロビジョニングの概念とテクノロジ
この章では、iPlanet Messaging Serverのプロビジョニングに関する概念とテクノロジを説明します。この章には、以下の節があります。
「iPlanet Messaging Server ネームスペース」
iPlanet Messaging Server のプロビジョニング
プロビジョニングとは、Directory Server 内の iPlanet Messaging Server ユーザ、メーリングリスト、システム管理者、ドメインの各エントリに関する追加、変更、削除を行うことです。Messaging Server は、必要に応じてディレクトリを照会することにより、これらの要素に関する情報を取得します。iPlanet Messaging Server には、次の 4 つのプロビジョニングインタフェースがあります。
iPlanet Delegated Administrator for Messaging コンソール
このマニュアルでは、LDAP を使用してプロビジョニングを行う方法について説明します。他のプロビジョニング方法に触れる場合がありますが、このマニュアルでは、LDAP を使用したプロビジョニングを中心に説明します。iPlanet Delegated Administrator for Messaging コマンドラインユーティリティ
iPlanet Messaging Server ネームスペース
インストール後の iPlanet Messaging Server ネームスペースは、「組織ツリー」および「ドメインコンポーネントツリー (DC ツリー) 」の 2 つのディレクトリ情報ツリー (DIT) で構成されます。組織ツリーは、ユーザおよびグループの各エントリを含んでいます。DC ツリーは、ローカル DNS 構造をミラー化したものであり、データエントリを含む組織ツリーへのインデックスとしてシステムにより使用されます (図 1-2 を参照)。DC ツリーはさらに、スマートホスト、ルーティングホスト、ドメインディスク容量制限などの、ドメインの操作パラメータを含んでいます。この後の節では、組織ツリーと DC ツリーからなる「二重ツリー機構」の仕組みと、この機構が選択された理由について説明します。既存の DIT を iPlanet Messaging Server の 二重ツリー機構へ移植する方法の詳細については、『iPlanet Messaging Server 移行ガイド』を参照してください。
二重ツリーネームスペース機構の仕組み
この節では、iPlanet Messaging Server が 2 つの DIT 機構をどのように利用しているかを説明します。iPlanet Messaging Server がユーザまたはグループのエントリを検索する場合、初めに DC ツリー内でユーザまたはグループのドメインノードを検索し、inetDomainBaseDN 属性の値を展開します。この属性には、実際のユーザまたはグループのエントリを含む組織サブツリーへの DN 参照が格納されています。
このモデルを使用することで、iPlanet Messaging Server は任意のタイプのディレクトリツリー内に格納されたエントリをサポートできます。ただし条件として、DC ツリー内のドメインコンポーネントノードが、そのドメインのユーザが見つかる組織ツリー内のノードを指している必要があります。この関係を、図 1-1 の例に示します。この図の点線は inetDomainBaseDN の値を示しています。組織ツリー内のノード名は、DC ツリー内のノード名と一致している必要はありません。
図 1-1    iPlanet Messaging Server ディレクトリ構造の例
  
この例では、データエントリが組織ツリーの下で追加および変更されていますが、実際にはメッセージサーバは DC ツリーを参照します。次の 3 人のユーザについて考えてみます。
ユーザ 1
ユーザ 2
ユーザ 3
名前 :
John Doe
John Doe
Jane Doe
ドメイン :
siroe.com
west.siroe.com
varrius.org
UID :
jdoe
jdoe
jdoe
ログイン :
jdoe@siroe.com
jdoe@west.siroe.com
jdoe@varrius.org
ログイン名は UID とドメインで構成されます。どのユーザの場合にも、サーバはログインのドメイン部分 (@ マークの後の値) を探し、対応する DC ノードの inetdomainbasedn 属性から DN を取得します。次に、ログイン名のローカル部分 (@ マークの前の値) と等しい UID を持つユーザエントリを、DN によって指定されたサブツリーから検索します。
たとえばwest.siroe.com に属する John Doe は、ログイン名 jdoe@west.siroe.com を使用して、サーバにログインします。サーバは、DC ノード内の west.siroe.com に対する DN 参照 (inetdomainbasedn) を o=west.siroe.com, o=isp までたどります。
インストール時に、iPlanet Messaging Server は、既存の DNS にマップされるデフォルトの DC ツリーと組織ツリーを作成します。Delegated Administrator コマンド imadmin domain create を使用してディレクトリドメインノードを追加すると、対応するノードが DC ツリーと組織ツリーの両方に作成されます。LDAP インタフェースを使用してノードを作成する場合は、そのドメインに対応するノードを DC ツリー内に作成し、データに対応するドメインを組織ツリー内に作成する必要があります。この手順は、『iPlanet Messaging Server 移行ガイド』に記載されています。
注
2 つのディレクトリ情報ツリーが必要な理由
iPlanet Messaging Server は、構成情報およびユーザやグループのデータを含む単一の DC ツリーをサポートします。しかし、インストール時には、iPlanet Messaging Server は、DC ツリーと組織ツリーの両方を作成します。この二重ツリー機構は次の拡張機能を提供します。
既存の DIT にマップする DC ツリーを作成することによって、iPlanet Messaging Server が既存のディレクトリを利用できる
組織に特有のアクセス制御を行うために、データをパーティション化できる。つまり各組織は、ユーザとグループのエントリが置かれた DIT 内に個別のサブツリーを持つことができます。データにアクセスできるユーザを、そのサブツリーに含まれるユーザに制限できます。これにより、iPlanet Delegated Administrator for Messaging のようなローカライズされたアプリケーションを安全に稼動できる
サブドメイン用の個別のネームスペースを持つことができる。たとえば、west.siroe.com と siroe.com は、別々の組織サブツリーにマップされます。これにより、各サブツリー内に同じ UID を持つユーザエントリを作成できる
既存の DIT を iPlanet Messaging Server にマッピングする
二重ツリー機構を使うと、既存の DIT を iPlanet Messaging Server にマッピングできます。次の図にこの様子を示します。この図は、iPlanet Messaging Server 内の DC ツリーにマップされた既存の NMS DIT (o=siroe.com) を示しています。このプロセスの詳細は、『iPlanet Messaging Server 移行ガイド』に記載されています。
図 1-2    既存の DIT の iPlanet Messaging Server へのマッピングの例
  
アクセス制御のためのデータのパーティション化
二重ツリー機構は、各パーティション内でのデータのパーティション化とアクセス制御を提供します。この機能は、あるカスタマが同じディレクトリツリー内に格納された他のカスタマに関するデータにアクセスできないという厳しい要件に対応できるため、マルチテナントディレクトリにおいて重要です。データのパーティション化とアクセス制御により、個々のカスタマ組織に安全な方法でアプリケーションのアウトソーシングを提供することができます。その際、各組織のユーザやグループのデータを、他の組織のデータと分けて格納できます。iPlanet Delegated Administrator for Messaging は、このタイプのアプリケーションの一例です。そのため、アウトソーシングを受けるメッセージングカスタマは、1 つの大きな DIT の中にある適切に定義されたサブツリー (一般的にはドメイン) 内に表現されます。このサブツリーは、そのカスタマに属するすべてのサービスデータを格納するために使用されます。図 1-3 に、この概念を示します。
図 1-3    TEST アクセス制御のためのデータのパーティション化の例
  
サブドメイン用の個別のネームスペースの提供
二重ツリー機構は、サブドメイン用に個別のネームスペースを提供します。これにより、サブドメイン内で同じログイン名を使用することができます。たとえば、jdoe@siroe.com と jdoe@west.siroe.com を、2 つの独立した有効な電子メールアドレスにすることができます。図 1-1 にこのことを示しています。
iPlanet Messaging Server データモデル
iPlanet Messaging Server オブジェクトクラスの基本データモデルは、コアオブジェクトクラスによって作成された LDAP エントリタイプ (ユーザ、グループ、ドメインなど) を共有クラス (複数のサービスで共有できるオブジェクトクラス) およびサービス固有のオブジェクトクラス (特定のタイプのサーバに固有のクラス) でオーバーレイすることによって LDAP エントリタイプを拡張します。この関係を次の表に示します。
表 1-1    エントリタイプと対応するオブジェクトクラス
共有クラス
Messaging Server のクラス
inetMailGroup、inetLocalRecipient、inetMailGroupManagement、nsManagedMailList
たとえば電子メールユーザタイプを使う場合、各オブジェクトクラスは、それぞれ次の属性を提供します。
organizationalPerson は、組織に属するユーザを説明するための属性を提供します。
inetOrgPerson は、基本的なインターネットユーザの属性を提供します。
ipUser は、個人アドレス帳属性、サービスクラステンプレート、さらに該当する場合はファミリーアカウントの DN を保持します。
inetUser はユーザアカウントを表します。このクラスは、inetMailUser や ipUser と共にメールアカウントを作成するために使用されます。
inetSubscriber は、加入者アカウントを表すオプションのオブジェクトクラスです。このクラスは、アカウント ID および challenge/response 属性を提供します。
inetMailUser は、メールアカウントを表し、ユーザ固有のメールアカウント属性の大半を提供します。
inetLocalMailRecipient は、ローカル (組織内) の電子メール受信者を表します。このクラスは、受信者の電子メールアドレスを指定し、受信者に関するルーティング情報を提供します。
ACI アーキテクチャ
アクセスコントロール情報指示 (Access Control Information instructions、AIC) は、ディレクトリに対するユーザのアクセスを制御します。Messaging Server のユーザにはいくつかタイプがあり、必要とするディレクトリアクセスのレベルはタイプごとに異なります。これらのユーザタイプの一部を次に示します。
通常の電子メールユーザ: このタイプのユーザは、単に電子メールを送受信し、パスワードの変更や Vacation モードの開始のための権限を必要とします。
これらの各ユーザタイプには、DC ツリーおよび組織ツリーのルートまたはドメインレベルで特定の ACI が割り当てられます (図 1-4 を参照)。各ユーザに対してではなく、ルートやドメインエントリ内で ACI を割り当てることにより、アクセス範囲をドメインまたはシステム全体に設定できます。ルートノード上で指定された ACI は、システム全体のエントリに適用されます。ドメイン内で指定された ACI は、そのドメイン内のエントリにのみ適用されます。(ACI 情報の詳細については、『iPlanet Directory Server 管理ガイド』を参照)。トップレベル管理者: ディレクトリ内のすべてのエントリに対してすべての処理を実行する権限を持ちます。
メッセージストア管理者: システムまたはドメインのメールボックスの表示や、メッセージストアの管理を実行する権限を持ちます。
ドメイン管理者: ドメイン内のメールユーザ、メーリングリスト、およびファミリーアカウントのエントリの作成、変更、削除を行うことができます。
さまざまな管理者用の ACI は、特定のグループ上で与えられます。管理者を作成するには、単にユーザをグループに追加し、そのユーザエントリにグループバックポインタ属性 (memberof) を追加します。たとえば、インストール時には、cn=Domain Administrators, ou=groups, <ドメインの DN> というグループが特定の ACI 権限を使って作成されます。ドメイン管理者を作成するには、単にユーザをそのグループに追加し、そのユーザのエントリに memberof 属性を追加します。
ファミリーグループ管理者を作成するには、ユーザをメーリングリスト
cn=Family Group Administrators, ou=groups, <ドメインの DN> に追加します。詳しい管理者の作成手順については、第 6 章「Messaging Server 管理者のプロビジョニング」を参照してください。たとえば、以下に示す構成内では、次のエントリ内で ACI が指定されます。
o=isp
o=sesta.com,o=isp
o=siroe.com,o=isp
o=internet
dc=siroe, dc=com, o=internet
dc=sesta, dc=com, o=internet図 1-4 に、ドメインとルートエントリノード用にインストールされる ACI を示します。
図 1-4    ACI の例
  
サービスクラス
サービスクラス (COS) 機能を使用すると、指定したユーザに適用できる固定された機能と属性のセットを名前付きで作成できます。さらに、単一の属性を持つユーザエントリに与えることができる属性のテンプレートを作成できます。たとえば、ISP を運用している場合、Hall of Fame および All-Star という名前で、2 つのレベルのメールサービスを作成することが考えられます。この場合、Hall of Fame サービスクラスでは、IMAP、セキュア IMAP、POP3、および HTTP (Web メール) メールサービスに加え、5G バイトのメッセージストアのディスク容量をユーザに提供できます。All-Star サービスクラスでは、POP3 メールサービスと 5G バイトのメッセージストアのディスク容量を提供できます。
注 サービスクラスで定義された属性を参照するフィルタを含む LDAP 検索要求は実行されません。たとえば、mailquota がサービスクラステンプレート内だけに定義され、ユーザエントリ内に定義されていない場合は、属性 mailquota に関する検索は正常に実行できません。サーバは、そのような要求が出されると、「実行されません」エラーメッセージを返します。
iPlanet Messaging Server のサービスクラスの設定
サービスクラス機能を追加するための基本的な手順は次のとおりです。
slapd.ldbm.conf に COS プラグインを追加します。
これらの手順の詳細は、次の Web サイトに記載されています。COS メールスキーマのエントリを作成します。COS メールスキーマは次の項目を定義します。
サービスクラステンプレートのエントリを作成します。
http://docs.iplanet.com/docs/manuals/deladmin/45/html/06_cos.htm#25217
次の節では、iPlanet Messaging Server サービスクラスに関する具体的な問題と例について説明します。サービスクラス機能をシステムに実装する際の「COS スキーマの管理」の手順では、次のパラメータ値を使用してください。
表 1-2    iPlanet Messaging Server サービスクラスのパラメータ値
パラメータ
値
サービスクラスの例
前の節で説明した例を使用し、sesta.com というホストドメイン用に、Hall of Fame および All-Star という名前を持つメールサービス用のサービスクラスを作成します。Hall of Fame サービスクラスでは、IMAP、セキュア IMAP、POP3、および HTTP (Web メール) メールサービスに加え、5G バイトのメッセージストアのディスク容量をユーザに提供します。All-Star サービスクラスでは、POP3 メールサービスと 5G バイトのメッセージストアのディスク容量を提供できます。
Directory Server に COS プラグインをインストールしますDirectory Server 4.1 の場合は、次のサイトを参照してください。
http://home.netscape.com/eng/server/directory/DSRK/4.1/cos.htm
COS のクラスと定義用のコンテナを作成します。
- Directory Server 5.0 の場合は、次のサイトを参照してください。
http://docs.iplanet.com/docs/manuals/directory/51/html/cli/plugconfig.htm#16608
dn: ou=COS,o=sesta.com, o=isp objectclass: top objectclass: organizationalUnit ou: COS 次の LDIF エントリの例を使用して、メールスキーマエントリを作成します。
dn: uid=mail scheme,ou=COS,o=sesta.com, o=isp
クラス用のコンテナを作成します。objectclass: cosDefinition
cosTemplateDn: ou=MailSchemeTemplates,ou=COS,o=sesta.com, o=isp
cosTargetTree: ou=People,o=sesta.com, o=isp
cosSpecifier: inetCOS
cosAttribute: mailQuota
cosAttribute: mailAllowedServiceAccess
COS テンプレートエントリを作成します。
- Hall of Fame および All-Star テンプレートのそれぞれに対応する 2 つのテンプレートエントリ用の LDIF を以下に示します。
dn: ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp objectclass: top objectclass: organizationalunit ou: MailSchemeClasses
- Hall of Fame および All-Star テンプレートのそれぞれに対応する、2 つのテンプレートエントリ用の LDIF を以下に示します。
dn: cn=All-Star,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp objectclass: top objectclass: inetUser objectclass: inetMailUser mailQuota: 5000000 mailAllowedServiceAccess: +pop3:*
dn: cn=All-Star,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp
サービスクラステンプレートをユーザに追加します。
dn: cn=Hall of Fame,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=ispobjectclass: top
objectclass: inetUser
objectclass: inetMailUser
mailQuota: 5000000
mailAllowedServiceAccess: +pop3:*objectclass: top
objectclass: inetUser
objectclass: inetMailUser
mailQuota: 5000000
mailAllowedServiceAccess: +imap, imaps, pop3:*
前へ 目次 索引 DocHome 次へ
Copyright © 2000 Sun Microsystems, Inc.
最新更新日 2002 年 2 月 13 日