ディレクトリへの統合

CommuniGate Pro のドメインは、次の3 種類のレベルでディレクトリに統合できます。

• 統合なし： ドメイン設定とドメインのアカウント設定はそれぞれ.settings ファイルに格納さ れ、ディレクトリには格納されません。したがって、アカウントの作成、更新、名前の変更、削 除が発生しても、ディレクトリは一切、更新されません。
• 同期： ドメイン設定とドメインのアカウント設定はそれぞれ.settings ファイルに格納さま す。同時に、ディレクトリに各アカウントのレコードが作成され、このレコードにアカウント 設定の「一部」が属性として格納されます。レコードに格納されるアカウントの属性は、次の通りです。
  • アカウントの名前（uid 属性）
  • アカウントの実名（cn 属性）
  • アカウントの証明書（userCertificate 属性、存在する場合）
  • ホストサーバーのメインドメインの名前（hostServer 属性、この属性は、ディレクトリ ベースのクラスタであるスタティッククラスタの実装に必要）
  • オプションのカスタム（公開情報） 設定/ 属性
  この統合レベルの場合、アカウントの作成、名前の変更、削除、更新が発生すると、ディレクト リも自動的に更新されます。
• ディレクトリベース： ドメイン設定とドメインのアカウント設定はすべて、ディレクトリ中の レコードに格納されます。.settings ファイルは作成されず、設定データはすべてディレクト リから取り出されます。

上記のほか、通常のドメインを使用し（ディレクトリへの統合なし）、LDAP を介してアカウントのプ ロビジョニングを行うという方法もあります。この場合の処理は、上記の3 番目の「ディレクトリベー ス」の統合と似ています。この方法では、LDAP コマンドを使ってアカウントの作成と更新が可能で す。この処理をLDAP ベースのプロビジョニング（または、単にLDAP プロビジョニング） と呼んで います。

CommuniGate Pro ディレクトリを使用する場合、ドメイン設定データまたはアカウント設定データの 中には、その名前がディレクトリスキーマに定義されている「標準」の属性名と対応しなければない ものもあります。例えば、アカウント設定Real Name がある場合、ディレクトリにcn （一般名） 属性がなければなりません。また、カスタムのアカウント設定としてsurname とcity （下記を参 照） がある場合、ディレクトリにsn 属性とl 属性が存在しなければなりません。

ディレクトリスキーマには属性を追加できますが、その場合、属性の名前としては必ず、LDAP イン ターネット標準（RFC） に指定されている名前を使用しなければなりません。また、追加した属性を ディレクトリ統合で使用（つまり、その属性を使って、ドメイン設定またはアカウント設定の値を ディレクトリに格納） するときには、その属性名をドメイン設定の名前またはアカウント設定の名前 に「マップ」することが必要です。

属性名のマップは、次の［Attributes Renaming］ テーブルを使って行います。［Name in CommuniGate Pro］ フィールドには、ドメイン設定またはアカウント設定の名前を入力します。［Name in Directory］ フィールドには、その名前に対応するディレクトリの属性の名前を入力します。

属性遷移

CommuniGate名	ディレクトリ名

注意: 上記の属性名のマップ機能は、CommuniGate Pro サーバーのディレクトリ統合コンポーネント についてのみ有効です。したがって、ディレクトリ統合コンポーネントを介さず、ディレクトリに直 接、アクセスを行う場合（例えば、LDAP モジュール経由）、属性名のマップは実行されません。そ のため、LDAP モジュール経由でディレクトリにアクセスする場合、LDAP クライアント上ではドメ イン設定またはアカウント設定の名前ではなく、ディレクトリの属性名が指定されていなければなら ず、これで、その属性名に対応するレコードが返ります。例えば、LDAP クライアントでは、 "RealName" ではなく"cn" を、また"Password" ではなく"userPassword" を指定しなければなりませ ん。

ドメインが通常のドメイン（非ディレクトリベースのドメイン） で、そのドメインの［Directory Ingetration］ オプションが［Keep in Sync］ に設定されている場合、または、ディレクトリベースのド メインの場合、そのドメインのディレクトリサブツリー（ ドメインサブツリー） が作成されます。こ の場合、サブツリーのルートにドメインのレコードが、また、サブツリーの要素にドメインの各アカ ウントのレコードが格納されます。さらに、必要に応じて追加の要素が作成され、各要素にアカウン トのエイリアスや各ドメイン設定などが格納されます。

ドメインサブツリーが作成される場所（構造） は、［Domain Subtree］ パネルを使って指定できます。

ドメインサブツリー

ベースDN:
ドメインRDN属性:
ドメインオブジェクトクラス:
UIDサブツリー:

ベースDN

このフィールドには、ベース識別名（ベースDN） を指定します。この識別名は、セントラル ディレクトリ（CommuniGate Pro ディレクトリ） に格納されるドメインすべての「基本」識別名 です。例えば、次のように指定した場合（your company name は会社名）、

o=your company name

CommuniGate Pro のドメインは、次の識別名で表現されます（domain name はドメイン名）。

cn=domain name,o=your company name

ドメインのレコードがディレクトリに格納される際、そのドメインの識別名を使ってレコード が作成されます。その場合、ベース識別名が存在しなかったときには、エラーが出力されるこ とがあります。ベース識別名の入力後、［Create It］ ボタンをクリックすると、そのベース識別 名で示されるレコードが作成されます。この時点では、レコードの内容は空です。

CommuniGate Pro をISP のサーバーとして使用する場合、通常、ホストするドメインをそれぞれ 最上位の識別名として指定します。形式は、次の通りです。

cn=domain name

また、［Base DN］ フィールドは空にしておきます。

ドメインRDN属性

このフィールドには、ドメインのレコードの相対識別名（識別名の左端の属性名） を指定しま す。この設定は通常、デフォルト値（cn） のままで十分です。別の属性の名前に変更することもできますが、その場合、その名前は、ディレクトリスキーマに定義されているものでなけれ ばなりません。また、この値をo に設定しておくと、ドメインのレコードの識別名として、自 動的に次の識別名が使われるようになります（domain name はドメイン名、base DN はベー ス識別名）。

o=domain name,base DN

注意: このフィールドの値として文字列dc を指定しておくと、ドメインmail.domain.dom の識別名として自動的にdc=mail,dc=domain,dc=dom が使われるようになります。

ドメインオブジェクトクラス

