LDAPへの移行を準備する

Brian-K.-Jones（2004年2月4日（水））
シェア
LDAPは、あなたと無縁のネーミング/ディレクトリサービスではない。規模の大小、商用、オープンソースの区別なく、複数のアプリケーションベンダが、認証と「ホワイトページ」タイプの情報を扱う一元化されたサービスとしてLDAPを採用している。

近頃は、”got root?” Tシャツを着ることもLDAPを手に入れろと背広族を怒鳴りつけることもない人は、たぶんLDAPが自分の環境に合うだろうかと考えている当の背広族ぐらいだろう。他のサービスとは段違いのセキュリティと統合の機能を持つLDAPは、少なくともちょっとした時間を費やして検討すべき代物のはずだ。では、始めるとしよう。

LDAPに移行したらどうだろう、と複数の友人（コンサルタント、システム管理者、マネージャーも含まれる）に質問してみた。すると、ほとんど誰もが、禁煙しろとかファーストフードを食べるのをやめようとか言われたみたいな表情になった。その顔には「確かにそうしたほうがいいだろうけどね、う〜ん」と書かれていた。その後で、たいていはこんな意味のことを言われた。「どこから始めればいいんだ?」、「○○○（ここにはアプリケーションやプラットフォームの名前が入る）で、うまく使えるかな?」云々。そこで、この週に一回の管理者向け連載記事の第一弾として、LDAPへの移行を始める前に検討すべき点と移行を進める手順について、かいつまんで説明してみたい。

なぜLDAPへ移行するのか?

手始めに、LDAPに移行する理由を挙げてみよう。

  • SunがNISとNIS+をやめた

    聞くところによると、米Sunは、次のSolarisリリースにNISサーバまたはNISクライアントソフトウェアをバンドルしないようだ。NIS+はこのリリースにまだ含まれるが、SunのNIS+クライアントでさえ、移行を始めるようにと勧告されている。Solaris 10リリース後のいずれかの時点で、NIS+のサポートが打ち切られる予定だからだ。NISやNIS+のことをよく知らない読者は、ここにある5分間学習コースを読むか、SunのNISドキュメントとNIS+ドキュメントを読んでいただきたい。

    NISやNIS+に代わるものとしてSunが推奨するのが同社のSunONE Directoryソフトウェア（旧iPlanet Directoryサーバ）であるのは、おそらく意外でも何でもないだろう。このソフトウェアは、手回しの良いことにSolaris 9にバンドルされている。Sunは、この後で説明するのと部分的に重なる理由でLDAPを推奨している。

  • セキュリティ

    あまり知らないものにまで話を広げるのは気が進まないので、セキュリティに関する比較はNISに限ることにしたい。ただし、ここでLDAPに関して述べる事実は、読者が現在使用しているネーミング/ディレクトリシステムと比較するための材料としても使えるはずだ。

    LDAPは、データベースではなく、ディレクトリのデータにアクセスする標準化プロトコルなので、環境にある情報を監視する役目にはうってつけだ。LDAPのプロトコル実装とデータ保存メカニズムとの間には、はっきりとわかる境界線が引かれている（これらは別々に設定できる）。そのおかげで、データ保存メカニズムはデータの保存に専念でき、アクセスプロトコルはデータのセキュリティを保証できる。

    LDAPは、きめの細かいセキュリティを目指して設計された。このことは、LDAPのデータモデルに少なくとも部分的な特徴として現れている。LDAPデータモデルは、文字列で埋まった単純なファイルではなくオブジェクト/属性階層に近い構造を持っている。たとえば、Linuxボックスの/etc/passwdには1文字列としてユーザエントリの全フィールドが保存されるが、LDAPではだいぶ違う。LDAPの場合、ユーザをディレクトリ内の1オブジェクトとして識別し、それ以外の/etc/passwdフィールド（ログインシェル、ホームディレクトリ、GECOSなど）は、そのオブジェクトの属性となる。つまり、アクセスを属性レベルで制限できるわけだ。これは、NISマップのフィールドへのアクセスを個別に制限できることに相当する。

    さらに、アクセス制御リスト（ACL）を使ってアクセスを設定できるので、データへのアクセスを部分的に制限できるだけでなく、データに対して実行できる操作も制限できる。たとえば、システムのユーザ名の一覧は誰でも読み取れるようにするが、個々のユーザの暗号化パスワード文字列の読み取りは禁止することも可能だ。また、本人に関係のあるデータの読み取りアクセスをユーザに許可する一方で、GECOS（ユーザに関するオプションの情報）フィールドのようなものを標準化し、管理者だけに書き込みアクセスを許可することもできる。

  • 統合

    NIS/NIS+と少なくとも同レベルの統合を提供できない技術を代わりに導入しろと、システム管理者に命じるほどお偉方は愚かではないだろう。ここ数年、ネーミング/ディレクトリサービスは、業務環境にあるほとんどのアプリケーションが頼り切る存在になる傾向にある。

