389 DS  
  HOME Next
オフィシャルサイト： 389 Directory Server

389 Directory Server

ネット上ではまだ 389 Directory Server よりも旧名の Fedora Directory Server (Fedora DS) のほうが通りがいいかもしれない。その歴史はきわめて複雑だ。389 DS の直接の先祖は Netscape Directory Server だ。その後 Netscape社は AOL に買収されるわけだが、それと相前後して Netscape は Sun と共同で iPlanet ブランドを立ち上げており、そこで iPlanet Directory Server が分岐。やがて AOL が iPlanet ブランドを放棄すると、iPlanet は Sun のブランドとなり、そこから Sun Java System Directory Server が派生した。2004年、Red Hat は AOL から Netsape DS を買い取り Ferora Directory Server としてオープンソース化、2009年に現在の 389 Directory Server の名前になった。つまり、ここに名前の挙がったディレクトリサーバは全て親戚以上の血縁がある。特に、この文書を書くにあたって Netscape DS 関係の文書や iPlanet DS の管理者ガイドが役に立つ場面も多かったことから、389 DS とそれら 2つは実装的にかなり近いものと思われる。

OpenLDAP との違いは、ACL をはじめ設定のほとんどをディレクトリデータとして管理していること、マルチマスタレプリケーションに対応していることなど。高度な設定や重作業は、付属の Javaベース設定クライアントから GUI でできる。設定クライアントソフトには Windows 版もある。また、ブラウザでアクセスできる Directory Server Gateway (DSGW) という WEBベースの設定インターフェイスを使うと、日常のエントリ登録や検索を簡単に行うことができる。

検証環境は CentOS 5.4 ～ 5.6 の x86_64 (KVM上の仮想サーバ)。389 DS のバージョンは 1.1.3 と 1.2.1。

Table of Contents

インストールとデプロイ

サーバの搭載メモリは最低 1GB 必要。その他の要件は Red Hat DS の Installation Guide を参照のこと。

パッケージのインストール

インストールは yum で行う。CentOS 5.6 上では install guide に書いてある通りに EPEL のレポジトリからインストールして問題なく動作した。それに対して、CentOS 5.4/5.5 では、そうしてインストールするとインスタンスのデプロイでエラーが出て成り立たなかったため、Download ページの "Old EL5 Package instructions" という節にある、Fedora Core 6 向けパッケージを使うやり方でインストールを行った。

Java SDK のインストール

root# yum install java-1.6.0-openjdk

Repoファイルのインストール

CentOS 5.6 の場合

(表示の都合でURLを途中で折り返しています)

root# rpm -ivh \
 http://download.fedora.redhat.com/pub/epel/5/i386\
/epel-release-5-4.noarch.rpm
CentOS 5.5 以前の場合

Fedora Core 6 用の古いレポジトリから Repo ファイルをダウンロードする。もはやあまり多くのトラフィックを想定していないのか、接続やダウンロードに少々時間がかかることがある。

root# wget -O - http://port389.org/sources/idmcommon.repo | \
     sed -e 's/$releasever/6/g;' > /etc/yum.repos.d/idmcommon.repo
root# wget -O - http://port389.org/sources/dirsrv.repo | \
     sed -e 's/$releasever/6/g;' > /etc/yum.repos.d/dirsrv.repo

この後 dirsrv-testing レポジトリからパッケージをインストールをしようとするとシグナチャチェックに失敗するようなので、dirsrv.repo ファイルを修正。[dirsrv-testing] の定義ブロックに gpgcheck=0 という行を追加する。

シグナチャのインポート

CenetOS 5.5 以前のみ
root# rpm --import '
     http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7B02652'

インストール

CentOS 5.6 の場合
root# yum install 389-ds
CentOS 5.5 以前の場合
root# yum --enablerepo=idmcommon-testing \
          --enablerepo=dirsrv-testing install 389-ds
root# yum --enablerepo=idmcommon-testing \
          --enablerepo=dirsrv-testing upgrade 389-ds-base 389-admin