このフィールドには、ディレクトリに格納されるドメインのレコードのオブジェクトクラスを 指定します。デフォルト値は、CommuniGate Pro ディレクトリマネージャスキーマで定義され ているオブジェクトクラス（CommuniGateDomain） です。このデフォルト値は変更できます が、その場合、ディレクトリスキーマ（［Object Classes］ パネル） で定義されているオブジェ クトクラスのいずれかを指定しなければなりません

通常のドメイン（ディレクトリに統合されていないドメイン） の場合、そのドメインのレコー ド（ディレクトリ中のドメインレコード） は空で、ドメインの設定データは何も格納されませ ん。したがって、そのドメインのオブジェクトクラスとしては、cn 属性（デフォルト）、また は、［Domain RDN attribute］ フィールドで指定した属性を格納できるオブジェクトクラスであ れば、任意のものを使用できます。

一方、ディレクトリベースのドメインの場合、ディレクトリのドメインレコードには、そのド メインの設定データがすべて格納されます。したがって、ドメインレコードに使われるオブ ジェクトクラスは、指定されているオブジェクトクラス（CommuniGateDomain） の属性がすべ てサポートされているオブジェクトクラスでなければなりません（ このフィールドの値を CommuniGateDomain に設定している場合）。

UIDサブツリー

このフィールドを空にしておくと、ドメインのオブジェクト（アカウント、グループ、メーリ ングリスト、フォワーダ） のレコードはすべて、uid=objectName,domain DN の形式の識別 名を使ってディレクトリに格納されます（objectName はオブジェクト名、domain DN はド メインの識別名）。
このフィールドが空で、ベース識別名（［Base DN］ フィールド） がo=mycompany、ドメインの 相対識別名（［Domain RDN attribute］ フィールド） がcn の場合、ドメインdomain1.dom のア カウントuser1 のディレクトリレコード（UID サブツリー） は下記の識別名で格納されます。
uid=user1,cn=domain1.dom,o=mycompany
一方、このフィールドにオブジェクトを指定した場合、そのオブジェクトは、ドメインツリー （cn=domain1.dom） の「下位」のオブジェクトとして使用されます。例えば、このフィール ドにou=People を指定した場合、上記のアカウントのレコードは、次の識別名で格納されま す。
uid=user1,ou=People,cn=domain1.dom,o=mycompany
また、［Domain RDN attribute］ フィールドにdc を指定しておいたときには、上記のアカウント のレコードは、次の識別名を使って格納されます。
uid=user1,ou=People,dc=domain1,dc=dom,o=mycompany

例:

ベース識別名（ベースDN） が空白で、ドメインの相対識別名がcn に設定されており、 CommuniGate Pro のドメインとして3 つのドメイン（domain1.dom、domain2.dom、 domain3.dom） が作成された場合、ディレクトリの内容は次のようになります。

このケースでは、LDAP クライアントでドメインサブツリー（cn=domain1.dom など） のアカウ ントを検索する場合、LDAP クライアントでは、パラメータとして次の文字列を指定します （domainN は、domain1、domain2 など）。

cn=domainN.dom

LDAP クライアントでは、上記の文字列をベースオブジェクト（Base Object） パラメータ、ま たはサーチベース（Search Base） パラメータとして指定します。

例:

ベース識別名がo=acme、ドメインの相対識別名がcn に設定されており、CommuniGate Pro の ドメインとして3 つのドメイン（domain1.dom、domain2.dom、domain3.dom） が作成された場 合、ディレクトリの内容は次のようになります。

この場合、LDAP クライアントでドメインサブツリーのアカウントを検索するときには、LDAP クライアントでは、パラメータとして次の文字列を指定します（domainN は、domain1、 domain2 など）。

cn=domainN.dom,o=acme

LDAP クライアントでは、上記の文字列をベースオブジェクト（Base Object） パラメータ、また はサーチベース（Search Base） パラメータとして指定します。

例:

ベース識別名がo=acme、ドメインの相対識別名がdc で、CommuniGate Pro のドメインとして 3 つのドメイン（domain1.dom、domain2.dom、domain3.dom） が作成された場合、ディレクトリ の内容は次のようになります。

この場合、LDAP クライアントでドメインサブツリーのアカウントを検索するときには、LDAP クライアントでは、パラメータとして次の文字列を指定します（domainN は、domain1、 domain2 など）。

dc=domainN,dc=dom,o=acme

LDAP クライアントでは、上記の文字列をベースオブジェクト（Base Object） パラメータ、ま たはサーチベース（Search Base） パラメータとして指定します。

［Domain Subtree］ パネルを使ってドメインサブツリーの構造の設定ができれば、その後、ストレージユニットを作成し、そのストレージユニットにドメイン/ アカウント設定データを格納することも できます（ この作業は、必須ではありません）。例えば、CommuniGate Pro のドメイン/ アカウント とは関係のないデータはCommuniGate Pro のディレクトリマネージャによって格納（つまり、下図 のストレージユニットMAIN に格納） されるようにし、その一方、ドメイン/ アカウント情報はすべ て、リモートLDAP サーバーまたは専用のローカルストレージユニット（下図では、ストレージユ ニットDOMAINS） に格納されるように設定できます。例えば、ストレージユニットMyDomains を作成し、そのユニットをドメインサブツリーとして設定 （ベース識別名として設定、上記の例ではo=acme） します。このようにすることで、ドメイン/ ア カウントのレコードはすべて、ストレージユニットMyDomains （専用のローカルユニットまたはリ モートLDAP サーバー） に格納されます。一方、ドメイン/ アカウントとは関係のないデータ （ベース識別名がo=acme 以外のレコード） はいずれも、別のストレージユニット（下図ではMAIN） に格納されます。

注意:［Domain Subtree］ パネルの設定を変更しても、既存のドメインサブツリーは自動的に変更さ れず、そのまま残ります。したがって、ディレクトリへの統合（ ドメインサブツリーの設定） を行う 場合、あらかじめドメインサブツリーの構造や階層を十分考慮することが必要です。また、既存のド メインサブツリーは、その場所を変更したり（［Base DN］ フィールドのベース識別名を変更）、既存 のドメインレコードの相対識別名を変更したり（［Domain RDN Attribute］ フィールドの値を変更） で きますが、こういった変更は慎重に行う必要があります（既存のサブツリーは残っています）。

