Tweet

第1回　OpenLDAPの設計

　「ディレクトリサーバ」を利用すれば、ユーザー情報を一元的に管理し、運用面でさまざまなメリットを得ることができます。この連載では、オープンソースのディレクトリサーバ「OpenLDAP」を対象にしたディレクトリサーバの構築方法および活用方法を紹介していきます。

関連記事：
	LinuxでLDAPサーバを構築するには http://www.atmarkit.co.jp/flinux/rensai/linuxtips/904ldapserver.html
	LDAPによるパスワードの一元管理 http://www.atmarkit.co.jp/flinux/rensai/root02/root02a.html

ディレクトリサーバとは

　ディレクトリサーバとは、コンピュータネットワーク上でユーザー情報、組織情報などを保存、管理し、ネットワーク上に分散しているクライアントに対しこれらの情報を提供するサーバです。また、管理する情報に対するアクセスコントロールも提供します。

　従ってクライアントは、ディレクトリサーバでの認証後、許可された操作を行うことになります。このため、サーバ／クライアント間でのプロトコルが必要ですが、現在主に使われているのがLDAP（Lightweight Directory Access Protocol）です。

　LDAPサーバの実装としては、商用製品ではマイクロソフトのActive Directory、サン・マイクロシステムズのSun Java System Directory Server、ノベルのeDirectoryなどが有名です。オープンソースの実装では、本連載で取り上げるOpenLDAPのほか、Fedora Directory Server、Apache Directory、OpenDSなどがあります。

　本連載で取り上げるOpenLDAPはプロジェクトが誕生してから10年以上の歴史があり、オープンソースの中では最も導入実績があるLDAPサーバです。多くのLinuxディストリビューションに含まれ、はじめから利用しやすい状態で提供されていることが多いことも特徴です。

■ディレクトリサーバのメリット

　個人で利用するコンピュータや、比較的小規模のオフィスにおいては、ユーザー情報はそれぞれのコンピュータで管理されることが多いと思います。

　しかし、例えば30〜50人、またはそれを超える規模の組織でユーザー情報を管理する場合は、それぞれのコンピュータで個別に管理するよりも、専用サーバ上で誰かが責任をもって管理している方が、何かと都合のいい場合が多くなってきます。

　また、ディレクトリサービスを活用することでアプリケーションサーバやWebサーバと連携させたシングルサインオン環境や、Active Directoryで管理されるWindowsユーザーを統合したアカウント管理へと発展させることも可能となります。

　逆に、管理する情報が個々のコンピュータに分散していれば、分散した数だけ、メンテナンスに掛かる手間が増えてしまいます。

　本連載の第1回目では、LDAPに準拠したオープンソースのソフトウェア、OpenLDAPを用いて、ディレクトリサーバを構築するまでの設計方法を紹介していきます。ディレクトリサーバの構築においてまず重要なのは、どんな情報をどのように格納し、どこを参照するかという設計の部分です。まずそこから紹介していきましょう。

ディレクトリサーバ設計のポイント

■スキーマ設計

　「ディレクトリ情報を集中管理できる」というメリットを持つディレクトリサーバですが、利用に当たって、まずはディレクトリ情報として格納する各エントリに、どのような情報を持たせるかを定義する必要があります。

　この定義には、ディレクトリサービスを利用するクライアント側の用途に基づいて、ディレクトリサーバに蓄積する必要があるデータを選定し、そのデータをディレクトリサーバが扱うことのできるデータ型へと落としていく作業が必要になります。

　ディレクトリサーバが扱うデータ型としては、標準的に利用されるものがあらかじめRFCに定義されています。OpenLDAPでは[OpenLDAPインストールDir]/etc/openldap/schema/ディレクトリにこれらのデータ型を定義したファイルが用意されています。

■オブジェクトクラス設計

　例えば、Linuxクライアントからのユーザー認証に、/etc/passwdファイルではなくディレクトリサーバを利用する場合、LinuxはPAM（pam_ldap.so）を利用します。

　PAMは、認証対象のユーザーがディレクトリサーバに存在することを確認するため、サーバ内の「posixAccount」オブジェクトクラスの「uid」属性を検索します。この「posixAccount」オブジェクトクラスの利用には、OpenLDAPが提供するnis.schemaファイルにあらかじめ用意されている定義を利用することができます。

　上記のnis.schemaファイルの内容から、「posixAccount」オブジェクトクラスは

• オブジェクトIDは、"1.3.6.1.1.1.2.0"
• "top"という上位クラスから派生した補助型（AUXILIARY）のオブジェクトクラス
• cn、uid、uidNumber、gidNumber、homeDirectoryの各属性を必須で備える
• userPassword、loginShell、gecos、descriptionの各属性を任意に備えることができる

と、/etc/passwdファイルに含まれる情報が定義されていることが分かります。

　このオブジェクトクラスは、構造型（STRUCTURAL）、補助型（AUXILIARY）、抽象型（ABSTRACT）の3つに分類され、各エントリには構造型のオブジェクトクラスを必ず含めるという制約があります。

　このため、Linuxのユーザー認証という用途で利用する場合、ユーザーエントリには、構造型のオブジェクトクラス、例えばcosine.schemaファイルにあらかじめ用意された「account」オブジェクトクラスなどを加えることになります。次のLDIFファイル（LDAP Data Interchange Format: LDAPエントリをテキスト形式で表現したファイル）は、posixAccountオブジェクトクラスを利用する場合に必要となる定義を行った例です。

1/3

Index OpenLDAPで始めるディレクトリサーバ構築 　第1回　OpenLDAPの設計

Page 1 ディレクトリサーバとは ディレクトリサーバ設計のポイント 　 Page 2 「継承」の概念 　 Page 3 そのほかの留意事項

Linux Square全記事インデックス

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード