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 は各ドメイン内で一意です。たとえば、uid が jdoe のユーザーは各ドメインで 1 人だけです。識別名 (DN) は、各ドメインのルートを表わします。
Calendar Server は、ホストされたドメインで次の両方の LDAP ディレクトリスキーマバージョンをサポートしています。
- Sun LDAP Schema 2 (互換モードまたはネイティブモード)
注
Directory Server セットアップスクリプト (comm_dssetup.pl) を実行するときに、LDAP Schema 1 または LDAP Schema 2 のいずれかを選択できます。次の点に注意してください。
Sun LDAP Schema 2
図 5-1 は、Sun LDAP Schema 2 を使用する、ホストされたドメインのインストールでの LDAP ディレクトリ構造を示しています。
図 5-1 LDAP Schema 2 を使用する場合の LDAP ディレクトリの構造
LDAP Schema 2 の LDAP ディレクトリの構造はフラットです。ホストされたドメインのインストールでは、最初のレベルのエントリ (この図では varriusDomain、sestaDomain、siroeDomain) がディレクトリ構造内で並列である必要があります。これらのエントリを入れ子にすることはできません。
ユーザー管理ユーティリティ (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 つの手順が必要です。
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 を参照してください。
ドメイン間の検索
デフォルトでは、ユーザーが検索し、予定に招待できるユーザーやグループは、各自のドメイン内のユーザーとグループに限定されています。ドメイン間の検索機能を利用することで、あるドメインのユーザーが他のドメインのユーザーやグループを検索することができます。ただし、次の要件を満たしている必要があります。
- 各ドメインは、他のドメインからのドメイン間検索を許可または拒否するアクセス制御リスト (ACL) を icsExtendedDomainPrefs 属性の domainAccess プロパティに指定することができます。このためドメインは、そのドメイン内の検索を特定のドメイン、またはすべてのドメインを対象に許可または拒否することができます。domainAccess については、表 D-16 を参照してください。ACL の一般的な説明については、「アクセス制御リスト (ACL)」を参照してください。
- 各ドメインは、そのドメインのユーザーが検索できる外部ドメインを指定できます。ユーザーやグループを探すためにユーザーが検索する外部ドメインは、LDAP 属性 icsDomainNames によって決定されます (外部ドメインの ACL が検索を許可している必要があります)。たとえば、various.org ドメインの icsDomainNames に sesta.com と siroe.com が含まれる場合、various.org のユーザーは sesta.com と siroe.com に対するドメイン間検索を実行できます。icsDomainNames については、表 D-17 を参照してください。
LDAP 属性 icsDomainNames および icsExtendedDomainPrefs を設定するには、Calendar Server の csdomain ユーティリティを使用します。ドメインの LDAP 属性を csdomain (または commadmin や ldapmodify などのユーティリティ) で追加または変更したときは、新しい値が適用されるように Calendar Server を再起動します。
ホストされていないドメイン環境のサポート
Calendar Server はホストされていないドメイン (つまり、シングルドメインを持つ) 環境での操作も引き続きサポートしています。たとえば、Calendar Server 5.x 以前の旧バージョンをインストールしている場合、シングルドメイン環境でも操作できます。
この場合、ics.conf ファイルで次のパラメータを no に設定します。
service.virtualdomain.support = "no"
ただし、6.x 以前の Calendar Server コンポーネントデータベースを現在のバージョンに移行する必要があります。移行の詳細については、第 4 章「移行ユーティリティ」を参照してください。
ホストされたドメイン環境への移行ここでは、LDAP にホストされたドメインエントリを新しく作成する前に、実行しなければならない、基本作業について説明します。
表 5-1 は、ホストされたドメインのサポートに使用される、ics.conf ファイルの設定パラメータ一覧を示しています。
表 5-1 に表示されるパラメータのいずれかが ics.conf ファイルに含まれていない場合は、パラメータと値をファイルに追加し、変更を適用するために Calendar Server を再起動します。
表 5-1 ホストされたドメインをサポートするための設定パラメータ
パラメータ
説明
service.virtualdomain.support
ホストされた (仮想) ドメインモードのサポートを有効化 (yes) または無効化 (no) する。デフォルトは no
local.schemaversion
LDAP スキーマのバージョンを指定する
- "1" = Sun LDAP Schema 1。service.dcroot も参照
- "2" = Sun LDAP Schema 2。service.schema2root も参照
デフォルトは 1
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 のこのインスタンスのデフォルトドメインを指定する。ログイン時にドメイン名が指定されない場合は、このドメイン名が適用される
例 :"sesta.com".
service.loginseparator
Calendar Server が userid[login-separator]domain をパースするときに login-separator で使用される区切り文字を指定する。Calendar Server は各区切り文字を順に使用する
デフォルトは @+
service.siteadmin.userid
ドメイン管理者のユーザー ID を指定する
例 : DomainAdmin@sesta.com
service.virtualdomain.scope = "select"
ドメイン間検索を制御する
デフォルトは select
local.domain.language
ドメインの言語を指定する。デフォルトは en (英語)
csvdmig 移行ユーティリティを実行すると、次の情報が変更されます。
csvdmig の実行については、第 4 章「移行ユーティリティ」を参照
Schema 1 の場合: ldapmodify を使用する LDAP の o=internet ドメインエントリに、icsCalendarDomain オブジェクトクラスを追加します。
Schema 2 の場合: commadmin の設定後、カレンダー (およびメール) サービスを追加するようにデフォルトドメイン (commadmin 設定プログラムで作成された) を変更します。次の例では、カレンダーサービスとメールサービスがデフォルトドメインに追加されます (blue.sesta.com)。
commadmin domain modify -D admin -w passwd -d blue.sesta.com -S cal,mail -H luna.blue.sesta.com
Messaging Server を利用して作成したドメインの使用Messaging Server が、ホストされたドメインをすでに作成している場合は、Schema 1 または Schema 2 のいずれかに対してカレンダーを有効にすることができます。ここで説明する内容は次のとおりです。
Schema 1 でのカレンダー管理を有効にする
ドメインに対するカレンダー管理を有効にするには、次の作業を実行します。
- Calendar Server ユーザーに対して有効にする各ドメインの LDAP エントリに icsCalendarDomain オブジェクトクラスを追加します。
- 手順 1 で有効にした各ドメインで、icsStatus の属性値を "active" に設定します。
- 手順 1 で有効にした各ドメインで、icsExtendedDomainPrefs 属性のアクセス制御に使用するオプション domainAccess の値を ACL に設定します。
これを実行するには、csattribute add コマンドを使用することも、コード例 5-1 に示すように ldapmodify を使用することもできます。
- カレンダーシステムごとにドメインレベルの管理者が必要な場合は、適切なアクセス制御を追加して、各ドメインに calmaster ユーザーを追加します。
- 有効にしたドメインごとに、csuer enable コマンドを使用して、既存のすべてのユーザーに対してもカレンダーを有効にする必要があります。
csattribute ユーティリティと csuser ユーティリティの使用方法については、付録 D 「Calendar Server のコマンド行ユーティリティのリファレンス」を参照してください。
Schema 2 でのカレンダー管理を有効にする
(commdirmig を使用して) すでに既存の Messaging Server LDAP エントリを Schema 2 に移行しているか、Messaging Server LDAP エントリを Schema 2 モードで独自に作成した場合は、次の手順でカレンダー管理を有効にします。
commadmin コマンドの詳細については、『Sun Java System Communications Services User Management Utility Administration Guide』を参照してください。
commdirmig の詳細については、『Sun Java System Communications Services Schema Migration Guide』を参照してください。