test

Sun Java System Calendar Server 6 2005Q4 管理ガイド

第 11 章 ホストされたドメインの設定

Calendar Server はホストされた (または仮想) ドメインをサポートしています。ホストされたドメインのインストールでは、各ドメインが Calendar Server の同じインスタンスを共有するため、1 つのサーバーに複数のドメインが存在できます。各ドメインはネームスペースを定義し、1 つのネームスペースではすべてのユーザー、グループ、リソースが一意です。各ドメインには、変更可能な属性とユーザー設定もあります。

この章で説明する内容は次のとおりです。

注 –

『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』では、ホストされたドメインを使用するためのインストール準備に必要なすべての手順を説明しています。

注意 – 注意 –

現在のサイトに複数の Calendar Server インスタンスが設定されていたり、限定的な仮想ドメインモードが設定されている場合は、移行要件の評価について購入先の顧客サービスの担当者に問い合わせてください。

ホストされたドメインの概要

ここでは、ホストされたドメインの概要について、次の項目を説明します。

LDAP ディレクトリの構造

ホストされたドメインのインストールでは、LDAP ディレクトリは完全に区別され、部分的な交差もありません。 それぞれの LDAP ディレクトリが DNS (ドメイン名システム) 内のドメインを表します。ユーザー、グループおよびリソースの uid は各ドメイン内で一意です。たとえば、uid が jdoe のユーザーは各ドメインで 1 人だけです。識別名 (DN) は、各ドメインのルートを表します。

Calendar Server は、ホストされたドメインで次の両方の LDAP ディレクトリスキーマバージョンをサポートしています。

Directory Server セットアップスクリプト (comm_dssetup.pl) を実行するときに、LDAP Schema 1 または LDAP Schema 2 のいずれかを選択できます。 次の点に注意してください。

Sun LDAP Schema 2

次の図は、Sun LDAP Schema 2 を使用する、ホストされたドメインのインストールでの LDAP ディレクトリ構造を示しています。

図 11–1 LDAP Schema 2 を使用する場合の LDAP ディレクトリの構造

この図は、1 つのツリー (組織ツリー) だけを使用し、DC ツリーのない純粋な Schema 2 環境の例を示しています。

LDAP Schema 2 ではフラットな LDAP ディレクトリ構造を使用します。つまり、ドメインはすべて同じレベルにあり、入れ子にはされません。ホストされたドメインのインストールでは、最初のレベルのエントリ (この図では varriusDomain、sestaDomain、および siroeDomain) がディレクトリ構造内で並列である必要があります。これらのエントリを入れ子にすることはできません。

シングルサインオン (SSO) などの Access Manager 機能を使用する場合、または Delegated Administrator を使用してユーザーをプロビジョニングする場合は、Schema 2 が必要です。ただし、複合型の形態として、DC ツリーと組織ツリーの両方を使用する 2 ツリースキーマも存在します。これは Schema 1 に似ていますが、Schema 2 のオブジェクトクラスと属性を使用します。これは、設定プログラム (csconfigurator.sh) では Schema 1.5 と呼ばれる Schema 2 互換モードです。

Sun LDAP Schema 1

次の図は、Sun LDAP Schema 1 を使用するホストされたドメインのインストールに対する LDAP ディレクトリ構造の例を示しています。

この構造には、ドメイン管理のための 2 つのツリーが含まれます。DC ツリーと組織ツリー (OSI) です。

図 11–2 LDAP Schema 1 を使用する場合の LDAP ディレクトリの構造

この図は、Schema 1、LDAP の 2 つのツリーからなる構造の例を示します。

DC ツリー (ノード) は、指定したドメイン名からドメインエントリを決定する DNS に似ています。LDAP 属性 inetdomainbasedn は、ベース DN をポイントします。ベース DN は、組織 ツリー (ノード) 内のドメインのユーザー、リソース、およびグループのルートです。各ドメインでは、Calendar Server のユーザー、リソース、グループの ID は一意である必要があります。

注 –