CommuniGate Pro サーバーでは、アカウント設定（のセット） があらかじめ定義されています（詳し くは、「アカウント」のセクションのアカウントの説明を参照してください）。こうした定義済みの設 定のほか、カスタム（ユーザー定義） アカウント設定を追加できます。追加は、下記の［Custom Account Settings］ パネルで行えます。

カスタムアカウント設定

システム

公開情報

このパネルでは、ユーザーに関する情報（場所や電話番号など） を格納する設定フィールドを定義で きます。

［System］ の各フィールドの値は、システム管理者、または基本（Basic Domain） ドメインアクセス権 を有するドメイン管理者が入力、変更できます。

［Public Info］ の各フィールドの値は、ユーザー自身が入力、変更できます。

［System］ （システム情報） または［Public Info］ （公開情報） の下の空白のフィールドにカスタムアカ ウント設定の名前を入力し、［Update］ ボタンをクリックすると、そのカスタムアカウント設定が作 成されます。

カスタムアカウント設定はいずれも、ディレクトリ中のアカウントレコードに格納されます（レコー ドのオブジェクトクラスはCommuniGateAccount です）。

新規のカスタムアカウント設定を作成する場合、その名前としては、オブジェクトクラスCommuni- GateAccount に定義されているいずれかの属性の名前を使用できます（「ディレクトリスキーマ」の セクションを参照）。または、任意の名前を入力し、属性名の変更機能を使って、その名前をディレ クトリの属性名（既存の属性の名前） に割り当てるという方法も使用できます。

例:

新規のカスタムアカウント設定としてtelephoneNumber （電話番号） を作成したい場合、 ［Public Info］ リストの空白のフィールドに文字列telephoneNumber を入力します。
ローカルストレージユニットを使ってCommuniGate Pro のドメイン/ アカウントサブツリーが 格納されるように設定している場合、これ以上の操作は必要ありません。これで、属性 telephoneNumber がオブジェクトクラスCommuniGateAccount に自動的に挿入されます。ま た、この属性は、すべてのローカルユニットスキーマで使用されます。

例:

新規のカスタムアカウント設定としてsurname （姓） を作成したい場合、［System］ リストの 空白のフィールドに文字列surname を入力します。また、［Attributes Renaming］ パネル（属 性名のマップ機能） の［Name in CommuniGate Pro］ フィールドにsurname、［Name in Directory］ フィールドにsn を入力します。これで、surname というアカウント設定が属性 sn としてディレクトリのレコードに格納されます。
ローカルストレージユニットを使ってCommuniGate Pro のドメイン/ アカウントサブツリーが 格納されるように設定している場合、これ以上の操作は必要ありません。これで、属性sn が オブジェクトクラスCommuniGateAccount に自動的に挿入されます。また、この属性は、すべ てのローカルユニットスキーマで使用されます。

例:

新規のカスタムアカウント設定としてBirthDay （誕生日） を作成したい場合、空白のフィー ルドに文字列BirthDay を入力します。
ローカルストレージユニットを使ってCommuniGate Pro のドメイン/ アカウントサブツリーが 格納されるように設定している場合、そのローカルユニットスキーマに属性BirthDay を追加 します。また、属性BirthDay をオブジェクトクラスCommuniGateAccount のオプションの属 性として追加するという作業も必要です。
一方、リモートストレージユニットを使ってCommuniGate Pro のドメイン/ アカウントサブツ リーが格納されるように設定している場合、リモートLDAP サーバーのディレクトリスキーマ を更新し、オブジェクトクラスCommuniGateAccount のレコードに属性BirthDay が取り込ま れるように設定し直す必要があります。

注意: Aディレクトリ中のアカウントレコードには必ず属性sn が必要で、この属性を介して、アカウ ントレコードと標準のLDAP ディレクトリスキーマとの間で互換が維持されます。このカスタムアカ ウント設定（例えば、surname） を定義しなかった場合、ディレクトリに格納されるアカウントレ コードの属性sn は空白の文字列になります。

以上のようにしてカスタムアカウント設定を追加すると、その名前が［Account Settings］ ページに 表示されます。このページ（または、CLI） を使って、カスタムアカウント設定の値を追加したり変 更したりできます。ここで指定した値がCommuniGate Pro のアカウントで使用されます。

実名:
surname:
市区町村:
CommuniGate   パスワード:
telephoneNumber:

注意: 作成済みのカスタムアカウント設定の名前を変更したりカスタムアカウント設定を削除して も、ディレクトリ中のアカウントレコードの値が自動的に更新されることはありません。つまり、カ スタムアカウント設定に関する変更は、あくまでディレクトリのパラメータに関する変更であり、 ディレクトリのデータの変更ではありません。ディレクトリの実際のデータを更新（例えば、属性 telephoneNumber の値をすべて削除） したい場合、LDAP ユーティリティ/ アプリケーションを使 用します。

通常のドメイン（非ディレクトリベースのドメイン） では、ディレクトリのデータは使用されません。 この場合、ドメインとアカウントの設定（データ） はすべて、CommuniGate Pro のファイルディレク トリの中にファイル（.settings ファイル） として格納されます。CommuniGate Pro サーバーでドメ イン/ アカウント設定データの取り出しが必要になった場合、こういったファイルから設定が読み込 まれます。なお、通常のドメインの場合でも、アカウント設定の一部をディレクトリレコードに格納 することもできます。

アカウント設定（の一部） がディレクトリレコードに格納されるように設定しておいた場合（下記を 参照）、CommuniGate Pro サーバー上でドメインのオブジェクトをディレクトリに格納する必要が発 生したときに、ディレクトリ中にレコードが作成されます。例えば、ドメインdom1.dom のアカウントjohn について、そのレコードの作成が必要になった場合、ディレクトリ中にまず、 cn=dom1.dom というレコードが作成され（ このレコードが存在しなかった場合）、その後、アカウ ントjohn のレコードとしてuid=john,cn=dom1.dom が作成されます。

ドメインが通常のドメインで、そのドメインの設定（オブジェクトまたはアカウントの設定） データ がディレクトリに格納されるようにしたい場合、［Directory Integration］ パネルの［Usage］ オプショ ンを［Keep In Sync］ に設定します。この設定の場合、次の処理が実行されます。

