LDAP の設定と構成

第 1 章 概要

このマニュアルでは、iPlanet LDAP ディレクトリサーバーの設定方法とネームサービスをサポートするための Solaris クライアントの設定方法について説明します。

ネームサービス

ネームサービスは、ユーザー、ワークステーション、アプリケーションがネットワーク上でやり取りするために必要な情報を中央の 1 箇所に格納します。これには、次のような情報が含まれます。

中央のネームサービスがないと、各ワークステーションがこれらの情報を保持しなければならないため、大規模なネットワークでは管理コストが非常に高くなります。ネームサービス情報は、ファイル、データベーステーブルなどの形式で格納されます。

Solaris のネームサービス

Solaris オペレーティング環境では、次のネームサービスを提供しています。

LDAP 以外の上記の 4 つのネームサービスについての詳細は、『Solaris ネーミングの管理』を参照してください。

現行の多くのネットワークでは、上記のサービスを 2 つ以上組み合わせて使用し、それらをネームサービススイッチ (単にスイッチともいう) で調整しています。スイッチは、クライアントワークステーションまたはクライアントアプリケーションがネットワーク情報を取得する方法を制御します。また、スイッチはアプリケーションが名前情報を取得するために使用するネームサービスを決定します。Solaris のスイッチについての詳細は、nsswitch.conf(4) のマニュアルページを参照してください。

LDAP モデル

LDAP は、ディレクトリサーバーにアクセスするための新しい業界標準プロトコルです。LDAP は軽量プロトコルです。効率的かつ単純で、実装も容易ですが、同時に十分に実用的でもあります。システムに依存しない単純化されたエンコーディング方式を採用しており、TCP/IP のすぐ上で動作します。

LDAP ディレクトリは、ディレクトリエントリの集合に名前を付け、管理し、アクセスする方法を提供します。ディレクトリのエントリは、1 つの型と 1 つ以上の値を持つ属性で構成されます。各属性の構文は、取り得る値の種類 (ASCII 文字や jpeg の写真など) と、それらの値のディレクトリ処理時における解釈方法 (検索時や比較時に大文字と小文字を区別するかなど) を定義します。

ディレクトリエントリは、地域 (国)、組織 (会社) 境界、またはドメイン (dc) に基づいてツリー構造に編成されます。

エントリには、このツリー構造内での位置によって、識別名 (DN) が付けられます。識別名の各構成要素は相対識別名 (RDN) と呼ばれます。RDN は、そのエントリの 1 つ以上の属性から成ります (識別名の正式な定義については、RFC2253 を参照してください)。

ディレクトリツリー構造の階層は、UNIX ファイルシステムの階層に似ています。つまり、RDN がファイル名、DN がそのファイルへの絶対パスに相当します。UNIX ファイルシステムと同様、同じ親を持つディレクトリエントリはそれぞれ固有の RDN を持たなければなりません。ただし、ディレクトリツリー内では、末端ノードでも非末端ノードでも中身または属性を持つことができます。

DNS 名前空間と同様に、LDAP ディレクトリエントリは「リトルエンディアン」方式でアクセスされます。つまり、LDAP の名前では、最も小さな構成要素が最初に、ルート直下の最も大きな構成要素が最後にきます。DN は、RDN の並びをツリーのルートまで連結することによって構成されます。たとえば、Joe Qwerty という人が米国にある Ultra Keyboards という会社で働いているとすると、Joe Qwerty という人物の俗名 (CN) 属性には「Joe Qwerty」という値が、DN 属性には「cn=Joseph Qwerty, o=Ultra Keyboards, c=US」という値が格納されます。

LDAP をネームサービスとして使う理由

LDAP を使うと、既存のアプリケーション固有のディレクトリを置き換え、情報を統合することができます。つまり、LDAP サーバー上で行なった変更は、その情報を使用するすべてのディレクトリ対応アプリケーションで有効になります。たとえば、新規ユーザーに関するさまざまな情報を 1 つのインタフェースで 1 回だけ更新すれば、そのユーザーの UNIX アカウント、メールアドレス、別名がすぐに作成され、部門メーリングリストのメンバーに登録され、部外秘の Web サーバーにアクセスできるようになり、職責限定のニュースグループの購読者になるという場合を想像してみてください。またそのユーザーは、会社の電話帳、メールアドレス帳、会議カレンダーシステムにもすぐに登録されます。そのユーザーが退社したときも、1 回の操作で上記のすべてのサービスを無効にすることができます。