LDAPサポートを使うべきでない領域がまだ若干あるとはいえ、多くの環境でLDAPはNISにできることか、それ以上のことをこなせる。具体例を少し挙げてみよう。

  • Apacheは、LDAPを認証に使える
  • Sendmailは、LDAPを認証、メール経路情報、エイリアス検索に使える
  • Sambaは、LDAPをバックエンド認証メカニズムとして使える
  • Autofsは、LDAPからオートマウントマップを取得できる
  • FreeRADIUSは、LDAPを認証に使える

これはすごい。しかも、これは氷山の一角だ。システムサービスのほかにも、多くの企業がLDAPを自社「ホワイトページ」ソリューションとして利用している。多くの電子メールアプリケーションやカレンダーアプリケーションが、LDAPとの互換性を備えているからだ。Netscape、Mozilla、Evolution、Outlook、KMail、その他、数多くの電子メールクライアントが堅牢なLDAPサポートを備えているし、MuttやPineのようなテキストベースのクライアントでさえ、LDAP検索に基づいてアドレスを補完させることができる。

しかし、目の肥えたシステム管理者には、これでも十分ではない。LDAPは、PAM（Pluggable Authentication Modules）ともかなり相性がよく、/etc/nsswitchファイル（”man 5 nsswitch.conf”）のほぼ全部の行の「nis」を置き換えできる。LDAPに対応するためにnsswitchとPAMの設定をすべて変更すれば（authconfigユーティリティのあるシステムならほぼ自動的に変更できる）、ほとんどの他のシステムレベルのメカニズム（ls -l、TCPラッパー、idにおけるUID番号の名前へのマッピングなど）は「まともに動作する」。

