[AIX Solaris HP-UX Linux Windows][z/OS]

Lightweight Directory Access Protocol

このセクションでは、Lightweight Directory Access Protocol (LDAP) とは何か、それがどのように動作するのかに関する質問について説明し、X.500 と LDAP の高度な概要を示します。

LDAP は中央 X.500 または LDAP ディレクトリー・サーバー上に担当者、グループ、またはオブジェクトに関する情報を保管し、取得する手段を提供する標準プロトコルです。X.500 では、さまざまな属性を使用する複数の Web サーバーで、LDAP を使用して情報を編成し、照会することができます。LDAP クエリーは、希望する個々のエンティティーまたはグループのエンティティーを識別するために、必要に応じて、単純または複雑である可能性があります。LDAP は、元の X.500 Directory Access Protocol (DAP) の機能サブセットのみを含めることにより、必要なシステム・リソースを削減することができます。

IBM® HTTP Server LDAP モジュールにより認証と許可のために X.500 ディレクトリー・サーバーが使用可能になります。IBM HTTP Server はこの機能を使用して、制御されたユーザー・グループに、リソースへのアクセスを制限することができます。この機能により、個々の Web サーバーのユーザーおよびグループ情報を維持するために、通常は必要な管理オーバーヘッドが削減されます。

X.500 ディレクトリー・サーバーへの TCP/IP または Secure Sockets Layer (SSL) 接続が使用できるように、IBM HTTP Server LDAP モジュールを構成することができます。単一 LDAP サーバーまたは複数のサーバーを参照するように LDAP モジュールを構成することができます。

X.500 概要。X.500 では、さらに効率的な取得が可能なコンポーネントを使用してディレクトリー・サービスを提供します。LDAP では、これらのコンポーネントの 2 つ、つまり、フォームと文字を決定する情報モデル、および情報索引付けと参照を使用可能にするネーム・スペースを使用します。

X.500 ディレクトリー構造は、情報保管と検索がその他のディレクトリーと異なります。このディレクトリー・サービスは、情報と属性を関連付けます。属性に基づくクエリーが生成され、LDAP サーバーに渡され、サーバーはそれぞれの値を戻します。LDAP は、ディレクトリー・エントリーを表すために単純なストリング・ベースのアプローチを使用します。

X.500 ディレクトリーは、ObjectClass 属性に基づく型付きエントリーから構成されます。各エントリーは、属性から構成されます。ObjectClass 属性は、必要な属性とオプションの属性を決定する項目の型 (たとえば、担当者または組織など) を識別します。

項目は、ツリー構造で配置された状態で、地理的および組織的に分散しているサーバー間で分担することができます。 ディレクトリー・サービスは、配布階層内の位置に従って識別名 (DN) により項目に命名します。

Lightweight Directory Access Protocol の概要。X.500 ディレクトリーにアクセスするには、 Directory Access Protocol (DAP) が必要です。ただし、 DAP には大量のシステム・リソースと、プロトコルの複雑さを処理するサポート・メカニズムが必要です。 デスクトップ・ワークステーションが X.500 ディレクトリー・サービスにアクセスできるよう、LDAP が導入されました。

クライアントおよびサーバー・ベースのプロトコルである LDAP は、DAP クライアントに必要な大量のリソースの一部を処理することができます。LDAP サーバーは、クライアントに結果またはエラーを戻すだけで、クライアントに何かを要求することはほとんどありません。クライアント要求に応答することができない場合、LDAP サーバーは要求を別の X.500 サーバーにチェーニングする必要があります。サーバーは要求を完了するか、LDAP サーバーにエラーを戻す必要があります。LDAP サーバーは情報をクライアントに渡します。

IBM HTTP Server は以下の LDAP サーバーをサポートしています。
[8.5.5.0 or later]

ldapsearch を使用して LDAP 構成の問題をデバッグする

一部のケースでは、LDAP 構成が適切に機能できなくなる場合があります。以下に例を示します。
  • 識別名 (DN) が管理者アクセス制御リスト (ACL) に含まれていないため、一部の LDAP 照会を実行できない。
  • ログイン試行の失敗回数が多すぎて DN が LDAP からロックアウトされた。
  • DN パスワードが変更された可能性がある。
  • LDAP サーバーが匿名の照会を許可していない可能性がある。
  • WebSphere® Application Server に定義されているデフォルトのフィルターがユーザーの設定に適応しない可能性がある (例えば、objectclass=someObjectClass が定義されている場合など)。
  • ファイアウォールが該当ポートでの通信を許可していない。
  • LDAP が 389 以外の標準外ポートを使用するように設定されている。
  • LDAP 管理者 ID がサーバー ID に使用されるが、その管理者 ID が通常のユーザーとして定義されていない。
LDAP 構成が適切に機能できなくなるような上記およびその他の事例が発生した場合、ldapsearch を使用して問題を素早くデバッグできます。ldapsearch は、管理コンソールで WebSphere Application Server が LDAP サーバーに照会するときに使用するものに似たコマンド行ユーティリティーです。以下に例を示します。
ldapsearch –h <Host> -p <Port> -b “<BaseDN>” –D <BindDN> -w <Bind Password> “<User Filter>”
各部の意味は、次のとおりです。
Host
LDAP サーバーのホスト名。ホスト名としては、ショート・ネーム、ロング・ネーム、または IP アドレスを使用できます。
Port
デフォルトの LDAP ポート名 (389)。
BaseDN
LDAP ツリー内の照会開始位置。
BindDN
LDAP サーバーにバインドし、要求された照会を実行するための権限を保持する完全修飾 DN。一部の LDAP サーバーは匿名の照会を許可するため、バインド DN およびバインド・パスワードは必要ありません。
Bind Password
バインド DN のパスワード。
User Filter
LDAP サーバーを照会するときに使用されるストリング。
ldapsearch 照会の例:
C:¥>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" uid=test
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test
C:¥>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test
概念トピック    

インフォメーション・センターに関するご使用条件 | フィードバック

最終更新: October 08, 2014 06:19 PM EDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=ihs-dist&topic=cihs_ldap
ファイル名: cihs_ldap.html