デプロイの準備

LDAPサーバ及び管理サーバの配備のためのシステム環境を整えておく。

リゾルバの整備

389 DS では管理サーバに接続する際に名前解決がきちんとできていないとうまくいかない。RedHat 系ではデフォルトの /etc/hosts ファイルが、

127.0.0.1    localhost.localdomain localhost centos5u.hoge.com centos5u

のようになってしまっているので、きちんと、

127.0.0.1    localhost.localdomain localhost
x.x.x.x      centos5u.hoge.com centos5u

のように整形しておく。イントラ環境に DNSサーバがあり設定が自由になるなら、DNS にもレコードを登録し、それが牽けるように /etc/resolv.conf も整備しておいたほうが、389 DS 管理サーバの余計なエラーログが幾分かでも減らせる。

LDAPサーバ実行ユーザの作成

デフォルトではディレクトリサーバデーモンは nobody 権限で実行するようになっているが、セキュリティ向上のため専用のユーザで動作させたほうが良いので、あらかじめ作成しておく。通常のデプロイでは、管理サーバの httpd プロセスもこのユーザの権限で動くことになる。ユーザ名や UID, GID はこの通りである必要はない。

root# groupadd -g 7000 dsadmin
root# useradd -u 7000 -g dsadmin dsadmin

ファイルディスクリプタ数上限の拡張

解説は 389 DS の Performance Tuning のページを参照。

/etc/security/limits.conf に以下の行を追記；

*                soft    nofile          8192
*                hard    nofile          8192

/etc/profile に下記を追加；

ulimit -n 8192

389 DS のディレクトリサーバと管理サーバの起動パラメータをこれらに合わせる。/etc/sysconfig/dirsrv, dirsrv-admin 両ファイルの、

#ulimit -n 8192

