LDAPを介した許可を伴うejabberd

長い間、後悔することなく、私はICQと別れました。 この機会を利用して、私は自分のJabberサーバーを作成しました。 ただし、すべての従業員がJabberアカウントを持っているわけではありません(誰もがそれを知っているわけでもありません:-)。 他のユーザーと通信し、安全で独立したメッセージングシステムを編成するために、企業のジャバーサーバーを設置することにしました。 また、LDAPを積極的に使用しているため、ユーザーの認証とアカウントの管理にLDAPを使用することは理にかなっています。





ソースデータ



-OS:FreeBSD 5.4

-company.ruドメインを持つ当社のサイトを含む、サーバー上にいくつかのサイトがあります(自己宣伝で告発されないように、名前が変更されます:-)

-ldap.company.local上のLDAPサーバー(当社のサーバーはcompany.localのローカルネットワークに接続されています)

-ejabberd 1.1.4_2(インストール時のFreeBSDポートの最新バージョン)



このノートで示されているすべてのパスはFreeBSDに固有のものであり、他のシステムでは異なる場合があります。



設置



FreeBSDポートからejabberdを問題なくインストールしました。 ejabberd Handbookで他のシステムへのインストールについて読んでください。



カスタマイズ



ejabberdが設定でどのように機能するかを理解することが重要です。 彼には2つのソースがあります。

  1. 現在の構成のDB(/ var / spool / ejabberd /)
  2. テキストファイル(/ usr / local / etc / ejabbrd /)
管理用のWebインターフェイスもあります。 だから:

これから2つの重要な結論を引き出す必要があります。

  1. ejabberdを再起動すると、Webインターフェースで行った変更が失われる場合があります
  2. 構成ファイルに加えられた変更は、ejabberdの構成に影響しない場合があります
これを理解することは、頭の上の多くの時間、神経と髪を節約します。



構成ファイルの構文について少し



コメントは%文字で始まり、行末で終わります。



チームはピリオドで終了する必要があります。



パラメーターは次のように示されます。



 {パラメーター、値}


リストは角括弧で示されます。 リスト項目はコンマで区切られます。 最後の要素の後に、コンマは置かれません。



これで初めてです。



初期設定



初期セットアップは、ファイル/usr/local/etc/ejabberd/ejabberd.cfg



編集することにより行われます。



最初のステップは、構成のどの部分(データベースに格納されている)を変更するかを示すことです。 これには3つのコマンドがあります。

設定の編集ではなく、表示のみにWebインターフェースを使用するため、すべての設定をファイルから取得します。すべてをクリアします。



 override_global。
 override_local。
 override_acls


ポートとサービス



次のステップは、ejabberdサービスをTCPポートにバインドし、これらのサービスを構成することです。 合計で4つのサービス(またはモジュール)があります。



ここに私が得たものがあります:



 {聞く、[

   %クライアントサーバー
   {5222、ejabberd_c2s、[
     starttls、{certfile、 "./server.pem"}% StartTLSを使用します。 証明書パスは相対を示しま​​す
                                           %構成ファイル。 後でserver.pem証明書を作成します。
   ]}、

   %サーバーサーバー。 ドメイン内だけでなく通信したい場合
   {5269、ejabberd_s2s_in、[
   ]}、

   %HTTPサービス
   {5280、ejabberd_http、[
     web_admin%Webインターフェイスを提供します
   ]}

 ]}。


相互に通信するだけでなく、他のサーバーのユーザーとも通信する場合、s2s接続を追加で構成する必要があります。



 {s2s_use_starttls、true}。  %サーバー間通信にStartTLSを使用する
 {s2s_certfile、 "/usr/local/etc/ejabberd/server.pem"}。  %証明書。 後で作成します。
 {outgoing_s2s_port、5269}。  %私はそれが何であるかを正確に知りませんが、それなしでは私にはうまくいきませんでした:-)




Webインターフェースにアクセスするには、管理者アクセスリストを追加し、そのメンバーが構成にアクセスできるようにし、このリストに自分を追加します。



 {acl、admins、{user、 "my_login"、 "company.ru"}}。  %adminsは任意のリスト名、my_loginは私のLDAPアカウント、
                                         %company.ru-サーバーが実行される仮想ドメイン
 {アクセス、構成、[{許可、管理者}]}。  %configure-サーバーを構成する許可、admins-リスト名


ドメイン設定



ejabberdは、異なる構成の複数の仮想ドメインを提供できます。 リストにはドメインが1つしかありません。



 {hosts、["company.ru"]}。


このドメインにのみ指定するその他のすべてのパラメーター:



 {host_config、 "company.ru"、[
 ...ここでは、company.ruホストのパラメーターを示します...
 ]}。




LDAP接続