• ドメインにオブジェクト（アカウント、グループ、メーリングリスト、フォワーダ） が作成さ れた場合、そのオブジェクトのレコードがディレクトリに作成されます。
• ドメインのオブジェクトが削除された場合、そのオブジェクトのレコードがディレクトリから 削除されます。
• ドメインのオブジェクトの名前が変更された場合、そのオブジェクトのレコード（ディレクト リ中のレコード） の識別名（DN） が変更されます。
• ドメインのアカウント設定が更新された場合、そのアカウント設定のレコード（ディレクトリ 中のレコード） が更新されます。

［Directory Integration］ オプション（ ［Usage］ ） を［Disabled］ に設定しておくと、上記の処理は一切、 行われません。

下記は、ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されて おり、このドメインに新規のアカウントが作成されたときの処理を示した図です。

下は、上記の処理の内容です。

• WebAdmin インターフェイスまたはCLI インターフェイスを使って、ドメインdom1.com にアカ ウントjohn が作成されます。
• アカウントjohn が作成され、所定の設定（また、アカウントテンプレート） を使って、初期ア カウント設定が作成されます。
• アカウントマネージャによってAddRecord 処理が実行され、この処理により、ディレクトリに レコードが作成されます。
  グローバルディレクトリ統合設定を使って、レコードの識別名（DN） が作成されます。例え ば、デフォルトのディレクトリ統合設定の場合、uid=john,cn=dom1.dom という識別名が作 成されます。
  初期アカウント設定のうち、いくつかはディレクトリ属性に変換され、各属性が作成されたレ コードに格納されます（下記を参照）。

この後、ディレクトリ検索処理（LDAP クライアントまたはWebUser インターフェイスで可能） を実 行でき、検索後、新規に作成されたレコードが表示されます。

作成されたレコードには、次の属性が格納されます。

• uid - アカウントの名前。
• cn - アカウントの「実名」。
• sn - この属性がカスタムアカウント設定（例えば、surname） として定義されていない場合、 空白の文字列。
• hostServer - このアカウントをホストしているCommuniGate Pro サーバーのメインドメイン の名前。
• userCertificate - アカウントの証明書（ある場合）。
• カスタムアカウント設定（上記を参照）。
• userPasword - アカウントのパスワード（オプション、下記を参照）。
• その他の標準の設定（オプション、下記を参照）。

WebAdmin インターフェイスの［Directory Integration］ ページには［Regular Domains］ パネルがあり ます。このパネルを使って、ディレクトリに格納される属性（パスワードと標準の設定） の設定が可 能です。

通常ドメイン

アカウントレコードにコピー:	パスワード
	標準設定

アカウントレコードにコピー: パスワード

このオプションを有効に設定しておくと、ドメインのアカウントのパスワードがディレクトリ のアカウントレコードにコピーされます（通常、パスワード属性の名前がuserPassword に 変換され、レコードに格納されます）。

アカウントレコードにコピー: 標準設定

CommuniGate Pro のアカウントの標準の設定がすべてコピーされます。ただし、RealName と userCertificate の各設定（どちらも必ずレコードに格納され、したがって設定の必要はありませ ん） とPassword 設定（別のオプションで設定できます） は除きます。

下記は、ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されて おり、このドメインのアカウント設定が更新されたときの処理を示した図です。

下は、上記の処理の説明です。

• WebAdmin インターフェイスコマンドまたはCLI インターフェイスコマンドにより、 UpdateAccount 処理が開始されます。
• コマンドで提供された新規の設定をもとにアカウントjohn の設定が変更され、その後、更新さ れた設定がCommuniGate Pro のアカウントのデータファイルに格納されます。
• ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されている 場合、アカウントマネージャによってUpdateRecord 処理（ディレクトリ処理） が実行され、そ の結果、ディレクトリのアカウントレコードが更新されます。

注意: 通常のドメインをディレクトリに統合する場合（ ［Directory Integration］ オプション［Keep In Sync］ に設定）、ディレクトリとドメインは一方向の関係であることに注意が必要です。つまり、ディ レクトリのアカウントレコードの属性を変更しても（LDAP ユーティリティを使用）、実際のアカウン ト設定は一切変更されません。また、CommuniGate Pro 上で、通常のドメインの設定データや、その ドメインのアカウントの設定データが必要になった場合、必ずアカウント設定ファイルのデータが使 用され、ディレクトリのデータが読み取られることはありません。さらに、ディレクトリのレコード は、CommuniGate Pro のドメイン/ アカウントマネージャによって更新されますが、このマネージャ の機能は更新だけで、ディレクトリのアカウントレコードを読み取る機能はありません。

下記は、ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されて おり、このドメインのアカウントの名前が変更されたときの処理を示した図です。

下は、上記の処理の内容です。

• WebAdmin インターフェイスコマンドまたはCLI インターフェイスコマンドにより、 RenameAccount 処理が開始されます。
• アカウントjohn の名前、また、その関連ファイルの名前が変更されます。
• ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されている 場合、アカウントマネージャによってRenameRecord （modifyDN） 処理（ディレクトリ処理） が 実行され、その結果、ディレクトリのアカウントレコードの名前が変更されます。

下記は、ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されて おり、このドメインのアカウントが削除されたときの処理を示した図です。

下は、上記の処理の内容です。

• WebAdmin インターフェイスコマンドまたはCLI インターフェイスコマンドにより、 RevomeAccount 処理が開始されます。
• アカウントjohn、また、その関連ファイルが削除されます。
• ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されている 場合、アカウントマネージャによってDeleteRecord 処理（ディレクトリ処理） が実行され、そ の結果、ディレクトリのアカウントレコードが削除されます。

ドメインの［Settings］ ページの［Directory Integration］ パネルには［Delete All］ ボタンがあります。 このボタンをクリックすると、ディレクトリに格納されているドメインレコードと、ドメインのオブ ジェクトのレコードがすべて削除されます。なお、この処理では、レコードのうち、レコードに属性 hostServer があり、その値がCommuniGate Pro サーバーのメインドメインの名前と同じレコードだけ が削除されます。

また、ドメインの［Settings］ ページの［Directory Integration］ パネルには［Insert All］ ボタンがあり ます。このボタンをクリックすると、そのドメインのディレクトリレコードが作成され、同時に、そ のドメインの全オブジェクトのディレクトリレコードが作成されます。

