Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Calendar Server 管理ガイド 

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

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

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

 


『Sun Java System Calendar Server 配備計画ガイド』 (http://docs.sun.com/db/prod/entsys?l=ja) では、ホストされたドメインを使用するためのインストール準備に必要なすべての手順を説明しています。



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

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

LDAP ディレクトリの構造

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

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


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

  • 新規インストール : Calendar Server 6 2004Q2 を新規インストールとしてサイトにインストールする場合は、LDAP Schema 2 を使用します。
  • アップグレード : Calendar Server 5.x からのアップグレードでは、スキーマバージョンを次のように選択します。
    • commadmin ユーティリティやシングルサインオン (SSO) など、Identity Server の機能を利用する場合は、LDAP Schema 2 を選択します。
    • Identity Server の機能を必要としない場合はどちらのバージョンも利用できます。ただし、可能であれば LDAP Schema 2 を使用します。

Sun LDAP Schema 2

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

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

Sun ONE LDAP Schema v.2 を使用する、ホストされたドメインのインストールでの LDAP ディレクトリの構造

 

LDAP Schema 2 の LDAP ディレクトリの構造はフラットです。ホストされたドメインのインストールでは、最初のレベルのエントリ (この図では varriusDomainsestaDomainsiroeDomain) がディレクトリ構造内で並列である必要があります。これらのエントリを入れ子にすることはできません。

ユーザー管理ユーティリティ (commadmin) やシングルサインオン (SSO) など、Identity Server の機能を利用する場合は、LDAP Schema 2 が必要です。

Sun LDAP Schema 1

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

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

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

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

  1. DC ツリーで検索を行い、OSI ツリー内のドメインのベース DN (inetDomainBaseDN 属性) をポイントする DN 値を持つドメインエントリを特定します。
  2. OSI ツリーで検索を行なってドメインエントリを特定し、そのエントリのベース DN に基づいてドメイン内のユーザー、リソース、またはグループを特定します。

Calendar Server へのログイン

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

userid[@domain-name]

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

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

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

ログインの許可は、icsStatus 属性または icsAllowedServiceAccess 属性に基づいています。詳細については、表 D-17 を参照してください。

ドメイン間の検索

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

LDAP 属性 icsDomainNames および icsExtendedDomainPrefs を設定するには、Calendar Server の csdomain ユーティリティを使用します。ドメインの LDAP 属性を csdomain (または commadminldapmodify などのユーティリティ) で追加または変更したときは、新しい値が適用されるように Calendar Server を再起動します。

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

Calendar Server はホストされていないドメイン (つまり、シングルドメインを持つ) 環境での操作も引き続きサポートしています。たとえば、Calendar Server 5.x 以前の旧バージョンをインストールしている場合、シングルドメイン環境でも操作できます。

この場合、ics.conf ファイルで次のパラメータを no に設定します。

service.virtualdomain.support = "no"

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


ホストされたドメイン環境への移行

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


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

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

Schema 1 でのカレンダー管理を有効にする

ドメインに対するカレンダー管理を有効にするには、次の作業を実行します。

  1. Calendar Server ユーザーに対して有効にする各ドメインの LDAP エントリに icsCalendarDomain オブジェクトクラスを追加します。
  2. 手順 1 で有効にした各ドメインで、icsStatus の属性値を "active" に設定します。
  3. 手順 1 で有効にした各ドメインで、icsExtendedDomainPrefs 属性のアクセス制御に使用するオプション domainAccess の値を ACL に設定します。
  4. これを実行するには、csattribute add コマンドを使用することも、コード例 5-1 に示すように ldapmodify を使用することもできます。

    コード例 5-1 ドメインの LDAP エントリの変更

    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

  5. カレンダーシステムごとにドメインレベルの管理者が必要な場合は、適切なアクセス制御を追加して、各ドメインに calmaster ユーザーを追加します。
  6. 有効にしたドメインごとに、csuer enable コマンドを使用して、既存のすべてのユーザーに対してもカレンダーを有効にする必要があります。

csattribute ユーティリティと csuser ユーティリティの使用方法については、付録 D 「Calendar Server のコマンド行ユーティリティのリファレンス」を参照してください。

Schema 2 でのカレンダー管理を有効にする

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

  1. commadmin domain modify コマンドを -S オプション付きで使用して、ドメインにカレンダーサービスを追加します。
  2. commadmin user modify コマンドを -S オプション付きで使用して、カレンダーサービスを割り当てることによって影響を受けたドメインの各ユーザーを有効にします。

commadmin コマンドの詳細については、『Sun Java System Communications Services User Management Utility Administration Guide』を参照してください。

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



前へ      目次      索引      次へ     


Copyright 2004 Sun Microsystems, Inc. All rights reserved.