仮想ホストにコマンドを追加します。



 {auth_method、ldap}、%認証方法-LDAP
 {ldap_servers、["ldap.company.local"]}、%LDAPサーバーアドレス
 {ldap_port、389}、%そのポート
 {ldap_base、 "ou = people、dc = company、dc = local"}%ユーザーアカウントのベースDN


証明書の作成



SSLを使用するには、証明書が必要です。



構成ファイルのディレクトリ(/ usr / local / etc / ejabberd)で、次のコマンドを実行します。

 $ openssl req -newkey rsa:1024 -keyout server.pem -nodes -x509 -days 3650 -out server.cer
 $ echo "" >> server.pem
 $ cat server.cer >> server.pem
 $ chown ejabberd:ejabberd server.pem
 $ chmod 0400 server.pem




その後、server.cerファイルを簡単に削除できます。



最初の打ち上げ



この構成は、サーバーをテストするのに十分です。 /usr/local/etc/rc.d/ejabberd start



を実行し、ログ/var/log/ejabberd/sasl.log



を確認します。 CRASH REPORTエントリが含まれていない場合、サーバーは正常に起動しました。 検証のために、ログインmy_login@company.ru(my_loginは私のLDAPログイン、company.ruはejabberdに登録された仮想ホスト)を使用してcompany.ru Jabberクライアントに接続でき、パスワードはLDAPからのものです。 これが失敗した場合、LDAP、ldap_base、そしてもちろんログとの接続を確認する必要があります。



私は最初の試行で成功しました。 次に、Webインターフェースを試してください。 私の構成では、次の場所にあります。

  http://company.ru:5280/admin/ 


認証のために、Jabberクライアントを使用するときと同じデータを指定する必要があります。



ここでは、「仮想ホスト-company.ru-ユーザー」に移動して、このジャバーサーバーを使用できるユーザーのリストを表示できます。



UPD :リストを表示するには、ホスト構成に次の行を追加します。

 {モジュール、[
   {mod_last、[]}、
   {mod_offline、[]}
 ]}




おわりに



新しいプログラムまたはテクノロジーを使用する場合、最も難しいことは開始することです。 個人的には、最初は構成ファイルの例に混乱し、通常とは異なる構文とサイズに混乱しました。 そして、ドキュメントも認めます。 したがって、少なくともサーバーを起動して接続できる最小限の構成を作成しようとしました。 稼働中のサーバーを手に入れると、それをさらに構成し、モジュールをマウントし、調整などを行うことができます。 主なものは、足の下のしっかりした土台です。



近い将来、さらなるカスタマイズについて書くために手を伸ばすことを願っています。 または、おそらく他の誰かがそれを行うでしょう;-)



結果の構成



 %
共有オプションの割合
 %

 %すべての設定を上書き

 override_global。
 override_local。
 override_acls


 %ポートとサービス
 {聞く、[

         %クライアントからサーバー
         {5222、ejabberd_c2s、[
                 starttls、{certfile、「/ usr / local / etc / ejabberd / server.pem」}
         ]}、

         %サーバー間
         {5269、ejabberd_s2s_in、[
         ]}、

         %HTTPサービス
         {5280、ejabberd_http、[
                 web_admin
         ]}

 ]}。

 %S2S接続にSTARTTLS +ダイヤルバックを使用
 {s2s_use_starttls、true}。
 {s2s_certfile、 "/usr/local/etc/ejabberd/server.pem"}。

 %SRVルックアップが失敗した場合、ポート5269はリモートサーバーとの通信に使用されます
 {outgoing_s2s_port、5269}。

 Webadminアクセスの割合
 {acl、admins、{user、 "my_login"、 "company.ru"}}。
 {アクセス、構成、[{許可、管理者}]}。


 %ホスト構成

 {hosts、["company.ru"]}。

 %
 %ホスト:company.ru
 %

 {host_config、 "company.ru"、[

         {auth_method、ldap}、
         {ldap_servers、["ldap.company.local"]}、
         {ldap_port、389}、
         {ldap_base、「ou = people、dc = 3wstyle、dc = local」}

 ]}。




いくつかのコメント



時々、クラッシュ後、ejabberdは起動を拒否します。 beamおよびempdプロセスまたは他のアーランアプリケーションがハングしているかどうかを確認します。



Webインターフェイスを介してすべての仮想ドメインを管理するには、{access、configure、...}エントリは、仮想ホスト構成ではなく、グローバルスコープに配置する必要があります。



LDAPバックエンドを使用する場合、クライアント 「プレーンテキストログインを許可する」オプション(プレーンテキストでの許可を許可する)を含める必要があります。 UPD: SSLが使用されている場合、これはパスワードセキュリティリスクではありません。 この場合、サーバーとの暗号化された接続が最初に確立され、次にオープンパスワードが送信されます。 たとえば、Psiクライアントでは、これは次のように構成されます。接続の暗号化:常に。 プレーンテキスト認証を許可する:暗号化された接続で。



参照資料






All Articles