ここでは、ホストされたドメインの概要について、次の項目を説明します。
ホストされたドメインのインストールでは、LDAP ディレクトリは完全に区別され、部分的な交差もありません。 それぞれの LDAP ディレクトリが DNS (ドメイン名システム) 内のドメインを表します。ユーザー、グループおよびリソースの uid は各ドメイン内で一意です。たとえば、uid が jdoe のユーザーは各ドメインで 1 人だけです。識別名 (DN) は、各ドメインのルートを表します。
Calendar Server は、ホストされたドメインで次の両方の LDAP ディレクトリスキーマバージョンをサポートしています。
「Sun LDAP Schema 2」 (互換モードまたはネイティブモード)
Directory Server セットアップスクリプト (comm_dssetup.pl) を実行するときに、LDAP Schema 1 または LDAP Schema 2 のいずれかを選択できます。 次の点に注意してください。
新規インストール: Calendar Server を新規インストールとしてサイトにインストールする場合は、LDAP Schema 2 を使用します。
アップグレード: Calendar Server バージョン 5 からのアップグレードでは、スキーマバージョンを次のように選択します。
シングルサインオン (SSO) などの Access Manager 機能を使用する場合、または Delegated Administrator を使用する場合は、LDAP Schema 2 を選択します。
ホストされたドメインがない、Access Manager 機能を使用しない、または Delegated Administrator によるユーザーのプロビジョニングを行わない場合は、どちらのスキーマバージョンも使用できます。ただし、可能であれば LDAP Schema 2 を使用します。
次の図は、Sun LDAP Schema 2 を使用する、ホストされたドメインのインストールでの LDAP ディレクトリ構造を示しています。
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 を使用するホストされたドメインのインストールに対する LDAP ディレクトリ構造の例を示しています。
この構造には、ドメイン管理のための 2 つのツリーが含まれます。DC ツリーと組織ツリー (OSI) です。
DC ツリー
組織 (OSI) ツリー
DC ツリー (ノード) は、指定したドメイン名からドメインエントリを決定する DNS に似ています。LDAP 属性 inetdomainbasedn は、ベース DN をポイントします。ベース DN は、組織 ツリー (ノード) 内のドメインのユーザー、リソース、およびグループのルートです。各ドメインでは、Calendar Server のユーザー、リソース、グループの ID は一意である必要があります。
以前の LDAP 設定に DC ツリーが含まれていなかった場合、Schema 1 モードまたは Schema 2 互換モードを使用するためには、「ホストされたドメイン環境の設定」の説明に従ってユーザー自身が DC ツリーノードを作成する必要があります。
LDAP Schema 1 を使用する、ホストされたドメインのインストールでは、ディレクトリ検索でエントリを特定するために次の 2 つの手順が必要です。
DC ツリーで検索を行い、組織ツリー内のドメインのベース DN (inetDomainBaseDN 属性) をポイントする DN 値を持つドメインエントリを特定します。
組織ツリーで検索を行ってドメインエントリを特定し、そのエントリのベース DN に基づいてドメイン内のユーザー、リソース、またはグループを特定します。
ホストされたドメインのインストールでは、各ユーザーはそのドメイン内で一意のユーザー ID (uid) を持つ必要があります。Calendar Server へのログインは、次の形式で行います。
userid[@domain-name]
domain-name を省略すると、ics.conf ファイルの service.defaultdomain パラメータに設定されているデフォルトドメイン名が適用されます。このため、ユーザーは userid を指定するだけでデフォルトドメインにログインできます。
ホストされていないドメイン環境でのインストールでは、domain-name は不要です。ドメイン名を指定しても無視されます。
自動プロビジョニングが有効になっている場合、ユーザーが最初にログインしたときに Calendar Server はそのユーザーのデフォルトカレンダを作成します。カレンダ作成については、第 15 章「カレンダの管理」を参照してください。
ログインの許可は、icsStatus 属性または icsAllowedServiceAccess 属性に基づいています。詳細は、「LDAP 属性とプロパティー名」を参照してください。
デフォルトでは、ユーザーが検索し、予定への出席を依頼できるユーザーやグループは、各自のドメイン内のユーザーとグループに限定されています。ドメイン間の検索機能を利用することで、あるドメインのユーザーがほかのドメインのユーザーやグループを検索することができます。ただし、次の要件を満たしている必要があります。
各ドメインは、ほかのドメインからのドメイン間検索を許可または拒否するアクセス制御リスト (ACL) を icsExtendedDomainPrefs 属性の domainAccess プロパティーに指定することができる。このためドメインは、そのドメイン内の検索を特定のドメイン、またはすべてのドメインを対象に許可または拒否することができる。
domainAccess については、「LDAP 属性とプロパティー名」を参照してください。ACL の一般的な説明については、「アクセス制御リスト (ACL)」を参照してください。
各ドメインは、そのドメインのユーザーが検索できる外部ドメインを指定できる。ユーザーやグループを探すためにユーザーが検索する外部ドメインは、LDAP 属性 icsDomainNames によって決定される (外部ドメインの ACL が検索を許可している場合)。
たとえば、various.org ドメインの icsDomainNames に sesta.com と siroe.com が含まれる場合、various.org のユーザーは sesta.com と siroe.com に対するドメイン間検索を実行できます。icsDomainNames については、「LDAP 属性とプロパティー名」を参照してください。
ドメイン間検索を有効にする方法については、「ドメイン間の検索の有効化」を参照してください。
Calendar Server はホストされていないドメイン (つまり、シングルドメインを持つ) 環境での操作も引き続きサポートしています。たとえば、Calendar Server バージョン 5 以前の旧バージョンがインストールされている場合、ics.conf のパラメータ service.virtualdomain.support を "no" に設定すれば、シングルドメイン環境でも操作できます。「ホストされたドメインの有効化」も参照してください。
ただし、旧バージョンのコンポーネントデータベースを現在のバージョンに移行する必要があります。移行の詳細については、第 4 章「データベース移行ユーティリティー」を参照してください。