のコメント記号 `#' を外す。なお、Proc の値 fs.file-max (システム全体のファイルディスクリプタ上限数) はたいてい元々充分取られているので変更の必要はない。

ネットワークパラメータの調整

解説は 389 DS の Performance Tuning のページにあり。

/etc/sysctl.conf に下記を追加；

net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_keepalive_time = 1800

mozldap版LDAPコマンドパスを PATH に追加

389 DS に対しては、mozldap-tools パッケージによってインストールされたほうの ldapmodify や ldapsearch などを使うことが推奨されている。しかし、OpenLDAP 用の同等ツールがインストールされていると、mozldap 版のツール使う時にいちいちフルパスでコマンドしなくてはならない。それでは効率が悪いので、新しいパスが PATH 環境変数の前の方に登録されるよう、/etc/profile.d/ 下に下記内容のファイル mozldap-tools.sh (ファイル名は任意。root:root 755) を新規に作成する。

if ! echo ${PATH} | /bin/grep -q /usr/lib64/mozldap ; then
        PATH=/usr/lib64/mozldap:${PATH}
fi

サーバを起動したまま環境変数や sysctl 値を個別に反映させることも可能ではあるが、再起動しても問題のないサーバならここで一度リブートしておくほうがいいだろう。

デプロイ

実際の ディレクトリサーバインスタンスと管理/設定サーバをセットアップする。

ディレクトリサーバと管理サーバのデプロイ

デプロイでは、Administration Server と呼ばれる管理サーバと、実際にデータの入れ物となるディレクトリサーバインスタンスが作成される。更に言えば、ディレクトリサーバの中には、設定データを管理する NetscapeRoot (o=NetscapeRoot) ディレクトリツリーと、実運用データ用のディレクトリツリー (例えば dc=hoge,dc=com) のふたつが格納される。セットアップを始めるには、

root# setup-ds-admin.pl

セットアップは対話式で進む。以下、要所だけ抜粋；

==============================================================================
This program will set up the 389 Directory and Administration Servers.
 
It is recommended that you have "root" privilege to set up the software.
Tips for using this program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" then "Enter" to go back to the previous screen
  - Type "Control-C" to cancel the setup program
 
Would you like to continue with set up? [yes]: y
 
Do you agree to the license terms? [no]: y
 
==============================================================================
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.
 
389 Directory Server system tuning analysis version 10-AUGUST-2007.
 
NOTICE : System is x86_64-unknown-linux2.6.18-194.32.1.el5 (1 processor).
 
WARNING: 1002MB of physical memory is available on the system. 1024MB is 
recommended for best performance on large production system.
 
NOTICE : The net.ipv4.tcp_keepalive_time is set to 1800000 milliseconds
(30 minutes).  This may cause temporary server congestion from lost
client connections.
 
WARNING  : The warning messages above should be reviewed before proceeding.
 
Would you like to continue? [no]: y
 
==============================================================================
Choose a setup type:
 
   1. Express
       Allows you to quickly set up the servers using the most
       common options and pre-defined defaults. Useful for quick
       evaluation of the products.
 
   2. Typical
       Allows you to specify common defaults and options.
 
   3. Custom
       Allows you to specify more advanced options. This is 
       recommended for experienced server administrators only.
 
Choose a setup type [2]: 2
 
Computer name [centos5u.hoge.com]: <TCP/IPホスト名。通常はそのままEnter>
 
System User [nobody]: dsadmin <「デプロイの準備」で作っておいたシステムユーザ>
System Group [nobody]: dsadmin <そのグループ>
 
Do you want to register this software with an existing
configuration directory server? [no]: n
 
Configuration directory server
administrator ID [admin]: <管理サーバのスーパーユーザ>
Password: ****
Password (confirm): ****
 
Administration Domain [hoge.com]: <通常はサーバホストのTCP/IPドメイン。同一Domianの389DSサーバは集中管理できるらしい>
 
Directory server network port [389]: <通常はそのままEnter>
 
Directory server identifier [centos5u]: <ディレクトリサーバのインスタンス名。自由に付けてよい>
 
Suffix [dc=hoge, dc=com]: <このディレクトリサーバで扱うディレクトリサフィックス>
 
Directory Manager DN [cn=Directory Manager]: <ディレクトリマネージャのDN。dc などサフィックスはない>
Password: ****
Password (confirm): ****
 
Administration port [9830]: <管理サーバのHTTPリッスンポート>
 
Are you ready to set up your servers? [yes]: y
デプロイをやり直すには

管理サーバとディレクトリサーバインスタンスを両方とも消すやり方と、ディレクトリインスタンスだけを削除するやり方がある。
ディレクトリインスタンスの削除のみの場合は、

root# remove-ds.pl -d -i slapd-<INSTANCE_NAME>

`-i' の引数はインスタンス名で、前述のデプロイ例のインスタンスなら `-i slapd-centos5u' とする。`-d' はデバグの意。
管理サーバも一緒に削除するなら、

root# remove-ds-admin.pl -d -y

いずれも、ディレクトリインスタンスの設定フォルダ /etc/dirsrv/slapd-<INSTANCE_NAME>/ が slapd-<INSTANCE_NAME>.removed/ にリネームされて残る。再デプロイに備えて、旧設定フォルダは削除するかどこか全く別の場所へ退避させたほうがよい。

なお、ディレクトリインスタンスだけを削除した場合は、再デプロイの時、setup-ds-admin.pl の途中の 「既存の管理サーバへ登録するか」の問い に y で答えなければならない(後述の「ディレクトリサーバのマルチインスタンス化」での例が参考になるはず)。また、代わりに setup-ds.pl コマンドを使ってもよい。setup-ds.pl では、管理サーバは新規に作成せずに、ディレクトリインスタンスだけをデプロイすることができる。ただし、再デプロイ後に管理サーバデーモンを再起動 (`service dirsrv-admin restart') しても 389 Management Console からディレクトリインスタンスが見えないかもしれない。その場合は register-ds-admin.pl コマンドでインスタンスを管理サーバに登録してやり、管理サーバデーモンを再度リスタートすれば見えるようになるはずだ。

基本的な動作テスト

