LDAP モジュール

CommuniGate Pro のLDAP モジュールを介して、 ディレクトリツリーと、そのレコードにアクセスが可能です。

なお、CommuniGate Pro のLDAP モジュール自体には、ディレクトリサービスへのアクセス機能はあ りません。LDAP モジュールはアクセスプロトコルとして動作するだけであり、実際のアクセスは、 CommuniGate Pro のディレクトリマネージャ（および、そのユニット） によって実行されます。

LDAP サービスの主な用途は、サーバーのユーザーの名前と電子メールアドレスの検索です。ただし、 LDAP モジュールを介してディレクトリツリーにアクセスできるため、CommuniGate Pro ディレクト リにデータを格納する場合にも利用できます。また、CommuniGate Pro ディレクトリは複数の異なる ストレージユニット（ ローカルまたはリモート） に格納できますが、その場合でも、LDAP クライア ントではCommuniGate Pro ディレクトリ全体が単一のツリーとして表示されるため、ディレクトリ全 体の確認が可能です。

システム管理者は、LDAP クライアント/ ユーティリティを使って、CommuniGate Pro ディレクトリ を表示し、内容を変更することができます。また、CommuniGate Pro のWebAdmin インターフェイス に用意されているディレクトリブラウザインターフェイスを使って、同様の操作を行うこともできま す。

注意: LDAP モジュールは、LDAP サーバーとして機能しますが、CommuniGate Pro サーバー自体を LDAP クライアントとして使用することもできます。つまり、CommuniGate Pro サーバーからLDAP プロトコルを介して、外部LDAP サーバーとデータベースにアクセスすることもできます。その場 合、外部ディレクトリは、CommuniGate Pro ディレクトリツリーのサブツリーとして表示されます。 外部ディレクトリについては、詳しくはリモートユニットの説明を参照してください。

ログレベル

このオプションでは、LDAP モジュールによってサーバーログに記録される情報の範囲（ ログ レベル） を指定できます。通常、このオプションは［Major］ または［Problems］ （非致命的エ ラー） にしておきます。一方、LDAP モジュールに問題が発生していると思われるときには、 ［Low-Level］ または［All Info］ に設定します。この場合、それぞれ、プロトコルレベルの情報 またはリンクレベルの情報がシステムログに記録されます。

LDAP モジュールによって記録されたログにはLDAP タグが付加されます。なお、LDAP はバ イナリプロトコルであるため、低レベルのデータはすべて16 進数で表示されます。

チャネル

このオプションでは、LDAP モジュールで使用されるTCP/IP チャンネルの最大数を指定できま す。この数は、LDAP モジュールが作成できる「リスナー」の最大数です。メールクライアント から送られたLDAP 接続要求がLDAP モジュールで処理される際、最大で、ここで指定した数 の接続（同時接続） が使用されます。オープンしている受信接続が、この数に達していたとき には、新規の接続は拒否されます。その場合、ユーザーは再度、接続を実行しなければなりま せん。
この最大チャンネル数を0 に設定しておいた場合、LDAP モジュールのリスナーが閉鎖される と同時に、TCP ポートが解放（拘束解除） されます。

リスナー

LDAP モジュールのリスナーは、デフォルトでは、クリアテキスト接続の場合はTCP ポート 389、セキュア接続の場合はTCP ポート636 です。このLDAP の リスナーのポートは、変更が 可能です。変更する場合、［listener］ リンクをクリックします。

注意:バージョン4.7 より前のNetscape LDAP クライアントは、サーバーが非常に高速で、しかも返 却レコード数が90 を超えるような場合、クラッシュします。この問題が発生するときには、Netscape/ ブラウザ/ メーラーを4.7 以降のバージョンに更新します。

注意:Netscape LDAP クライアント（バージョン4.7） では、「プロパティ」コマンドは正常に動作し ません。この問題は、このバージョンのクライアントの場合、必ずポート389 に対して接続が実行さ れるためです。この動作は、別のポート（例えば、セキュアポート） を使って検索が実行され、その 処理が成功したときでも、同じくポート389 が使われます。

場合によっては、検索処理で、「サーチベースDN （ディレクトリ名）」としてCommuniGate Pro ディ レクトリツリーのルート（空白の文字列） を指定しなければならないこともあります。その場合、 LDAP クライアントによっては、処理が正常に実行されないことがあります（例えば、Microsoft LDAP クライアントでは、空白の文字列を指定すると、その文字列がc=your_country に置き換えられま す）。
上記の場合、サーチベース文字列（DN） として文字列top を指定します。これで、その文字列 （top） が空白の文字列（つまり、CommuniGate Pro ディレクトリのルート） として解釈されます。

ディレクトリアクセス権は、CommuniGate Pro のアカウント名ではなく「バインドDN」をもとにし たアクセス権です。つまり、バインドDN を使って認証が行われます。ディレクトリアクセス権につ いては、ディレクトリマネージャの アクセス権の説明を参照してください。

デフォルトのディレクトリアクセス権の設定では、ディレクトリクライアント（LDAP クライアン ト） による処理がディレクトリツリーのデータの取り出しのときには、LDAP クライアントの認証は 不要です。処理がデータの取り出し以外の場合、下記のように認証が行われます。

LDAP クライアントで認証の文字列としてDN が指定されている場合、LDAP サーバー（モジュール） により、ディレクトリ（CommuniGate Pro ディレクトリ） のレコードのうち、指定されているDN の レコードが取り出され、そのレコードと、LDAP クライアントから提供されたパスワードの userPassword 属性が比較されます。そのレコードが存在し、そのレコードにuserPassword 属性 があり、しかも、その属性の値がLDAP クライアントから提供された値（パスワード） と同じであ れば、LDAP クライアントの認証は成功します。