以前の LDAP 設定に DC ツリーが含まれていなかった場合、Schema 1 モードまたは Schema 2 互換モードを使用するためには、「ホストされたドメイン環境の設定」の説明に従ってユーザー自身が DC ツリーノードを作成する必要があります。

LDAP Schema 1 を使用する、ホストされたドメインのインストールでは、ディレクトリ検索でエントリを特定するために次の 2 つの手順が必要です。

  1. DC ツリーで検索を行い、組織ツリー内のドメインのベース DN (inetDomainBaseDN 属性) をポイントする DN 値を持つドメインエントリを特定します。

  2. 組織ツリーで検索を行ってドメインエントリを特定し、そのエントリのベース DN に基づいてドメイン内のユーザー、リソース、またはグループを特定します。

Calendar Server へのログイン

ホストされたドメインのインストールでは、各ユーザーはそのドメイン内で一意のユーザー ID (uid) を持つ必要があります。Calendar Server へのログインは、次の形式で行います。

userid[@domain-name]

domain-name を省略すると、ics.conf ファイルの service.defaultdomain パラメータに設定されているデフォルトドメイン名が適用されます。このため、ユーザーは userid を指定するだけでデフォルトドメインにログインできます。

ホストされていないドメイン環境でのインストールでは、domain-name は不要です。ドメイン名を指定しても無視されます。

自動プロビジョニングが有効になっている場合、ユーザーが最初にログインしたときに Calendar Server はそのユーザーのデフォルトカレンダを作成します。カレンダ作成については、第 15 章「カレンダの管理」を参照してください。

ログインの許可は、icsStatus 属性または icsAllowedServiceAccess 属性に基づいています。詳細は、「LDAP 属性とプロパティー名」を参照してください。

ドメイン間の検索

デフォルトでは、ユーザーが検索し、予定への出席を依頼できるユーザーやグループは、各自のドメイン内のユーザーとグループに限定されています。ドメイン間の検索機能を利用することで、あるドメインのユーザーがほかのドメインのユーザーやグループを検索することができます。ただし、次の要件を満たしている必要があります。

ドメイン間検索を有効にする方法については、「ドメイン間の検索の有効化」を参照してください。

ホストされていないドメイン環境のサポート

Calendar Server はホストされていないドメイン (つまり、シングルドメインを持つ) 環境での操作も引き続きサポートしています。たとえば、Calendar Server バージョン 5 以前の旧バージョンがインストールされている場合、ics.conf のパラメータ service.virtualdomain.support を "no" に設定すれば、シングルドメイン環境でも操作できます。「ホストされたドメインの有効化」も参照してください。

ただし、旧バージョンのコンポーネントデータベースを現在のバージョンに移行する必要があります。移行の詳細については、第 4 章「データベース移行ユーティリティー」を参照してください。

ホストされたドメイン環境の設定

