既存のLDAPサーバでアカウント管理を行われているケースでは、CommuniGate Pro独自のアカウント管理ではなく、既存のLDAPサーバ上のアカウント名／パスワードを利用してCGPにアクセスできるようにしたいというニーズがあります。
ここでは、そういったニーズに対応する方法を紹介します。
１．外部のLDAPサーバに変更があった際に外部側からLDAPコマンドで同期させる方法
デフォルト状態のCommuniGate Proでは、内部的には独自のアカウント管理を行い、それとは別にLDAPで参照されるためだけのLDAPインターフェースを提供しています。
この状態では、仮にldapaddなどを使ってアカウント追加を行った場合でも、LDAPで参照するためのディレクトリ情報にアカウントが追加されるだけで、CommuniGate Proの内部的な独自アカウント管理側に反映されません。
外部からのLDAPコマンドでアカウント追加等を行った場合に、CommuniGate Proの内部的なアカウント管理に正しく反映するための方法の一つとして、CommuniGate Pro自身が、アカウント管理をディレクトリベースで行うように設定したドメインを作成する方法がありますので、その方法を解説します。
ステップ１ 「ディレクトリベースドメイン」の機能の有効化
まず、初期状態では無効になっている「ディレクトリベースドメイン」の機能を有効化します。
管理画面の「アカウント」－「ディレクトリ統合」の「ディレクトリベースドメイン」にある「有効」のボタンを押します。
ステップ２ 「ディレクトリベースのドメイン」としてドメインを作成
管理画面の「アカウント」－「ドメイン」で「ディレクトリベースのドメインの作成」を行います。
ディレクトリベースのドメインは、先頭部分に[D]がついて表示されます。
ステップ３ （内部的な）パスワード記録をクリアテキスト化する
管理画面の「アカウント」－「ドメイン」－「（作成したドメイン）」－「アカウント・デフォルト設定」－「アカウント設定」の「認証」にある「パスワード暗号化」の項目を「クリアテキスト」に変更します。
参考情報① 実際のアカウント追加のノウハウ
ldapaddコマンドを使って、実際にアカウント追加を行う例を例示します。
まず、ldapaddで利用するLDIFのファイルに書くべき内容を示します。
これは、管理画面で単に「test1」というユーザを作り、パスワードだけを追加設定した状態で、ldapsearchコマンドでその情報を取得した場合のアンサです。
[root@localhost ~]# ldapsearch -x -LLL -H ldap://192.168.2.200 -D "postmaster@moriyama-test.lan" -w password -b "cn=directory-base.lan" "(&(uid=test1)(objectclass=*))"
dn: uid=test1,cn=directory-base.lan
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: CommuniGateAccount
cn: none
hostServer: moriyama-test.lan
sn: none
storageLocation: DirectoryDomains/directory-base.lan/test1.macnt
uid: test1
userPassword:: AWVnd2dzf25pCg==
mail: test1@directory-base.lan
|
このアンサに準じて、ユーザ名部分を書き換えたものをLDIFとして使った上で、ldapaddコマンドでtest2というアカウントの追加を実行する例を示します。
先のldapsearchコマンドでは、パスワード部分が暗号化されて表示されていますが、新たなユーザのためのLDIFでは、その部分は、「:」を１つ減らし、クリアテキストで記載します。以下は、その場合のLDIFの内容です。
dn: uid=test2,cn=directory-base.lan
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: CommuniGateAccount
cn: none
hostServer: moriyama-test.lan
sn: none
storageLocation: DirectoryDomains/directory-base.lan/test2.macnt
uid: test2
userPassword: newpassword
mail: test2@directory-base.lan
|
LDIFが出来たら、それを使ってldapaddコマンドでアカウントを追加します。以下はその場合の例です。
[root@localhost ~]# ldapadd -x -H ldap://192.168.2.200 -D "postmaster@moriyama-test.lan" -w password -f /tmp/ldap-test.ldif
adding new entry "uid=test2,cn=directory-base.lan"
|
※CommuniGate Proの内部的なアカウント管理に正しく反映されたことが管理画面でも確認できます
この例では、アカウントのデータ保存場所が指定されていることもあり、階層化構造でアカウント管理する場合などは、CommuniGate Proのアカウント管理構造についての知識が必要です。
ldapdeleteや、ldapmodifyの場合でも、これに準じて使えますので、相応のノウハウをお持ちの方であれば、アカウントの同期の仕組みを実装することに問題はないでしょう。
参考情報② LDAPコマンドを使わず、CLIで外部からアカウント同期を行う方法
CommuniGate Proでは、CLI（コマンドラインインターフェイス API）というものが用意されており、デフォルトではTCP106番ポートでアクセスして専用コマンドを使うことで、CommuniGate Proの持つほとんどの管理機能を外部から実現できるようになっています。
CLIを使ったアカウント管理については、こちらに記載されている、CREATEACCOUNT、DELETEACCOUNT、RENAMEACCOUNT、SETACCOUNTPASSWORD..などのコマンドを使うと、LDAPコマンドより容易にアカウント管理が出来るようになっています。
CLIを使った場合は、アカウントやドメインを階層構造で管理する場合であっても、それを意識することなくアカウント管理が可能であり、ディレクトリベースドメインにしたり、パスワードの内部的管理をクリアテキストにしたりする必要も生じません。
CommuniGate Proをより有効に活用するためにも、可能な限り、CLIを使うことを推奨します。
106番ポートでCLIを使うための、サンプルプログラムを用意しました。（右クリックでダウンロードできます）
これを、Perlが動作する環境に置き、実行権をつけた上で、たとえば、
./exp_perl.pl CGPサーバのIPアドレス postmaster password "LISTACCOUNTS domain-name.lan"
という形で実行すると、domain-name.lanにいる全アカウントのリストが取れます。
CLIを実行しようと思う方の参考になれば幸いです。
２．ユーザの認証時、外部のLDAPサーバのアカウント情報を毎回参照することで行う方法
CommuniGate Proには、アカウントの存在確認や認証について、その都度、外部のLDAPサーバのアカウント／パスワード情報を参照して行うための仕組みが考慮されており、それに必要なプログラムがCommuniGate Systems社から提供されています。
提供されているもののうち、authLDAPNew.pl の機能を使うと、以下のような動きが実現されます。
- メール着信時、その宛先のアカウントが存在していない場合、その名前のアカウントが存在するか否かを外部のLDAPサーバに確認しに行き、存在するなら、そのアカウント用に必要なフォルダ構造等を作成して受信を行う。存在しなければ着信を拒否する。
- ユーザがログインしてきたとき、そのアカウントの存在と、パスワードの整合性を、外部のLDAPサーバに確認しに行き、ログインの可否を判断する
以下に、authLDAPNew.pl を使う場合の例を紹介します。
ステップ１ 外部認証プログラムの準備
- CommuniGate Systems社のCommuniGate Pro Perl Interfaceのページから、CLI.pmをダウンロードする。
- CommuniGate Systems社のCommuniGate Pro External Authenticationのページから、authLDAPNew.plをダウンロードする。
authLDAPNew.plのカスタマイズを行う
authLDAPNew.plは、あくまでサンプルの状態であり、実情に合わせた書き換えが必要です。
一般に、先頭付近にある「my @ldap_servers」の定義部分（address, adminDN, adminPassword, searchBase は書き換え、127.0.0.2の側は一般に不要なので構造ごと削除可）と、「my $CLIPassword」の定義部分は変更が必須です。
また、末尾近くの「$realName=@$vals[0] if($type eq 'cn');」の部分を「$realName=@$vals[0] if($type eq 'sAMAccountName');」に書き換える必要がある場合もあるでしょう。
相応のLDAPの知識と、Perlの知識をお持ちの方が、実環境向けの検証を実施した上で書き換える必要があります。
※お読みになればわかるとおり、「userPassword」がクリアテキストで返される必要がありますので、そのような運用が許されないケースでは、このプログラムを使った外部認証は成立しません。
- Perl内部で、 Net::LDAP を使うため、必要があれば、CommuniGate Proの動作するサーバ上に perl-ldap を導入する。
※その他 CLI.pm と authLDAPNew.pl 内部で使われるもので不足な部分があれば全て導入する。（例：Convert-ASN1）
- 適切なフォルダ（例：/var/CommuniGate/authLDAP）を作成し、そこに CLI.pm と authLDAPNew.pl を置いて実行権をつける。
ステップ２ 外部認証プログラムの登録
管理画面の「設定」－「全般」－「ヘルパー」の「外部認証」のチェックを入れ、プログラムパスを記述します。
パスは、/var/CommuniGateからの相対パス、またはフルパスで記述してください
ステップ３ 外部認証連携の有効化
管理画面の「アカウント」－「ドメイン」－「（対象のドメイン）」－「ドメイン設定」の「不明な名前」にある「未知のアドレスに対する外部認証連携」の選択肢で「はい」を選択する。
以上で設定完了です。ただし、これだけだと以下の問題が生じます。
- アカウントが削除されても、CommuniGate Proの内部的アカウントは残ってしまう。
- アカウントがリネームされたとき、旧アカウント名のアカウントがCommuniGate Proの内部アカウントとして残り続け、新アカウント名の宛先にメールが着信したとき、あるいはそのユーザが新アカウントでログインしたときに、新アカウント名でCommuniGate Proのアカウントが新たなアカウントとして作成される。
アカウント削除やアカウントリネームが必要な際は、CommuniGate Proの管理インターフェースでも操作を行うか、LDAPやCLIで外部からその操作と同じ処理を実行する必要が生じますので、そのような配慮を忘れないようご注意ください。
CommuniGate Systems社のサポートページ内にあるQ&A、「LDAP Authentication against an Active Directory server」も参考になります。
|
|