注意: ドメインの［Directory Integration］ オプションが［Disabled］ に設定されており、そのドメイン にアカウントを作成した場合、ディレクトリには、作成したアカウントのレコードは格納されません。 その後、［Directory Integration］ オプションを［Keep In Sync］ に変更し、この設定で、作成したアカ ウントの名前の変更や削除、更新を行ったときには、エラーレポートが出力されます。これは、Directory Integration］ オプションが［Keep In Sync］ に設定されているため、サーバーにより、こうしたアカウントのレコード（ディレクトリ中のアカウントレコード） に対して更新が試みられますが、該当する レコードがディレクトリに存在しないためです。

［Directory Integration］ オプションを［Disabled］ から［Keep In Sync］ に変更する場合、まず、 ［Delete All］ ボタンをクリックし、その後、［Insert All］ ボタンをクリックします。この操作により、 ディレクトリとドメインの現在のオブジェクトとの間で同期がとられます（削除と挿入が実行されま す）。この後、［Directory Integration］ オプションの設定を［Disabled］ から［Keep In Sync］ に変更し ます。これで、上記の問題は解決されます。

CommuniGate Pro では、LDAP プロトコルを介して、アカウントの作成、更新、名前の変更、削除が 可能です。

LDAPダイレクトプロビジョニング

オフオン

［LDAP direct Provisioning］ オプションを有効（Enabled） にしておくと、更新処理の際、LDAP モジュー ルにより、その更新処理で指定されている名前（識別名） がチェックされます。その識別名（DN） が CommuniGate Pro のアカウントの識別名と類似している場合、LDAP モジュールでは、ディレクトリ に対する更新処理は実行されません。その代わり、更新処理で指定されているアカウントとドメイン について、その処理の内容に応じてCreateAccount （アカウント作成）、UpdateAccount （アカウント更 新）、RenameAccount （アカウント名変更）、RemoveAccount （アカウント削除） が実行されます。その 後、最終のディレクトリ処理が実行されます。

処理がアカウントの作成の場合、LDAP AddRecord 処理が実行されます。下記は、この処理の流れを 示した図です。

下は、上記の処理の内容です。

• LDAP モジュールで、LDAP クライアントからAddRecord 要求が受信されます。要求の内容は、 識別名がuid=john,cn=dom1.com であるレコードの作成です。
• LDAP モジュールにより、要求に指定されている識別名がチェックされ、その識別名が、 CommuniGate Pro のドメインdom1.dom のアカウントjohn に似ていること、また、 CommuniGate Pro のドメインdom1.com が存在することが確認されます。
• LDAP モジュールでは、ディレクトリに対するAddRecord 処理は行われず、代わりにドメイン dom1.dom についてCreateAccount(john) 処理が実行されます。
• アカウントjohn が作成され、LDAP で指定されている属性（また、アカウントテンプレートの 設定） を使って、初期アカウント設定（データ） が作成されます。
• ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されている 場合、アカウントマネージャによってAddRecord 処理（ディレクトリ処理） が実行され、その 結果、ディレクトリにレコードが作成されます。

注意: LDAP クライアントから送信されたレコード（要求） の各属性の名前はそれぞれ、ディレクト リ統合設定（［Directory Integration］ ページの各種設定） にしたがってCommuniGate Pro の属性の名前 に変更されます。例えば、AddRecord 要求に属性cn がある場合、この属性は、RealName （実名） と してアカウント設定データに格納されます。その後、アカウントマネージャによってレコードがディ レクトリに追加される際、この名前（RealName） は再度、属性cn に変換され、この属性名を使って レコードに格納されます。

注意: LDAP クライアントからのAddRecord 要求の属性はすべて、CommuniGate Pro のアカウント設 定に格納されます。一方、ディレクトリのレコードにコピーされる属性は、ディレクトリ統合設定に 指定されている属性に限られます。ただし、AddRecord 要求には存在しなくても、アカウントテンプ レートに指定されていれば、その属性はディレクトリのレコードに格納されます。

注意: 上記の処理（LDAP プロビジョニング） で、属性unixPassword （Unix パスワード） が検出さ れた場合、その値に第1 バイト（0x02） が付加された後、属性がPassword 設定に変換されます。ア カウントのインポートとUnix パスワードについては、詳しくは「アカウント」のセクションのアカウントのインポートの説明を参照してください。

処理がアカウントの更新の場合、LDAP ModifyRecord 処理が実行されます。下記は、この処理の流れ を示した図です。

下は、上記の処理の内容です。

• LDAP モジュールで、LDAP クライアントからModifyRecord 要求が受信されます。要求の内容は、 識別名がuid=john,cn=dom1.com であるレコードの更新です。
• LDAP モジュールにより、要求に指定されている識別名がチェックされ、その識別名が、 CommuniGate Pro のドメインdom1.dom のアカウントjohn に似ていること、また、 CommuniGate Pro のドメインdom1.com が存在することが確認されます。
• LDAP モジュールでは、ディレクトリに対するModifyRecord 処理は行われず、代わりにドメイン dom1.dom についてUpdateAccount(john) 処理が実行されます。
• LDAP で指定されている属性を使って、アカウントjohn のアカウント設定が修正されます。
• ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されている 場合、アカウントマネージャによってModifyRecord 処理（ディレクトリ処理） が実行され、そ の結果、ディレクトリのレコードが更新されます。

処理がアカウント名の変更の場合、LDAP ModifyDN 処理が実行されます。下記は、この処理の流れ を示した図です。

下は、上記の処理の内容です。

• LDAP モジュールで、LDAP クライアントからModifyDN 要求が受信されます。要求の内容は、識 別名がuid=john,cn=dom1.com であるレコードの名前（識別名） の変更です。
• LDAP モジュールにより、要求に指定されている識別名がチェックされ、その識別名が、 CommuniGate Pro のドメインdom1.dom のアカウントjohn に似ていること、また、 CommuniGate Pro のドメインdom1.com が存在することが確認されます。さらに、新規の名前 （uid=john1） がCommuniGate Pro のアカウントのレコードの識別名に似ていることが確認さ れます。
• LDAP モジュールでは、ディレクトリに対するModifyDN 処理は行われず、代わりにドメイン dom1.dom についてRenameAccount(john,john1) 処理が実行されます。
• アカウントjohn の名前（john） がjohn1 に変更されます。
• ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されている 場合、アカウントマネージャによってModifyDN 処理（ディレクトリ処理） が実行され、その 結果、ディレクトリのレコードの識別名（DN） が変更されます。