ここでは、ホストされたドメインエントリを LDAP に新しく作成する前に実行しなければならない基本作業について説明します。

  1. データベース移行ユーティリティーを実行します。

    Calendar Server バージョン 5 から移行する場合、ホストされたドメインを設定する前に、cs5migrate、csmig、および csvdmig を実行済みであることを確認してください。Sun のテクニカルサポートから最新バージョンの cs5migrate を入手できます。これらの移行ユーティリティーについては、第 4 章「データベース移行ユーティリティー」を参照してください。

  2. 実行していない場合は、comm_dsseetup.pl を実行します。

    これにより、ホストされたドメインのサポートに必要なパラメータで、ics.conf ファイルが更新されます。

  3. ics.conf ファイルを編集して、ホストされたドメインを有効にします。

    次の表に、ホストされたドメインのサポートに使用される ics.conf ファイルの設定パラメータの一覧とその説明を示します。この表に示すパラメータのいずれかが ics.conf ファイルに含まれていない場合は、パラメータとそのパラメータに関連する値をファイルに追加し、変更を適用するために Calendar Server を再起動します。

    パラメータ 

    説明 

    service.virtualdomain.support

    ホストされた (仮想) ドメインモードのサポートを有効化 ("yes") または無効化 ("no") します。デフォルトは "no" です。

    local.schemaversion

    LDAP スキーマのバージョンを指定します。 

    service.dcroot

    local.schemaversion = 1 の場合に、LDAP ディレクトリの DC ツリーのルートサフィックスを指定します。

    例: "o=internet"

    ホストされた (仮想) ドメインモードでは、Calendar Server は service.dcroot パラメータを使用し、local.ugldapbasedn および local.authldapbasedn パラメータは使用されません。

    反対に、ホストされていない (仮想) ドメインモードでは、Calendar Server は local.ugldapbasedn および local.authldapbasedn パラメータを使用し、service.dcroot パラメータは使用されません。

    service.schema2root

    local.schemaversion = 2 の場合に、下にすべてのドメインが属するルートサフィックスを指定します。

    例: "o=sesta.com"

    service.defaultdomain

    Calendar Server のこのインスタンスのデフォルトドメインを指定します。ログイン時にドメイン名が指定されない場合は、このドメイン名が適用されます。 

    例: "red.sesta.com"

    service.loginseparator

    Calendar Server が "userid[login-separator ]domain" をパースするときに login-separator で使用される区切り文字を指定します。Calendar Server は各区切り文字を順に使用します。

    デフォルトは "@+" です。

    service.siteadmin.userid

    ドメイン管理者のユーザー ID を指定します。 

    例: DomainAdmin@sesta.com

    service.virtualdomain.scope

    ドメイン間検索を制御します。 

    • "primary": ユーザーがログインしているドメイン内だけの検索

    • "select": 検索が許可されている任意のドメインでの検索

      デフォルトは "select" です。

    local.domain.language

    ドメインの言語を指定します。デフォルトは "en" (英語) です。

  4. デフォルトドメインエントリを作成します。

    Schema 2 では、デフォルトドメインは Delegated Administrator 設定プログラム (config-commda) によって作成されます。

    Schema 1 では、DC ツリーの構造に応じて、デフォルトドメイン (ホストされたドメインのいずれか 1 つ) を DC ツリーのルートサフィックスより 1 つ以上下のレベルに作成します。たとえば、ルートサフィックスが o=internet である場合、「Sun LDAP Schema 1」に示すように、1 つ下のレベルのノードは com になります。ただし、デフォルトドメインは sesta.com など、さらに 1 ノード下になります。DC ツリーノードを作成する場合は、次の例に示すように、csdomain を実行します。

    csdomain -n o=com,dc=com,o=internet create comcsdomain
    -n o=sesta.com,dc=sesta,dc=com,o=internet create sesta.com

  5. デフォルトドメインエントリに対するカレンダサービスを有効にします。

    Schema 1 の場合: csattribute を使用して、LDAP の o=sesta.com ドメインエントリに、icsCalendarDomain オブジェクトクラスを追加します。

    Schema 2 の場合: Delegated Administrator の設定後、カレンダサービス (およびメールサービス) を追加するように、Delegated Administrator 設定プログラムで作成されたデフォルトドメインを変更します。次の例では、カレンダサービスとメールサービスがホストされたドメインに追加されます。

    commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail

  6. ホストされたドメインをシステムに必要なだけ作成します。

    Schema 2 モードでホストされたドメインを追加する方法については、「新規のホストされたドメインの作成」を参照してください。

    Schema 1 のホストされたドメインを作成するには、次の例に示すように、csdomain create を使用します。

    csdomain -n o=red.sesta.com,dc=red,dc=sesta,dc=com 
   create red.sesta.com

  7. 「ホストされたドメイン環境の設定」の説明に従って、ホストされた新規ドメインに対するカレンダサービスを有効にします。

  8. calmaster サイト管理者ユーザーが存在しない場合、作成します。

    Schema 2 では、次の例に示すように commadmin user create コマンドを使用して calmaster ユーザーを作成します。

    commadmin user create -D admin -w passwd -F Calendar
    -L Administrator -l calmaster -W calmasterpasswd -d sesta.com -S cal
    注 –

    Delegated Administrator コンソールの「新規ユーザー」ウィザードを使用して calmaster を作成する方法については、Delegated Administrator オンラインヘルプを参照してください。

    Schema 1 では、次の例に示すように、csuser を使用して calmaster ユーザーを組織ツリー上に作成します。

    csuser o=sesta.com,o=rootsuffix -d sesta.com
    -g Calendar -s Administrator -ycalmasterpasswordcreate calmaster

  9. 以前のホストされていないドメイン環境 (Schema 1) に calmaster サイト管理者ユーザーがすでにある場合は、次の手順を実行して、その管理者ユーザーをデフォルトドメインに移動します。

    1. 既存の calmaster LDAP エントリの LDAP ダンプを実行して、/tmp/calmaster.ldif などの一時ファイルに保存します。

    2. 次のように、ldapdelete を使用して、組織ツリーのルートサフィックス上の既存の calmaster LDAP エントリを削除します。

      #ldapdelete -D "cn=Directory Manager" -w password 
   uid=calmaster,ou=People,o=rootsuffix

    3. 次の LDIF の例に示すように、カレンダ管理者のグループエントリを変更 (uniqueMember 属性を更新) して変更内容を反映させます。


      dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix
changetype:modifyreplace:uniqueMember 
uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix

      グループエントリをホストされたドメインに移動する必要はありません。

  10. WCAP コマンドの calid が完全修飾名で指定されるように、管理スクリプトを更新します。つまり、各 calid にドメイン名を含める必要があります。例: jsmith@sesta.com

Messaging Server を利用して作成したドメインの使用

Messaging Server が、ホストされたドメインをすでに作成している場合は、Schema 1 または Schema 2 のいずれかに対してカレンダを有効にすることができます。 ここで説明する内容は次のとおりです。

Schema 1 メッセージングドメインでのカレンダ管理を有効にする

ドメインでカレンダ管理を有効にするには、カレンダを有効にする各ドメインに対して、次のオブジェクトクラスと 2 つの属性を LDAP ドメインエントリに追加します。

これは 2 つの方法で行うことができます。csattribute add コマンドを使用するか、次の例に示すように ldapmodify を使用します。


dn:dc=sesta,dc=com,o=internet
 changetype:modify
 add:objectclass
 objectClass:icsCalendarDomain
 add:icsStatus
 icsStatus:active
 add:icsExtendedDomainPrefs
 icsExtendedDomainPrefs:domainAccess=@@d^a^slfrwd^g;anonymous^a^r^g;@^a^s^g

Schema 2 メッセージングドメインでのカレンダ管理を有効にする

commdirmig を使用して既存の Messaging Server LDAP エントリを Schema 2 にすでに移行しているか、Messaging Server LDAP エントリを Schema 2 モードで独自に作成した場合は、次の 2 つの手順でカレンダ管理を有効にします。

  1. Delegated Administrator ユーティリティーの commadmin domain modify コマンドに -S オプションを指定して実行し、カレンダサービスを各ドメインに追加します。

    または、Delegated Administrator コンソールを使用して、カレンダサービスを含むサービスパッケージを、影響を受けるドメインに割り当てます。これを行うには、「組織」一覧ページの「サービスパッケージを割り当て」ボタンを使用します。

  2. Delegated Administrator ユーティリティーの commadmin user modify コマンドに -S オプションを指定して実行し、カレンダを有効にした各ドメインの各ユーザーにカレンダサービスを追加します。

    または、Delegated Administrator コンソールを使用して、カレンダサービスを含むサービスパッケージを、影響を受けるドメインの各ユーザーに割り当てます。これを行うには、影響を受ける各組織で、「ユーザー」一覧ページの「サービスパッケージを割り当て」ボタンを使用します。

commadmin コマンドについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。

Delegated Administrator コンソールについては、コンソールのオンラインヘルプを参照してください。

commdirmig については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。