一方、LDAP クライアントで、認証情報としてDN ではなくCommuniGate Pro のアカウント（ とパス ワード） が指定されている場合、そのアカウントがCommuniGate Pro サーバーによってオープンさ れ、そのアカウントのパスワードとLDAP クライアントから提供されたパスワードが比較されます。 ここでパスワードが同じであれば、そのアカウントのレコードのDN がディレクトリベースのドメ イン設定を使って作成され、そのDN がバインドDN （Bind DN） として使用されます。

ディレクトリ統合設定の内容が次の設定だったとします。

ベースDN:		o=myCompany
ドメインRDN属性:		cn

また、LDAP クライアントから送られたユーザー名がuser@domain.dom で、そのパスワードも 正しかったとします。その場合、次のバインドDN を使ってLDAP クライアントが認証されま す。
uid=user,cn=domain.dom,o=myCompany
認証後、LDAP クライアントは、ディレクトリの情報のうち、そのバインドDN で許可されて いる情報にアクセスできます。

LDAP クライアントから提供された文字列に等号（=） が含まれていなかった場合、または、文字列 がmail= で始まり、その等号以外に等号がなかった場合、上記の2 種類の認証方式のうち後者の方 式（アカウントによる方法） が使用されます。

ドメインまたはアカウントのLDAP サービスを無効にすると、上記の認証処理は実行されなくなります。

上記の認証は、［LDAP Provisioning］ オプション（LDAP プロビジョニング） の設定とも関係してい ます。つまり、このオプションを有効にしておいた場合、LDAP クライアントから提供されたDN （バインドDN） がCommuniGate Pro のいずれかのアカウントのDN と同じだったときには、DN が、 そのアカウント名に変換されます。その後、上記の認証方式のうち後者の方式（アカウントによる方 法） を使って処理が行われます。

指定されているバインドDN 文字列	パスワードの検証に使われるデータ
uid=user,cn=domain.dom,o=myCompany (LDAP Provisioning is off)	uid=user,cn=domain.dom,o=myCompany（ディレクトリレコード）のuserPassword 属性
ou=human_resources,o=myCompany	ou=human_resources,o=myCompany（ディレクトリレコード）のuserPassword 属性
user@domain.com	アカウントuser@domain.dom のパスワード
mail=user@domain.com	アカウントuser@domain.dom のパスワード
uid=user,cn=domain.dom,o=myCompany (LDAP プロビジョニング有効）	アカウントuser@domain.dom のパスワード

LDAP モジュールでは、CommuniGate Pro サーバーでサポートされている認証方式はすべてサポート されています。

上記の認証方式のうち後者の方式（アカウントによる方法） が使用され、また、LDAP クライアント で指定されているアカウントに［Directory Administrator］ （ディレクトリ管理者） アクセス権が付与 されている場合、そのLDAP クライアント（ユーザー） は、ディレクトリの全データにアクセスし、 データを変更することができます（マスタータイプアクセス）。

LDAP サービスの主な用途は、CommuniGate Pro のアカウント、またCommuniGate Pro のドメインのオブジェクトに関する情報の検索です。

CommuniGate Pro のドメインのオブジェクト（アカウント、グループ、メーリングリスト） を検索す る場合、LDAP クライアントで、そのオブジェクトが置かれているサブツリーを検索場所として指定 します（パラメータを使って指定でき、このパラメータは各LDAP クライアントで「サーチベース」 パラメータと呼ばれています）。 例えば、検索対象のサブツリーがドメインcompany.com の場合、サーチベースとして cn=company.com,o=MyCompany と指定します。ここで、cn はドメインRDN 属性、o=MyCompany は ドメインのベースDN です。ベースDN とドメインRDN 属性はどちらもディレクトリベースのドメ イン設定で（上記の例を参照）、変更が可能です。ベースDN とドメインRDN 属性を変更した場合 （例えば、サブツリーの場所を変更した場合）、その変更に見合うようにLDAP クライアントのサー チベースを再設定しなければなりません。

デフォルトの設定では、LDAP モジュールを介してCommuniGate Pro システムに新規のアカウントを 作成することはできません。これは、アカウントマネージャとCommuniGate Pro ディレクトリの関 係が一方向であるためです。つまり、アカウントマネージャによってアカウントの作成や削除、名前 の変更などが行われると、ディレクトリは更新されます（ディレクトリベースのドメイン設定で ［Keep In Sync］ オプションが有効になっている場合）。これに対し、ディレクトリのレコードが変更 されても、その変更はアカウントマネージャには伝わりません。

上記の処理（アカウントの操作） は、LDAP プロトコルを使って行うことができます。この処理は LDAP プロビジョニングと呼ばれています。LDAP プロビジョニングとしては、2 種類があります。 １ つは、ディレクトリベースドメインLDAP プロビジョニングです。従来の古いメッセージングシステムで使われているLDAP プロビジョニングで、このプロビジョニングは互換性とデータの移行 を考慮してCommuniGate Pro でサポートされています。 もう１ つは、最近の新しいプロビジョニングで、ダイレクトLDAP プロビジョニングと呼ばれてい ます。このプロビジョニングでは（［LDAP direct Provisioning］ オプションが有効の場合）、LDAP モ ジュールによって変更要求とバインド要求が別個に処理されます。つまり、変更要求に指定されてい るDN が、CommuniGate Pro のアカウントに対応する（または、対応すると思われる） ディレクトリ レコードのDN に「類似」していた場合、ディレクトリに対する処理は一切、行われません。代わり に、LDAP モジュールからアカウントマネージャに直接コマンドが送信され、アカウントマネージャ で、バインド要求に指定されているアカウントの作成や削除、名前の変更、更新が実行されます。こ の処理については、詳しくは「ディレクトリへの統合」のセクションを参照してください。