| SUSE LINUXドキュメント パート IX. サービス / 第45章 LDAP—ディレクトリサービス | ||||
|---|---|---|---|---|
 | 44.3. ローカルリファレンスクロックの設定 | 45.2. LDAPディレクトリツリーの構造 |  | |
| SUSE LINUXドキュメント パート IX. サービス / 第45章 LDAP—ディレクトリサービス | ||||
|---|---|---|---|---|
| 44.3. ローカルリファレンスクロックの設定 | 45.2. LDAPディレクトリツリーの構造 | | |
目次
概要
LDAP (Lightweight Directory Access Protocol)は、情報ディレクトリへのアクセスと管理を行うために設計されたプロトコルセットです。LDAPは、ユーザおよびグループ管理、システム構成の管理、アドレス管理など、さまざまな目的に使用できます。この章では、OpenLDAPの動作原理とYaSTを使用したLDAPデータの管理方法の基本事項について説明します。LDAPプロトコルには複数の実装方法がありますが、この章ではもっぱらOpenLDAPの実装を中心に説明します。
ネットワーク環境では、重要な情報をすぐに利用できるように整理しておくことは不可欠です。そのため、一般的に使用されているイエローページのようなディレクトリサービスを使用して、情報を整理し、すぐに検索できる形式にしておくことができます。
理想的なケースは、一元的なサーバでデータをディレクトリに保持し、特定のプロトコルを使用してそれをすべてのクライアントに配布するという形態です。データはさまざまなアプリケーションがアクセスできる方法で整理されます。この方法では、個々のカレンダツールや電子メールクライアントが独自のデータベースを持つ必要はありません。一元的なリポジトリにアクセスすればよいためです。これにより、情報管理のための負荷も大幅に軽減されます。LDAP (lightweight directory access protocol)のようなオープンで標準化されたプロトコルを使用すれば、可能な限り多くの異なるクライアントアプリケーションが、このような情報にアクセスできるようになります。
この文脈でのディレクトリとは、高速かつ効果的に読み込みと検索ができるように最適化された一種のデータベースです。
膨大な(同時)読み込みとアクセスを可能にするため、書き込みアクセスは、管理者による少量の更新作業に限られます。従来のデータベースは、できる限り大量のデータを短時間に受け付けられるように最適化されます。
書き込みアクセスは制約された形でのみ可能なため、ディレクトリサービスは、ほとんどが変更のない静的情報の管理に使用されます。一般に、非常に頻繁に変更されるデータ(動的データ)は、従来のデータベースに保存されます。たとえば、企業ディレクトリにある電話番号は、経理で管理する数字ほど頻繁に変更されません。
静的データを管理する場合、既存のデータセットの更新は非常にまれです。動的データ、特に銀行口座や経理のデータセットが関与する場合、データの一貫性が最重要課題となります。たとえばある項目から差し引かれた金額を他の項目に加算する場合、データストックで残高を正しく維持するためには、1回のトランザクション内で両方の操作が同時に行われる必要があります。データベースはこのようなトランザクションをサポートしますが、ディレクトリではサポートされません。ディレクトリでは、短期的にデータの一貫性が崩れても大きな問題にはなりません。
LDAPなどのディレクトリサービスの設計には、複雑な更新やクエリメカニズムのサポートは含まれません。このサービスにアクセスするすべてのアプリケーションが、すばやく簡単にアクセスできることが主な課題です。
Unixでも他のシステムでも、多くのディレクトリサービスがこれまでに存在し、今なお存在しています。いくつか例を挙げると、Novell NDS、Microsoft ADS、BanyanのStreet Talk、OSI標準のX.500などがあります。LDAPは元々、DAP (directory access protocol)の無駄な機能を省略したサービスであり、X.500へのアクセスを目的として開発されました。X.500標準は、ディレクトリエントリの階層構造を規定しています。
LDAPは、DAPの簡易版です。LDAPでは、X.500エントリ階層が維持されているため、プラットフォーム非依存という特長を持ち、必要なリソースも少なくて済みます。TCP/IPを使用することにより、ドッキングアプリケーションとLDAPサービス間のインタフェースが、非常に簡単に確立できます。
一方でLDAPは、X.500サポートとは別に進化し、スタンドアロンソリューションとして採用されることが多くなっています。LDAPはLDAPv3の照会(パッケージopenldap2のプロトコルバージョン)をサポートすることによって、分散データベースを実現しています。SASL (simple authentication and security layer)も新しく採用されています。
LDAPの機能は、当初の計画ではX.500サーバにデータを問い合わせることだけでしたが、現在はそれだけにとどまりません。slapdというオープンソースサーバが存在し、オブジェクト情報をローカルデータベースに格納できます。また複数のLDAPサーバへのレプリケートを行うslurpdという拡張機能もあります。
openldap2パッケージの構成は、次のとおりです。
スタンドアロンのLDAPv3サーバ。オブジェクト情報をBerkeleyDBベースのデータベースで管理します。
このプログラムは、データの変更をローカルLDAPサーバから、ネットワーク上にインストールされた他のLDAPサーバへレプリケートします。
slapcat、slapadd、slapindex
Unix系システムの管理者は、従来から、ネットワーク内の名前の解決やデータ配信にNISサービスを使用しています。設定データは/etc内のファイルに保存され、group、hosts、mail、netgroup、networks、passwd、printcap、protocols、rpc、およびservicesの各ディレクトリは、ネットワーク内の複数のクライアントに分散されています。これらのファイルはシンプルテキストファイルのため、保守にそれほどの手間はかかりません。しかし、構造化されていないため、大量のデータを処理することがますます困難になっています。NISはUnix系プラットフォーム専用に設計されているため、異種ネットワークでの一元的データ管理には採用できません。
LDAPサービスはNISと異なり、純粋なUnix系ネットワークに制限されていません。Windowsサーバ(2000以降)は、LDAPをディレクトリサービスとしてサポートします。NovellもまたLDAPサービスを提供します。前述のアプリケーションタスクは、Unix系以外のシステムでもサポートされます。
LDAPの原則は、一元管理が必要なあらゆるデータ構造に適用可能です。いくつかの例を次に示します。
NISサービスの代替としての採用
メールルーティング(postfix、sendmail)
Mozilla、Evolution、およびOutlookなどのメールクライアント用アドレス帳
BIND9ネームサーバのゾーン記述の管理
異種ネットワークでのSambaのユーザ認証
LDAPはNISと異なり拡張できるため、これら以外にも広範な用途が考えられます。データが明確に定義された階層構造になっているため、検索が容易であり、大量データの管理が非常に容易になります。