処理がアカウントの削除の場合、LDAP DeleteRecord 処理が実行されます。下記は、この処理の流れ を示した図です。

下は、上記の処理の内容です。

• LDAP モジュールで、LDAP クライアントからDeleteRecord 要求が受信されます。要求の内容は、 識別名がuid=john,cn=dom1.com であるレコードの削除です。
• LDAP モジュールにより、要求に指定されている識別名がチェックされ、その識別名が、 CommuniGate Pro のドメインdom1.dom のアカウントjohn に似ていること、また、 CommuniGate Pro のドメインdom1.com が存在することが確認されます。
• LDAP モジュールでは、ディレクトリに対するDeleteRecord 処理は行われず、代わりにドメイン dom1.dom についてDeleteAccount(john) 処理が実行されます。
• アカウントjohn が削除されます。
• ドメインdom1.com の［Directory Integration］ オプションが［Keep In Sync］ に設定されている 場合、アカウントマネージャによってDeleteRecord 処理（ディレクトリ処理） が実行され、そ の結果、ディレクトリのアカウントjohn のレコードが削除されます。

When LDAP Provisioning is enabled, the LDAP module uses special processing for some search requests, too. If

• the search request Base DN looks like a DN of some CommuniGate Pro Account, and
• the search request "scope" parameter is "base",

the LDAP module calls the Account Manager directly and retrieves the effective settings for the specified Account (i.e. the Account settings as well as all its Default Settings). The module converts these settings into Directory attributes, and sends them back to the LDAP client as a search result record.
If the authenticated LDAP user does not have the Domain Administrator access right for the target Account Domain, only the Real Name, User Certificate, Custom, Public Info, and mail attributes are retrieved.

CommuniGate Pro サーバーでは、ディレクトリベースのドメインをサポートしています。ディレクト リベースのドメインとは、ドメインの設定のほか、そのドメインのアカウントの設定がすべてディレ クトリに格納されるようなドメインをいいます。したがって、ディレクトリベースのドメインの場合、 ドメインの.settings ファイル、また、そのドメインのアカウントの.settings ファイルはあり ません。

ディレクトリベースのドメインの場合、ドメインについてそれぞれ、オブジェクトクラスが CommuniGateDirectoryDomain であるディレクトリレコード（ディレクトリ中のレコード） が作成され ます。このレコードに、そのドメインのドメイン設定がすべて格納されます。
ディレクトリベースのドメインの識別名は、通常のドメイン（ ［Directory Integration］ オプションが ［Keep In Sync］ に設定されているドメイン） と同じ方法で作成されます。

また、ディレクトリベースのドメインの場合、アカウントについてそれぞれ、オブジェクトクラスが CommuniGateAccount であるディレクトリレコードが作成されます。このレコードに、そのアカウン トのアカウント設定（カスタム設定を含む） がすべて格納されます。
ディレクトリベースのドメインのアカウントの識別名は、通常のドメインのアカウントと同じ方法で 作成されます。

ディレクトリベースのドメインのアカウントでは、そのディレクトリレコードに属性storageLocation が格納されていなければなりません。この属性の値は、アカウントのファイルディレクトリの場所 （ メールボックスがマルチメールボックスのアカウントの場合）、または、アカウントのINBOX ファイ ルが格納されている場所（ メールボックスがシングルメールボックスのアカウントの場合） です。こ の場所はいずれも、そのアカウントをホストしているCommuniGate Pro サーバーのベースディレクト リからの相対パスで指定されていなければなりません。

CommuniGate Pro サーバー上で、ディレクトリベースのドメインのアカウントがオープンされる際、 そのアカウントの属性storageLocation の値がアステリスク（*） で始まっていたときには、そのアカ ウントのファイルディレクトリ（ メールボックスがマルチメールボックスのアカウントの場合） のほ か、その他の必須の関連ファイルとファイルディレクトリが自動的に作成されます。

• 属性storageLocation の値がアステリスク（*） で始まっており、アステリスクが１ つだけの場 合、通常のドメインの新規のアカウントにパスが作成されるのと同じ方法で、そのアカウント の新規のパスが作成されます。つまり、そのアカウントのドメインのファイルディレクトリの 設定とフォルダリング方法（［Account Storage］ パネルの［Foldering Method］ オプションの設 定） を使ってパスが作成されます。

アカウントのディレクトリレコード（アカウントレコード） は、ディレクトリベースのドメインのア カウントのエイリアスについて作成されます。
エイリアスレコードの名前はいずれも、アカウントの識別名（uid= エイリアス名, ドメイン識別名） と 同じです。
エイリアスレコードのオブジェクトクラスは、標準のエイリアスオブジェクトクラスです。また、 aliasedObjectName の値（エイリアスオブジェクト名） は、オリジナルのアカウントレコードの識別名 と同じです。

下は、LDAP AddRecord 処理により、ディレクトリベースのドメインに新規のアカウントが作成され るときの流れを示した図です。

下は、上記の処理の内容です。

• LDAP モジュールで、LDAP クライアントからAddRecord 要求が受信されます。要求の内容は、識 別名がuid=john,cn=dom1.com であるレコードの作成です。
• LDAP モジュールにより、ディレクトリ中に新規のレコードが作成され、要求に指定されている 属性がすべて、そのレコードに格納されます。応答がLDAP クライアントに送信され、処理が 完了します。
• その後、メールサーバーコンポーネントによって、ディレクトリベースのドメインdom1.com の アカウントjohn のオープンが実行されます。ここで、要求がディレクトリに送信され、レコー ドのうち、識別名がuid=john,cn=dom1.com であるレコードが取り出されます。
• 取り出されたレコードの属性storageLocation にアステリスク（*） があった場合、メールサーバー により、そのアカウントのアカウントファイルがディスク上に作成され、また、ディレクトリ レコードが更新されます。その後、アカウントファイルのファイルパスが属性storageLocation に格納されます。
• アカウントjohn がオープンされ、要求された処理（アカウントの作成） が実行されます。

ディレクトリベースのドメインの場合、アカウントのアカウント設定は、CommuniGate Pro のデータ ファイルではなくディレクトリに格納されます。そのため、アカウント設定は、アカウントのオープ ン時にアカウントのディレクトリレコード（アカウントレコード） から取り出されます。下は、アカ ウント設定の取り出しの流れを示した図です。

