前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 プロビジョニングガイド



第 1 章   プロビジョニングの概念とテクノロジ


この章では、iPlanet Messaging Serverのプロビジョニングに関する概念とテクノロジを説明します。この章には、以下の節があります。



iPlanet Messaging Server のプロビジョニング

プロビジョニングとは、Directory Server 内の iPlanet Messaging Server ユーザ、メーリングリスト、システム管理者、ドメインの各エントリに関する追加、変更、削除を行うことです。Messaging Server は、必要に応じてディレクトリを照会することにより、これらの要素に関する情報を取得します。

iPlanet Messaging Server には、次の 4 つのプロビジョニングインタフェースがあります。

  • iPlanet Delegated Administrator for Messaging コンソール

  • iPlanet Delegated Administrator for Messaging コマンドラインユーティリティ

  • iPlanet Messaging Server 管理コンソール

  • Messaging Server LDAP ディレクトリ

このマニュアルでは、LDAP を使用してプロビジョニングを行う方法について説明します。他のプロビジョニング方法に触れる場合がありますが、このマニュアルでは、LDAP を使用したプロビジョニングを中心に説明します。



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 移行ガイド』に記載されています。


特定のドメインにメールを配信するには、そのドメインの MX レコードを DNS 内に含める必要があります。




2 つのディレクトリ情報ツリーが必要な理由

iPlanet Messaging Server は、構成情報およびユーザやグループのデータを含む単一の DC ツリーをサポートします。しかし、インストール時には、iPlanet Messaging Server は、DC ツリーと組織ツリーの両方を作成します。この二重ツリー機構は次の拡張機能を提供します。

  • 既存の DIT にマップする DC ツリーを作成することによって、iPlanet Messaging Server が既存のディレクトリを利用できる

  • 組織に特有のアクセス制御を行うために、データをパーティション化できる。つまり各組織は、ユーザとグループのエントリが置かれた DIT 内に個別のサブツリーを持つことができます。データにアクセスできるユーザを、そのサブツリーに含まれるユーザに制限できます。これにより、iPlanet Delegated Administrator for Messaging のようなローカライズされたアプリケーションを安全に稼動できる

  • サブドメイン用の個別のネームスペースを持つことができる。たとえば、west.siroe.comsiroe.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 のクラス

DC ツリーのドメイン  

domain、inetdomain  

 

mailDomain、nsManagedDomain、icsCalendarDomain  

組織ツリードメイン  

organization  

 

nsManagedDomain  

電子メールユーザ  

person、inetUser、organizationalPerson、
inetOrgPerson
 

ipUser、userPresenceProfile  

inetMailUser、inetLocalMailRecipient、nsManagedPerson  

グループ  

groupOfUniqueNames  

 

inetMailGroup、inetLocalRecipient、inetMailGroupManagement、nsManagedMailList  

ファミリーアカウント  

inetManagedGroup  

 

nsManagedDept  

たとえば電子メールユーザタイプを使う場合、各オブジェクトクラスは、それぞれ次の属性を提供します。

Person は、ユーザを説明するための属性を提供します。

organizationalPerson は、組織に属するユーザを説明するための属性を提供します。

inetOrgPerson は、基本的なインターネットユーザの属性を提供します。

ipUser は、個人アドレス帳属性、サービスクラステンプレート、さらに該当する場合はファミリーアカウントの DN を保持します。

inetUser はユーザアカウントを表します。このクラスは、inetMailUseripUser と共にメールアカウントを作成するために使用されます。

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 のサービスクラスの設定

サービスクラス機能を追加するための基本的な手順は次のとおりです。

  1. slapd.ldbm.conf に COS プラグインを追加します。

  2. COS メールスキーマのエントリを作成します。COS メールスキーマは次の項目を定義します。

    • ディレクトリ内の COS テンプレート定義の場所

    • サービスクラスを適用できるユーザエントリを含むディレクトリ

    • ユーザエントリに適用されるサービスクラステンプレートを指定するために使用する属性 (inetCOS) の名前

    • テンプレート内で使用する属性のリスト

  3. サービスクラステンプレートのエントリを作成します。

  4. サービスクラスをユーザエントリに割り当てます。

これらの手順の詳細は、次の Web サイトに記載されています。

http://docs.iplanet.com/docs/manuals/deladmin/45/html/06_cos.htm#25217

次の節では、iPlanet Messaging Server サービスクラスに関する具体的な問題と例について説明します。サービスクラス機能をシステムに実装する際の「COS スキーマの管理」の手順では、次のパラメータ値を使用してください。

表 1-2    iPlanet Messaging Server サービスクラスのパラメータ値

パラメータ

サービスクラスのスキーマおよびテンプレート用のコンテナの DN  

ou=COS, <ドメインの DN>  

メールスキーマエントリの DN  

cn=mail scheme, ou=COS, <ドメインの DN>  

サービスクラスコンテナの DN (cosTemplateDn)  

ou=MailSchemeTemplates,ou=COS,<ドメインの DN>  

サービスクラスをエントリに割り当てるための属性 (cosSpecifier)  

inetCOS  


サービスクラスの例

