OpenLDAPの設計：OpenLDAPで始めるディレクトリサーバ構築（1）（1/3 ページ）

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

ディレクトリサーバとは

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

　従ってクライアントは、ディレクトリサーバでの認証後、許可された操作を行うことになります。このため、サーバ／クライアント間でのプロトコルが必要ですが、現在主に使われているのが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オブジェクトクラスを利用する場合に必要となる定義を行った例です。