また、アカウント設定はいずれもディレクトリレコードに格納されているため、まず、ディレクトリ レコードが変更されます。その後、ドメインのアカウント設定が変更されます。下は、この処理の流 れを示した図です。

下は、上記の処理の内容です。

• LDAP モジュールで、LDAP クライアントからModifyRecord 要求が受信されます。要求の内容は、 識別名がuid=john,cn=dom1.com であるレコードの属性の変更です。
• LDAP モジュールにより、要求で指定されたレコードの変更が実行されます。その後、応答が LDAP クライアントに送信され、処理が完了します。
• その後、メールサーバーにより、ディレクトリベースのドメインdom1.com のアカウントjohn がオープンされます。同時に、ディレクトリに対して要求が送信され、識別名が uid=john,cn=dom1.com のレコードが取り出されます。ここで、そのレコードの属性がアカ ウント設定として使われます。この場合、属性の値が変更されているため、その属性に対応す るアカウント設定も変更されます。

CommuniGate Pro サーバーを複数使用している場合、各サーバーのドメイン統合レコードを同一の ディレクトリ（ディレクトリユニット） に格納できます。このようなディレクトリを共有ディレクト リと呼んでいます。

共有ディレクトリは、いずれかのCommuniGate Pro サーバーに単一のローカルストレージユニッ トとして置いておくことができます。また、サードパーティのディレクトリサーバーに置くこ ともできます。

• 共有ディレクトリを使用する場合、各CommuniGate Pro サーバーのドメインサブツリー設定 は同じでなければなりません。
• 共有ディレクトリを置くCommuniGate Pro サーバーを除き、すべてのCommuniGate Pro サーバー にリモートストレージユニットを作成します。この場合、リモートストレージユニットのサブ ツリーのパラメータ（ リモートユニットの［Settings］ パネルの［Server Subtree］ フィールド） は、ドメインサブツリーのベース識別名（DN） と同じか、またはドメインサブツリーのベース 識別名の親識別名でなければなりません。この設定で、ドメインサブツリー全体が各リモート ストレージユニットに格納されます。
• リモートストレージユニットはいずれも、共有ディレクトリが置かれているサーバーを指すよ うに設定します。

CommuniGate Pro サーバーが複数あり、その環境で共有ディレクトリを使用する場合、通常、サブツ リーが のリモートストレージユニットを各サーバー上に作成します。リモートストレージ ユニットを作成する場合、まず、そのリモートストレージユニットのデフォルトのローカルユニット Main を削除します。その後、下図の構成になるように設定を行います。

以下、上記の設定について説明します。

• いずれかのCommuniGate Pro サーバー（上図では中央のサーバー）に共有ディレクトリを格納し ます。
• 左側のCommuniGate Pro サーバー（SV1） と右側のCommuniGate Pro サーバー（SV2） で共有ディ レクトリが使用されるように設定します。方法は、SV1 とSV の両方にリモートストレージユ ニットSHR（中央のCommuniGate Pro サーバーの を使用するリモートストレージユニッ ト） を作成し、また、SV1 とSV をそれぞれ中央のCommuniGate Pro サーバーを指すように設定 します。
• 3 つのCommuniGate Pro サーバーのディレクトリ統合設定を同一にします。つまり、ドメインサ ブツリーのベース識別名をいずれもo=acme に設定します。
• 中央のCommuniGate Pro サーバー（共有ディレクトリのあるCommuniGate Pro サーバー） のロー カルストレージユニットMain にディレクトリレコード（o=acme） を作成します。
• 以上の設定で、次の3 種類のレコード、
  • SV1 サーバー上で作成されたレコード（ ドメインdom1.dom のレコード）
  • SV2 サーバー上で作成されたレコード（ ドメインdom2.dom のレコード）
  • 中央のCommuniGate Pro サーバーで作成されたレコード（ ドメインdom3.dom のレコード）
  がいずれも、中央のCommuniGate Pro サーバーのローカルストレージユニットMain に格納されるよ うになります。

上記のように、CommuniGate Pro サーバーが複数ある場合、いずれかのCommuniGate Pro サーバーに 共有ディレクトリを作成し、その共有ディレクトリにドメイン統合レコードをすべて一括して格納で きます。また、その場合、単一のドメインを各サーバーで共通して使用できるように設定することも できます。このドメインを分散ドメイン（各サーバーに分散したドメイン） と呼んでおり、各サー バーではそれぞれ、そのドメインの全アカウント（ユーザー） の一部をホストすることになります。 分散ドメインを使用する場合、下図の構成になるように設定します。なお、分散ドメインを使う場合、共有ドメインを分散ドメインのCommuniGate Pro サーバー（下の 例では、sv1.corp.com、sv2.corp.com、sv3.corp.com） のメインドメインに置くことはできません。

以下、上記の設定について説明します。

• 3 つのCommuniGate Pro サーバー（ メインドメインはそれぞれ、sv1.corp.com、sv2.corp.com、 sv3.corp.com） で処理されるドメイン（corp.com） は同一です。したがって、ドメイン corp.com のアカウントは、3 つのサーバーに分散して作成、格納されます。
• 3 つのCommuniGate Pro サーバーのいずれも、ドメインサブツリーのベース識別名を空白の文字 列（） に設定します。
• 共有ディレクトリは、通常、別のデバイス/ サーバーに格納します。ただし、3 つの CommuniGate Pro サーバーのいずれかで動作させることもできます。
• 3 つのCommuniGate Pro サーバーのいずれも、ドメインcorp.com の［Directory Integration］ オ プションを［Keep In Sync］ に設定します。

以上の設定で、いずれかのCommuniGate Pro サーバー（sv*.corp.com） でアカウントの作成、名前の 変更、削除、更新が実行されると、共有ディレクトリのディレクトリユニット（ディレクトリが置か れているストレージユニット） の内容が更新されます。その結果、全CommuniGate Pro サーバー （sv*.corp.com） の全アカウントのレコードが共有ディレクトリに格納（または更新） されます。

また、いずれかのCommuniGate Pro サーバーでアカウントが作成されると、そのレコードが共有ディ レクトリに格納されますが、その際、サーバーのメールのドメイン名がレコードの属性hostServer の値として保存されます。