どこから始めるか
  1. 環境を評価する

    ここでこうして座って「答えがLDAPなんですよ、質問は何でしたっけ?」と言うのはたやすいが、LDAPが読者の環境を健康体にする万能薬ではないことも十分に承知している。この記事に背中を押されたとしても、LDAPを使って何がしたいのかきちんと理解するのが賢明だろう。

    たとえば、自社で開発したアプリケーションがあって、そのログインルーチンを変更してLDAPに対応させる必要があるかもしれない。あるいは、認証にはLDAPを使用するが、オートマウントのマップはさしあたりファイルまたはマップに残しておくことにする場合もあるだろう。NISサーバのシャットダウン・パーティーの予定を立てるのはまだ早い。NISマップ（どれでもかまわない）を1つ選び出し、そのマップに依存して動作するすべてのサービス、アプリケーション、システムに注目する。そうしてから、それらがLDAPをサポートするか、つまりLDAPをサポートするよう設定できるかを確認する。サーバ退行テストを6か月間も行った後で、業務の根幹を担うアプリケーションのベンダから「LDAPって何ですか?」と言われるのは楽しいことではないだろう。

    私の経験では、LDAP開発は初期段階が最も長く過酷だ。いったんそこを抜けると、全部が下り坂になるとは言わないまでも、かなり楽になり、ペースが速くなる。

  2. 使用可能な各サーバを評価する

    次に（チームの人数が多ければ並行して）、どのLDAP実装を使うかを決める必要がある。これは、予想したほど難しい判断ではなかった。米NovellのeDirectoryとSunのSunONE Directory Server、そしてOpenLDAPをテストしてみた。

    客観的に見て、どれもすばらしいアプリケーションである。

    実際、私はNovellの製品に決める寸前まで行った（ともかくLinuxでは快調に動作する）。Novellの開発チームは、ごく平凡なシステム管理者でもLDAPの情報を簡単に入手できるようにするため、すばらしい仕事をした。明快かつ徹底的なチュートリアルとドキュメントが同社Webサイトに用意され、Novellサイトのサポートフォーラムの常連（Novellの社員もいた）は、実に親切で知識豊富だった。

    Sunの製品も優れているが、GUIインタフェースはNovellの製品と比べて多少とっつきにくかった。また、Sun Webサイトという名のデジタルの迷宮には、昔からどうも親しめない。LDAPに関連するドキュメントは見つかったが、バージョンが違っていたり、別のドキュメントと取り違えたり、まったく見当違いの場所を見ていたりすることもしばしばだった。同じことは、Solaris LDAPクライアントの設定に関するドキュメントを探しているときも経験した。

    結局、OpenLDAPを選んだのは、その単純さが主な理由だ。OpenLDAPは、基本的には、LDAPプロトコル関連のRFCに書かれたものの実装である。他の気のきいた機能は、後から組み込んだり、カスタマイズしたり、追加したりできる。RFCと旧約聖書であるところの「Understanding and Deploying LDAP Directories」（私のLDAPの教科書である）で使われる用語は、OpenLDAP スイートのインタフェース、ドキュメント、設定ファイルでそのまま使われる。これは心強かった。

    NovellとSunの製品には、この単純さが欠けている。Novellの場合、ユーザのホームディレクトリをマップするような簡単な作業をやり始めると、すぐに複雑な顔を見せ始める。デフォルトで、インタフェースは、ユーザディレクトリがNetWareボリュームにあるという前提で設定されている。また、一連のデータ属性が、GUIを使って定義していないのにエントリに追加されるらしい（データエキスパートの調査による）。Sunの製品にも似たような問題があり、こちらが望んでいる環境とセットアップを勝手に想定して動いてしまう。

    このようなツールは、私にはしっくりこなかった。中にはほれ込む人もいるだろう。価格は、政府機関やそれと似たような規模の大企業でない限り、おそらく問題にならない。NovellとSunは、数十万オブジェクトエントリ程度の規模であれば、フリーでソフトウェアを使うことを認めている（もちろんサポートはないが）。ただし、もし本当に困った問題が起きたときにも、どのベンダの商用ツールよりも大きなコミュニティがフリー/オープンソースのOpenLDAPにあると思われる。そのことを除外しても、OpenLDAPは、大部分においてLinuxによってLinuxのために作られている。他の製品には決して主張できない特徴である。

  3. クライアントから始めよ

    この見出しの文言は、LDAPの展開を準備している人への最も価値ある助言ではないだろうか。クライアントが、その申し立てどおりのことをこちらが期待しているように本当に実行できるのかテストするまでは、アプリケーションの移植、データの整理と移行、ディレクトリサーバの保守に時間を費やしてはならない。

    私の立場では（私がシステム管理者だということをお忘れなく）クライアントのテストは、システムレベルで始まる。認証は、現在使用中のすべての機能と正しく連携して動作しなければならない。ホスト解決は、DNS以外のものを使って行われているなら、後を濁さず退場しなければならない。パスワードポリシー、tcpwrapper、compat mode、リモートマウントは、パフォーマンスと機能の点で、エンドユーザ側に違和感を与えないように実行されなければならない。


少数のテストデータから始め、LDAPを使用する目的とLDAPをサポートするアプリケーションの一覧と相談し、マニュアルページ、ベンダのドキュメント、オンライン・チュートリアルを読み始める。そして、プロジェクトに関連するフォーラムに参加し、メーリングリストに登録する。

それから、ときどきはここへ戻ってきて、LDAPへの移行に関する次回以降の連載記事にも目を通してもらいたい。では、また次回。