デプロイがうまくいけば、管理サーバとディレクトリサーバが既に起動され、それぞれ TCPポートの 9830 と 389 をリッスンしているはずなので確認；

root# netstat -l -n -t

いろいろいじくり始める前に、ここでとりあえず接続できることを確認しておこう。

389 Management Console (Javaアプリ)
user$ 389-console
スプラッシュスクリーンとともに、左のようなログインウィンドウが出る。デプロイ時に設定したディレクトリマネージャの DN とパスワードと、管理サーバの HTTPアドレスを入れて OK ボタンを押せば、
マネージメントコンソールが開くはずだ。
なお、スプラッシュスクリーンが邪魔なら、389-console コマンドに `-x nologo' オプションを付けて起動すればいい (※Windows版の場合は備考参照)。

※ Windows版 389 Management Console でスプラッシュ画面を非表示にするには、C:\Program Files\389 Management Console\389-console.bat をエディタで開き、末尾付近にある `"%JAVA%"' で始まる長～いコマンドの最後を `... com.netscape.management.client.console.Console -x nologo %*' としておけばいい。

WEBベースの Management Console

サーバホスト自体の上からブラウザで接続してみる。URL は、

http://localhost:9830/
ldapsearchコマンドで検索

mozldap-tools の ldapsearch で検索を掛けてみる。OpenLDAP の ldapsearch とはオプションが少々異なる。

user$ ldapsearch -D "cn=Directory Manager" -w - \
   -b "dc=hoge,dc=com" 'objectclass=*'
Enter bind password: ****

Directory Server Gatewayのセットアップ

あらゆる管理やデータ登録/編集/検索は Java版の 389 Management Console からできるのだが、簡単な操作で検索や登録のできる LDAPオブジェクトクラスは極限られた既定のものだけだ。例えば、mailRecipient オブジェクトクラスはスキーマとしては元々 389 DS に含まれているものの、Java版マネージメントコンソールからでは非常に煩雑な手順を踏まないとエントリ登録も検索もできない。Javaアプリケーションのコードをいじればカスタマイズは可能らしいが敷居が高い。そこで利用したいのが、Directory Server Gateway (パッケージ名 389-dsgw) だ。これは、管理サーバの WEBインターフェイスの追加モジュールとして働く CGI で、カスタマイズも Javaアプリケーションを書くよりは楽だ。

Directory Server Gateway は 389 DS のインストール時に依存関係によって一緒にインストールされるが、使用できるようにするには、ディレクトリサーバインスタンスと管理サーバをデプロイした後で、下記のように別途デプロイしてやる必要がある。setup-ds-admin.pl などの時のような問答はなく、ディレクトリサーバ及び管理サーバの設定情報は自動的に検出される。

root# setup-ds-dsgw
root# service dirsrv-admin restart
再度ブラウザで http://localhost:9830/ を開くと、Directory Server Gateway へのリンクがあり、
それをクリックすると、左図のような画面が出るはずだ。ただし、Firefox ではタイトルフレームのフォーマットが崩れ、この通りには表示されないだろう。その点については後で対処する。

なお、サーバ自体でなく他のホストから使用する場合は、DNS かそれが無理ならクライアントの hosts ファイルに、サーバのホスト名と IPアドレスを登録しておく必要がある。

Windows版 Javaベース 389 Management Console のインストール

Windows クライアントから詳細な設定をしたいなら、389 DS オフィシャルサイトの Download ページから Windows用インストーラをダウンロードしてインストールするといいだろう。あらかじめ、Java Runtime Environment 6 をインストールしておく必要がある。

デプロイ後の調整

ディレクトリインスタンスのファイルディスクリプタ数の拡張

準備で増やしたファイルディスクリプタ上限数を、インスタンス側で有効利用できるようにする。設定変更は、389 Management Console の GUI からでも、インスタンス初期化ファイルの役目をする LDIF ファイルを直接編集する方法でも可能だ。GUI で設定したとしても結局 LDIF ファイルが書き換わるだけなので、結果はまったく同じ。

今後作成するディレクトリサーバインスタンス全てがデフォルトでこの設定になるようにしておくこともできる。dse.ldif の雛形となる /usr/share/dirsrv/data/template-dse.ldif を書き換えておけばよい。

GUI で設定する方法

389 Management Console で Directory Server(<インスタンス名>) を開き、Configuration タブ で、<インスタンス>:389 (最上位オブジェクト) の Performance タブにある Max number of file discriptors を 8192 に設定。

ファイルを直接編集する方法

/etc/dirsrv/slapd-<INSTANS_NAME>/dse.ldif ファイルを開き、nsslapd-maxdescriptors: の値を 8192 に書き換える。

どちらの方法も、変更を反映するためにディレクトリサーバインスタンスを再起動する必要がある；

root# service dirsrv restart

DSGWのFirefoxでの表示改善 (dsgw-html-moz.patch)

デフォルトの状態では、Directory Server Gateway を Firefox で表示すると、上部タイトルフレームのフォーマットが崩れてしまいきちんと表示されない。そこで、/usr/share/dirsrv/dsgw/html/ にある style.css と *title.html に手を入れた。パッチ(dsgw-html-moz.patch) にしておいたので、

root# patch -p1 -d /usr/share/dirsrv/dsgw/html \
      <dsgw-html-moz.patch

で適用できる。クライアントブラウザのキャッシュをクリアしてから DSGW を表示しなおせば、一応使えるレベルまで改善されているはずだ。

パスワード格納形式の調整

389 DS のデフォルトでは、userPassword 属性の値は SSHA 形式でハッシュして `{SSHA}4nhijZap8sdp5OqH+OUH+Po8hSeosFIOzijeiU==' というような文字列としてデータベースに格納される。ただ、LDAP を利用するアプリケーションの対応状況によっては、他のハッシュスキームでないと扱えない場合があるだろう。また、SSHA は他のハッシュ形式より多くの CPU パワーを消費するはず。アクセスの多い LDAP サーバでは、多少なりとも負荷の抑えられるもう少し軽いハッシュスキームを使った方がいいと思われる。例えば Postfix や Dovecot から利用する場合には、SMD5 (Salted MD5 Hash Algorithm) にしておくのがいいだろう。SMD5 にした場合、パスワードは `{SMD5}AbcDEfg...' といった形式で格納される。

OpenLDAP では、LDAP Password Modify Extended Operation [RFC3062] (パスワード変更拡張手順) を使用しない ldapadd や ldapmodify でパスワードを登録すると LDAP サーバ側で指定してあるハッシュ形式は無視されてしまい、それゆえ、パスワードを正しい形式でディレクトリに格納させるには、あらかじめハッシュしておいた文字列を投入するか、エントリ登録後に ldappasswd でパスワードを再登録してやらなければならない。それに対して 389 DS では、ldapmodify, ldapadd, 389 Management Console, DSGW ...どれを使っても、きちんとハッシュされて格納される。openldap-clients版の ldapmodify や ldapadd を使って入れてもそうなる。

パスワードハッシュ形式は、Java版 389 Management Console で対象の Directory Server インスタンスを開き、Configuration タブのツリーの Data オブジェクト -> Passwords タブの Password encryption ドロップダウンボックスで変更できる(※)。

ただし、変更が反映されるのはこれ以後に登録/変更する userPassword の値であって、既に登録されているものまで自動的にコンバートされるわけではない。もし既にユーザエントリが登録してあるなら、それらのパスワードは一度更新してやる必要がある。

なお、Directory Manager のパスワード形式だけは別の箇所で独立して規定されているのでこのオペレーションの影響は受けない。そちらはデフォルトの SSHA のままにしておくのが妥当だろう。

※ サブツリーやエントリ単位で `Fine-grained policy' を有効にするとパスワード格納形式が個別に設定できるはずなのだが、少なくとも手元の 389 DS 1.1.3 では、意図通りに機能してくれなかった。

  TOP Next
  HOME 最低限のセキュリティ設定