ディレクトリは、汎用のデータベースとは使われ方が異なります。ディレクトリには、頻繁に検索されるが、滅多に変更されない情報が格納されます。たとえばホスト名やユーザー名などの情報は、1 回登録され、何千回も検索されます。LDAP サーバーは、このような用途に合わせて調整されています。一方リレーショナルデータベースは、絶えず変化するデータを保守するという用途に合わせて調整されています。

複製サーバーを作成することによって、ディレクトリデータは複数のサーバーから利用できるようになり、装置の故障などという不測の事態に備えることができます。また、ディレクトリデータをより多く複製し、それを使用するユーザーやアプリケーションの近くに置くことができるため、処理のパフォーマンスが向上します。

複製サーバーを使用する理由は、正式な (複製元の) サーバーの負荷を軽減することだけではありません。多くの UNIX ネットワークでは、サブネットにスレーブサーバーを置く NIS (YPともいう) を使用しています。NIS と同様に、サブネット上に複製を置くと、ルーター経由のネットワークトラフィックを避けることができるため、応答待ち時間を短縮できます。ただし NIS と違って、LDAP の同期方式では増分更新を採用しているため、すべてのデータを定期的に複製に転送するのではなく、更新データを随時複製に転送します。

正式な (複製元の) サーバーの情報を保守するには、読み取り、書き込み、検索、比較の各権利についてアクセス制御を設定する必要があります。アクセス制御の対象にできるのは、サブツリー、エントリ、属性タイプで、個人、グループ、または「自分自身」(これにより、認証されたユーザーが自分自身のエントリにアクセスできる) に権限を与えることができます。これは極めて柔軟性の高い方式です。たとえば、人事部門の社員だけに役職やマネージャ属性の変更を許可したいとか、管理アシスタントにオフィスの住所とポケットベルの番号の変更許可を与えるとか、各個人に自宅の電話番号、車のナンバーといった情報の変更を許可するなどということが可能になります。詳細は、iPlanet ディレクトリサーバーのマニュアルを参照してください。

UNIX のログイン情報を例に説明してみましょう。いったんユーザーの属性をディレクトリサーバーに格納すると、ディレクトリサーバーのインタフェースを介して更新することによって、複数のオペレーティングシステムプラットフォームで使用しているユーザー名とパスワードを一括して更新できます。これにより、ユーザー情報の変更が簡単になるだけでなく、稀にしか使用しないアカウントのパスワードを忘れるといったことも少なくなります。

LDAP を Solaris オペレーティング環境のネームサービスとして使用する

Solaris クライアントは、NIS や NIS+ と同じようにネームサービススイッチを介して LDAP を使用することによって、名前情報を取得できます。

Solaris で広く使用されている、プロトコル非依存のネームサービスインタフェースは、標準の getXbyY API です。アプリケーションから getXbyY() (たとえば gethostbyname(3NSL)) を呼び出すと、ネームサービススイッチを走査し、そこから適切なネームサービスプロトコルを見つけます。それが LDAP であれば、LDAP API を呼び出して LDAP サーバーから情報を取得します。ネームサービススイッチについての詳細は、nsswitch.conf(4) のマニュアルページを参照してください。

図 1–1 に、ネームサービス、ネームサービススイッチ、および LDAP 実装各部の関係を示します。

図 1–1 アーキテクチャの概要

Graphic

前述の LDAP のすべての機能に加えて、ディレクトリ内にクライアントプロファイルを格納しておくと、Solaris クライアントの構成と保守が大幅に簡略化されます。この場合、各クライアントがデーモンを動作させ、このデーモンがディレクトリから最新のプロファイルをダウンロードしてクライアントの構成を更新します。これにより、クライアントの構成を変更する必要が生じても (新しい LDAP サーバーが追加されたり、セキュリティモデルが変更された場合など)、システム管理者は適切なプロファイルを変更するだけで、クライアントが最新の構成を自動的に取得します。詳細は、ldap_cachemgr(1M) のマニュアルページを参照してください。

LDAP の処理

LDAP では、次の 3 つの機能に関して 9 つの処理が定義されています。