test

Sun Java System Calendar Server 6.3 管理ガイド

第 10 章 Calendar Server 6.3 の複数ドメイン環境の設定

この章では、はじめて複数ドメイン環境を設定する場合の概要と手順について説明します。

ヒント –

以前、複数ドメイン環境内のドメインは、ホストされたドメインや仮想ドメインと呼ばれていました。このマニュアルでは、これらの用語を同じ意味で使用します。

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

10.1 Calendar Server バージョン 6.3 での複数ドメインの概要

Calendar Server 6.3 では、ユーザーおよびグループ LDAP エントリをまとめるデフォルトかつ唯一の方法として、複数ドメインが用意されています。つまり、ルートノードの下に少なくとも 1 つのドメインを作成し、すべてのユーザーおよびグループエントリをドメインノードの下に置く必要があります。以前のバージョンの Calendar Server では、ドメインを使用してユーザーおよびグループエントリをまとめる方法はオプションになっていました。ドメインをまったく使用せずに Calendar Server を実行できました。これは Calendar Server 6.3 には当てはまらず、少なくとも 1 つの (デフォルト) ドメインが必要になります。

複数ドメイン環境では、各ドメインが Calendar Server システムの同一のインスタンスを共有します。このため、単一のサーバーに複数のドメインを配備できます。各ドメインはネームスペースを定義し、1 つのネームスペースではすべてのユーザー、グループ、リソースが一意です。各ドメインには、変更可能な属性とユーザー設定もあります。ドメインのすべてのユーザー ID とカレンダ ID は完全修飾名にする必要があります。

設定プログラムでは、デフォルトドメインの設定に必要な情報を入力するように求められます。設定プログラムが終了し、必要なドメインをすべて作成し終えたら、ユーザーおよびグループ LDAP エントリを適切なドメインにコピーする前に、移行ユーティリティーを実行し非ドメイン ユーザーおよびグループ LDAP エントリをドメイン対応のユーザーおよびグループエントリに変換して、ユーザーおよびグループエントリを準備する必要があります。実行するユーティリティーは csmig と csvdmig です。

非ドメインバージョンの Calendar Server から Calendar Server 6.3 にアップグレードする場合は、次の選択肢があります。

現在のバージョンにアップグレードする前にホストされた (複数) ドメインを設定していた場合、ユーザー ID とカレンダ ID を変更する必要はありません。ただし、次の節で示すように、ics.conf の新しいパラメータの中には設定する必要のあるものもあります。「10.4 Calendar Server バージョン 6.3 の複数ドメインモードで必要な追加パラメータ」。

注意 – 注意 –

単一マシン上で複数の Calendar Server インスタンスを使用するように現在のサイトを設定していたり、限定的な仮想ドメインモードを実装している場合は、移行要件の評価について購入先の顧客サービスの担当者に問い合わせてください。

10.2 はじめての Calendar Server バージョン 6.3 の複数ドメイン環境の設定