ここで、共有ディレクトリを使って、共有ドメインのメールを所定の場所（サーバー） にルートする ことができます。このルート処理を行いたい場合、ディレクトリベースのルーティング設定（［General］ -> ［Cluster Settings］） を有効に設定します。これで、通常のアドレスルーティングメカニズムが次の ように修正されます。

• CommuniGate Pro サーバーでメールが受信され、メールの送信先が、そのCommuniGate Pro サー バーのいずれかのドメインだった場合、ローカルドメインのオブジェクト（アカウント、エイ リアス、メーリングリスト、グループ、フォワーダ） が存在するかどうかチェックされます。
• ローカルドメインにオブジェクトが何も見つからなかったときには、ディレクトリがチェック されます。
• 指定されているオブジェクト（uid= オブジェクト名,cn= ドメイン名） に該当するレコードがディ レクトリになかった場合、レコードの属性hostServer の値がチェックされます。
• 属性hostServer がなかった場合、または、その値が、そのCommuniGate Pro サーバーのメイ ンドメイン名だったときには、エラーメッセージが出力されます。それ以外のときには、属性 hostServer の値と接尾辞.smtp がオリジナルのアドレスに付加されます。例えば、次によう になります（下で、objectName はオブジェクト名、domainName はドメイン名、 hostserver は属性hostServer の値、つまりリモートホスト）。
  objectName%domainName@hostserver.smtp
  上記のアドレスはSMTP モジュールで受け取られ、リモートホスト（ hostserver） の objectName@ domainNameにルートされます。

分散ドメインは、多国籍企業における処理、つまり、社員のアカウントをすべて同一のドメインで管 理したいが、各組織ユニットで専用のサーバーが使用されている場合に有効です。こういった環境で 分散ドメインを使用する場合、DNS MX レコードの内容を分散ドメインをホストするサーバー（いず れかのサーバーまたは全サーバー） に設定します。これで、送信先が分散ドメインであるメールがサー バーで受信されると、サーバーにより、メールがローカルで配信（そのサーバーで宛先のアカウント がホストされている場合）、または、アカウントのディレクトリレコードの属性hostServer で指定され ているサーバーにメールがリレーされます。

分散ドメインを使用する場合、通常、分散ドメイン用のサーバーのうち、いずれか１ つのサーバー（ メ インロケーション） で分散ドメインのアカウントの大半がホストされるようにします。また、そのサー バーに共有ディレクトリを置きます。このようにすることで、ディレクトリ検索による時間的遅延を 最小化できます。これ以外のサーバーは、送信先が分散ドメインの非ローカルオブジェクトであるメー ル（ ローカル以外のメール） がすべて、上記のメインロケーションのサーバーにリルートされるよう に設定します。このリルート処理は、その分散ドメインの［Unknown Names］ パネルの［Mail To Unknown Name］ オプション（ドメイン設定） の値を次のように指定することで設定できます。

Reroute To: *%domain.dom@mainserver.via

上記のリルート処理により、「リモートロケーション」のサーバーとディレクトリの間でアドレスのリ ルートが必要になった場合でも、両者間で通信は行われなくなります。結局、「リモートロケーショ ン」のサーバーとディレクトリとの通信は、分散ドメインでのアカウントの作成や名前の変更、また 分散ドメインからのアカウントの削除が実行された場合、または、WebMail やLDAP を介してユーザー がディレクトリの検索要求を実行した場合に限って実行されるようになります。その結果、とくに、 リモートロケーションのサーバーと共有ディレクトリが置かれているサーバーのリンクが低速または 信頼性が低い場合、リモートロケーションのサーバーの処理速度は大幅に向上します。

非対称、「メイン/ リモートロケーション」のシステムの場合、分散ドメインのMX レコードのうち、 優先度の高いMX レコードの内容をメインロケーションのサーバーに設定しておきます。一方、優先 度の低いMX レコードにリモートロケーションのサーバーの名前を指定します。また、リモートロケー ションのサーバーと共有ディレクトリとの間のリンクが遅いか、信頼性が低い場合、ディレクトリベースのドメインを共有ドメインとして使用することは避けるようにします。

CommuniGate Pro のスタティッククラスタ（静的クラスタ） は、分散ドメインのコンセプトが基礎と なっています。

分散ドメインのサイズが小さい（ユーザー数が少ない） ときには、CommuniGate Pro の ルータレコー ドを使ってルーティングを定義できます。例えば、上記の例の場合（sv1.corp.com、sv2.corp.com、 sv3.corp.com）、SV1 サーバーのルータレコードを次のように定義します。

; SV2 accounts
<dan@corp.dom>  =  dan%corp.dom@sv2.corp.dom.via
<ed@corp.dom>   =   ed%corp.dom@sv2.corp.dom.via
<fred@corp.dom> = fred%corp.dom@sv2.corp.dom.via
;
; SV3 accounts
<gil@corp.dom>  =  gil%corp.dom@sv3.corp.dom.via
<hugh@corp.dom> = hugh%corp.dom@sv3.corp.dom.via
<judy@corp.dom> = judy%corp.dom@sv3.corp.dom.via

上のルータレコードによるルーティングは、ディレクトリには直接処理は発生しませんが、アカウン トの数が多いときにはあまり適当ではありません。それでも、各サーバーでホストされるアカウント 名をルータのワイルドカードを使って簡単に表現できるときには、アカウントの数が多くても利用が 可能です。例えば、サーバーSV2 でホストされるアカウント名がすべて接尾辞-uk で終わる場合 （dan-uk@corp.com、ed-uk@corp.com、fred-uk@corp.com など）、SV2 のアカウントをすべ て、単一のルータレコードを使ってルーティングできます。ルータレコードは次の通りです。

<*-uk@corp.dom> = *-uk%corp.dom@sv2.corp.dom.via

ダイナミッククラスタ環境の場合、クラスタワイドのディレクトリ統合設定が使用されます。つま り、アカウントのうち共有ドメインのアカウントには、クラスタワイドの属性名変更テーブル （ ［Attributes Renaming］ パネル） 、ドメインサブツリー（ ［Domain Subtree］ パネル） 、カスタム設定 （ ［Custom Account Settings］ パネル） の設定が使われます。一方、ローカルのドメインのアカウント については、通常（ ドメインワイド） の設定が使用されます。

WebAdmin インターフェイスでクラスタメンバーの［Directory Integration］ ページを開くと、ページ にリンクが表示されます。このリンクを使って、クラスタワイドのディレクトリ統合設定を変更でき ます。