test

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

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

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

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 章「データベース移行ユーティリティー」を参照してください。