前の節で説明した例を使用し、sesta.com というホストドメイン用に、Hall of Fame および All-Star という名前を持つメールサービス用のサービスクラスを作成します。Hall of Fame サービスクラスでは、IMAP、セキュア IMAP、POP3、および HTTP (Web メール) メールサービスに加え、5G バイトのメッセージストアのディスク容量をユーザに提供します。All-Star サービスクラスでは、POP3 メールサービスと 5G バイトのメッセージストアのディスク容量を提供できます。

  1. Directory Server に COS プラグインをインストールしますDirectory Server 4.1 の場合は、次のサイトを参照してください。
    http://home.netscape.com/eng/server/directory/DSRK/4.1/cos.htm

    Directory Server 5.0 の場合は、次のサイトを参照してください。
    http://docs.iplanet.com/docs/manuals/directory/51/html/cli/plugconfig.htm#16608

  2. COS のクラスと定義用のコンテナを作成します。

    dn: ou=COS,o=sesta.com, o=isp
    objectclass: top
    objectclass: organizationalUnit
    ou: COS

  3. 次の LDIF エントリの例を使用して、メールスキーマエントリを作成します。

    dn: uid=mail scheme,ou=COS,o=sesta.com, o=isp
    objectclass: top
    objectclass: cosDefinition
    cosTemplateDn: ou=MailSchemeTemplates,ou=COS,o=sesta.com, o=isp
    cosTargetTree: o=sesta.com, o=isp
    cosSpecifier: inetCOS
    cosAttribute: mailQuota
    cosAttribute: mailAllowedServiceAccess

    • dn: uid=mail scheme,ou=COS,o=sesta.com, o=isp

      COS メールスキーマエントリの DN

    • objectclass: cosDefinition

      サービスクラススキーマのエントリを定義するオブジェクトクラス

    • cosTemplateDn: ou=MailSchemeTemplates,ou=COS,o=sesta.com, o=isp

      このスキーマの COS テンプレートエントリが格納されるサブツリーを含む複数値の属性

    • cosTargetTree: ou=People,o=sesta.com, o=isp

      COS スキーマが適用されるサブツリーを含む複数値の属性

    • cosSpecifier: inetCOS

      ユーザエントリに適用されるサービスクラステンプレートを指定するために使用する属性の名前

    • cosAttribute: mailQuota
      cosAttribute: mailAllowedServiceAccess

      テンプレートエントリ内で使用される属性

  4. クラス用のコンテナを作成します。

    Hall of Fame および All-Star テンプレートのそれぞれに対応する 2 つのテンプレートエントリ用の LDIF を以下に示します。

    dn: ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp
    objectclass: top
    objectclass: organizationalunit
    ou: MailSchemeClasses

  5. COS テンプレートエントリを作成します。

    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=Hall of Fame,ou=MailSchemeClasses,ou=COS,o=sesta.com, o=isp
    objectclass: top
    objectclass: inetUser
    objectclass: inetMailUser
    mailQuota: 5000000000
    mailAllowedServiceAccess: +imap, imaps, pop3, http:*

    • 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=isp

      COS テンプレートの DN

    • objectclass: top
      objectclass: inetUser
      objectclass: inetMailUser
      mailQuota: 5000000
      mailAllowedServiceAccess: +pop3:*

      All-Star テンプレート内の属性とオブジェクトクラス

    • objectclass: top
      objectclass: inetUser
      objectclass: inetMailUser
      mailQuota: 5000000
      mailAllowedServiceAccess: +imap, imaps, pop3:*

      Hall of Fame テンプレート内の属性とオブジェクトクラス

  6. サービスクラステンプレートをユーザに追加します。

    dn: uid=Havlicek,ou=People,o=sesta.com, o=isp
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: inetUser
    objectClass: ipUser
    objectClass: userPresenceProfile
    objectClass: inetMailUser
    objectClass: inetLocalMailRecipient
    cn: John Havlicek
    sn: Havlicek
    initials: JH
    givenName: John
    mail: john.havlicek@sesta.com
    mailAlternateAddress: Havlicek@sesta.com
    mailHost: mail.siroe.com
    uid: Havlicek
    dataSource: iPlanet Messaging Server
    userPassword: secret
    inetUserStatus: active
    mailUserStatus: active
    mailMsgQuota: 100
    inetCos: Hall of Fame

    dn: uid=Hornicek,ou=People,o=sesta.com, o=isp
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: inetUser
    objectClass: ipUser
    objectClass: userPresenceProfile
    objectClass: inetMailUser
    objectClass: inetLocalMailRecipient
    cn: Jeff Hornicek
    sn: Hornicek
    initials: JH
    givenName: Jeff
    mail: jeff.hornicek@sesta.com
    mailAlternateAddress: Hornicek@sesta.com
    mailDeliveryOption: mailbox
    mailHost: mail.siroe.com
    uid: Hornicek
    dataSource: iPlanet Messaging Server 5.0
    userPassword: secret
    inetUserStatus: active
    mailUserStatus: active
    mailMsgQuota: 100
    inetCos: All-Star


前へ     目次     索引     DocHome     次へ     
Copyright © 2000 Sun Microsystems, Inc.

最新更新日 2002 年 2 月 13 日