非ドメイン環境や単一ドメイン環境から複数ドメイン環境に移行するには、LDAP エントリを作成する前に次の作業を実行する必要があります。

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

    Calendar Server バージョン 5 から移行する場合は、複数ドメインを設定する前に、必ず csmig、csvdmig、cs5migrate、および cs5migrate をあらかじめ実行しておいてください。これらの移行ユーティリティーについては、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」を参照してください。

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

  3. 設定を変更する権限を持つ管理者としてログインします。

  4. stop-cal コマンドを発行して Calendar Server サービスを停止します。

  5. ics.conf ファイルを編集して、複数ドメインを有効にします。

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

    パラメータ 

    説明 

    service.virtualdomain.support

    複数ドメインのサポートを有効にします ("yes")。デフォルトは "yes" です。

    注 –

    単一ドメインで運用する予定の場合でも、このパラメータを "no" に変更しないでください。現在のバージョンの Calendar Server では、これが "yes" になっている必要があります。

    local.schemaversion

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

    service.dcroot

    複数ドメインのサポートの場合、これが local.ugldapbasedn と local.authldapbasedn に置き換わります。

    local.schemaversion="1" または local.schemaversion="1.5" の場合、すべてのドメインを下に抱えた DC ツリーのルートサフィックスを指定します。

    例: "o=internet"

    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" (英語) です。

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

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

    Schema バージョン 1 では、DC ツリーの構造に応じて、デフォルトドメイン (複数ドメインのいずれか 1 つ) を作成し、DC ツリーのルートサフィックスより 1 つ以上下のレベルに配置します。たとえば、ルートサフィックスが o=internet の場合、「10.3.3 Calendar Server バージョン 6.3 の 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

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

    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

  8. システムで必要な数だけドメインを作成します。

    Schema バージョン 2 モードでドメインを追加する手順については、「13.2 新規の Calendar Server ドメインの作成」を参照してください。

    Schema バージョン 1 のドメインを作成するには、次の例に示すように、csdomain create を使用します。

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

  9. 新しいドメインのカレンダ (必要に応じてメール) サービスを追加します。

  10. 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

  11. 以前の非ドメイン環境 (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

      管理者のグループエントリをドメインに移動する必要はありません。

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

10.3 Calendar Server バージョン 6.3 の複数ドメイン機能によるスキーマ選択への影響

ここでは、複数ドメインを実装するプロセスと、スキーマバージョンの選択に及ぼすその影響を十分に理解するために役立つ概念情報について説明します。

この項の内容は次のとおりです。

10.3.1 複数ドメインの概要と Calendar Server バージョン 6.3 のスキーマ選択への影響

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

Calendar Server は、Schema バージョン 1 と Schema バージョン 2 の両方の LDAP ディレクトリスキーマバージョンをサポートしています。Directory Server セットアップスクリプト(comm_dssetup.pl) を実行するときに、LDAP Schema バージョン 1 または LDAP Schema バージョン 2 のいずれかを選択できます。Schema バージョン 1 を使用する特別な理由がないかぎり、Schema バージョン 2 を使用してください。

Schema バージョン 1 を使用する場合には次の 2 つがあります。

10.3.2 Calendar Server バージョン 6.3 の Sun LDAP Schema バージョン 2

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

図 10–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 互換モードです。

10.3.3 Calendar Server バージョン 6.3 の Sun LDAP Schema バージョン 1

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

この構造には、ドメイン管理のための 2 つのツリーが含まれます。

図 10–2 LDAP Schema バージョン 1 を使用する場合の LDAP ディレクトリの構造

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

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

注 –

以前の LDAP 設定に DC ツリーが含まれていなかった場合、Schema バージョン 1 モードまたは Schema バージョン 2 互換モードを使用するには、「10.2 はじめての Calendar Server バージョン 6.3 の複数ドメイン環境の設定」の説明に従ってユーザー自身が DC ツリーノードを作成する必要があります。ただし、Schema バージョン 2 が推奨のモードです。

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

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

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

10.4 Calendar Server バージョン 6.3 の複数ドメインモードで必要な追加パラメータ

Calendar Server 6 以降、すべての配備が複数ドメインに合わせて設定されています。これ以前のバージョンの Calendar Server からアップグレードする場合、ホストされた (複数) ドメインを設定していないときには、次のように、スキーマモードに合わせてパラメータを追加する必要があります。

10.4.1 Calendar Server バージョン 6.3 の Schema バージョン 1 パラメータの追加

次のパラメータがまだ存在していない場合は、設定ファイル (ics.conf) に追加してください。

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support ("yes" に設定)

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion ("1" に設定)

10.4.2 Calendar Server バージョン 6.3 の Schema バージョン 2 パラメータの追加

次のパラメータがまだ存在していない場合は、設定ファイル (ics.conf) に追加してください。

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support ("yes" に設定)

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion ("2" に設定)

service.schema2root

10.5 Calendar Server 6.3 へのログイン

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

userid[@domain-name]

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

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

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

10.6 Calendar Server バージョン 6.3 での非ドメイン環境からの移行

Calendar Server バージョン 5.0 以前では、ドメインはありませんでした。したがって、ユーザー ID とカレンダ ID は完全修飾名である必要はありませんでした。つまり、jdoe@domain.com のように ID にドメイン名を含める必要はありませんでした。現バージョンの Calendar Server をインストールするまで、uid と calid が完全修飾名でなかった場合、データを変更する必要はありません。システムでは、完全修飾名ではない uid と calid が見つかった場合、デフォルトドメインに属するものと想定します。ただし、複数ドメインを実装する場合は、各ユーザーがどのドメインに所属するかを示すために、LDAP とコンポーネントデータベースを移行する必要があります。

さらに、別の方法でデータを移行する必要が生じる場合もあります。移行プログラムは複数あります。移行については、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」を参照してください。