軽量ディレクトリアクセスプロトコル
軽量ディレクトリアクセスプロトコル
通信プロトコル
目的ディレクトリサービス
に基づくX.500
ポート389 (ldap)、636 (ldaps)
RFC(s)4510、4511​​

軽量ディレクトリアクセスプロトコル（LDAP / ˈ ɛ l d æ p / ）は、インターネットプロトコル（IP）ネットワーク上で分散ディレクトリ情報サービスにアクセスし、これを維持するための、オープンでベンダー中立な業界標準アプリケーションプロトコルです。 [ 1 ]ディレクトリサービスは、ネットワーク全体でユーザー、システム、ネットワーク、サービス、アプリケーションに関する情報の共有を可能にすることで、イントラネットやインターネットアプリケーションの開発において重要な役割を果たしています。 [ 2 ]例えば、ディレクトリサービスは、企業の電子メールディレクトリ のように、階層構造になっていることが多い、整理されたレコードセットを提供します。同様に、電話帳は、住所と電話番号が記載された加入者のリストです。

LDAPは、記述言語ASN.1を用いて、インターネット技術タスクフォース（IETF）の一連のRFC（ Request for Comments ）で規定されています。最新の仕様はバージョン3で、RFC  4511 [ 3 ]として公開されており、技術仕様へのロードマップはRFC  4510で提供されています。

LDAPの一般的な用途は、ユーザー名とパスワードを一元的に保存する場所です。これにより、様々なアプリケーションやサービスがLDAPサーバーに接続し、ユーザーを認証できるようになります。[ 4 ]

LDAPは、 X.500シリーズの標準規格、特にX.511ディレクトリアクセスプロトコルのよりシンプルな（軽量な）サブセットです。[ 5 ] [ 6 ] この関係から、LDAPはX.500 Liteと呼ばれることもあります。[ 7 ]

歴史

電気通信会社は、約70年にわたる電話帳の作成と管理を経て、ディレクトリ要件に関する理解を深めました。これらの会社は、情報技術とコンピュータネットワークにディレクトリサービスの概念を導入し、その貢献は、1980年代に国際電気通信連合（ITU）によって策定された包括的なプロトコルスイートであるX.500仕様[ 8 ]に結実しました。

X.500ディレクトリサービスへのアクセスは、従来、X.511ディレクトリアクセスプロトコル（DAP）を介して行われていました。DAPは、 OSI（Open Systems Interconnection ）プロトコルスタックを必要としました。LDAPは当初、よりシンプルな（そして現在では広く普及している） TCP/IPプロトコルスタックを介してX.500ディレクトリサービスにアクセスするための軽量な代替プロトコルとして設計されました。このディレクトリアクセスモデルは、 DIXIEプロトコルとディレクトリアシスタンスサービスプロトコル から借用されました。

このプロトコルはもともと、ミシガン大学の Tim Howes 氏、Isode Limited の Steve Kille 氏、Nexor の Colin Robbins 氏、および Performance Systems International の Wengyik Yeong 氏によって 1993 年頃に DIXIE および DAS の後継として作成されました[ 9 ] 。Critical Angle Inc.のMark Wahl氏、Tim Howes氏、およびSteve Kille氏は、インターネット技術タスクフォース( IETF)の後援の下、LDAP の新しいバージョンである LDAPv3 の作業を開始しました。1997 年に最初に公開された LDAPv3 は、LDAPv2 に取って代わり、拡張性のサポートが追加され、 Simple Authentication and Security Layerが統合され、プロトコルが 1993 年版の X.500 に準拠するようになりました。LDAPv3 仕様自体のさらなる開発や、LDAPv3 に機能を追加する多数の拡張機能の開発は、IETFを通じて行われました。

LDAP の初期の設計段階では、Lightweight Directory Browsing Protocol（LDBP）として知られていました。プロトコルの適用範囲がディレクトリの閲覧と検索からディレクトリ更新機能へと拡張されたため、名称が変更されました。LDAP がLightweight という名前を付けられたのは、LDAP が DAP の前身である DAP ほどネットワークを消費せず、帯域幅の使用量も比較的少なく、インターネット上での実装が容易だったためです。

LDAPは、X.500の後継バージョン、XML Enabled Directory (XED)、Directory Service Markup Language (DSML)、Service Provisioning Markup Language (SPML)、Service Location Protocol (SLP)など、その後のインターネットプロトコルに影響を与えてきました。また、 MicrosoftのActive Directoryの基盤としても使用されています。

プロトコルの概要

クライアントは、LDAPサーバー（ディレクトリシステムエージェント（DSA）と呼ばれる）に接続することでLDAPセッションを開始します。デフォルトではTCPおよびUDPポート389、LDAPS（LDAP over TLS/SSL、後述）の場合はポート636を使用します。[ 11 ]次に、クライアントはサーバーに操作要求を送信し、サーバーは応答を返します。一部の例外を除き、クライアントは次の要求を送信する前に応答を待つ必要はなく、サーバーは任意の順序で応答を送信できます。すべての情報は基本符号化規則（BER）を使用して送信されます。

クライアントは次の操作を要求できます。

  • StartTLS –安全な接続のためにLDAPv3トランスポート層セキュリティ（TLS）拡張機能を使用する
  • バインド –認証し、LDAPプロトコルのバージョンを指定する
  • 検索 – ディレクトリエントリを検索および/または取得する
  • 比較 – 名前付きエントリに指定された属性値が含まれているかどうかをテストします
  • 新しいエントリを追加する
  • エントリを削除する
  • エントリを変更する
  • 識別名（DN）の変更 – エントリを移動または名前変更する
  • 放棄 – 以前のリクエストを中止する
  • 拡張操作 – 他の操作を定義するために使用される汎用操作
  • アンバインド – 接続を閉じる（バインドの逆ではありません）

さらに、サーバーは、接続がタイムアウトする前などに、いかなる要求にも応答しない「非要求通知」を送信する場合があります。

LDAP通信をセキュアにする一般的な代替方法として、SSLトンネルの使用があります。LDAP over SSLのデフォルトポートは636です。LDAP over SSLの使用はLDAPバージョン2（LDAPv2）では一般的でしたが、正式な仕様で標準化されたことはありませんでした。この使用法は、2003年に正式に廃止されたLDAPv2とともに非推奨となっています。[ 12 ]

ディレクトリ構造

このプロトコルは、1993 年版のX.500モデルに準拠したディレクトリとのインターフェイスを提供します。

  • エントリは属性のセットから構成されます。
  • 属性は名前（属性タイプまたは属性説明）と1つ以上の値を持ちます。属性はスキーマで定義されます（下記参照）。
  • 各エントリには、一意の識別子である識別名(DN) が付与されます。DN は、エントリ内の属性から構成される相対識別名(RDN) と、それに続く親エントリの DN で構成されます。DNはファイルのフルパス、RDN は親フォルダ内の相対ファイル名と考えてください (例: /foo/bar/myfile.txtDN が DN であれば、myfile.txtRDN は DN になります)。

DNは、エントリの存続期間中に変化する可能性があります。例えば、エントリがツリー内で移動された場合などです。エントリを確実かつ明確に識別するために、エントリの操作属性セットにUUIDが提供される場合があります。

エントリは、プレーン テキスト形式 ( LDAP 自体のような バイナリ プロトコルとは対照的) であるLDAP データ交換形式(LDIF) で表現すると、次のようになります。

dn : cn = John Doe 、dc = example 、dc = com cn : John Doe givenName : John sn : Doe telephoneNumber : +1 888 555 6789 telephoneNumber : +1 888 555 1232 mail : [email protected] manager : cn=Barbara Doe、dc=example、dc=com objectClass : inetOrgPerson objectClass : organizationalPerson objectClass : person objectClass : top

「dn」はエントリの識別名であり、属性でもエントリの一部でもありません。「cn=John Doe」はエントリのRDN（相対識別名）であり、「dc=example,dc=com」は親エントリのDNです。ここで、「 」は「ドメインコンポーネントdc」を表します。その他の行はエントリ内の属性を示します。属性名は通常、ニーモニック文字列で、共通名は「 」、ドメインコンポーネントは「 」、メールアドレスは「 」、姓は「 」です。[ 13 ]cndcmailsn

dc=example,dc=comサーバーは、特定のエントリ（例えば「 」とその子エントリ）から始まるサブツリーを保持します。サーバーは他のサーバーへの参照も保持している場合があり、そのため「 」にアクセスしようとすると、ディレクトリツリーのその部分を保持するサーバーへの参照または継続参照がou=department,dc=example,dc=com返されることがあります。クライアントはその後、他のサーバーに接続できます。一部のサーバーはチェーニングもサポートしており、これはサーバーが他のサーバーに接続し、結果をクライアントに返すことを意味します。

LDAPでは順序付けがほとんど定義されていません。サーバーは、属性の値、エントリ内の属性、そして検索操作で見つかったエントリを任意の順序で返す可能性があります。これは、エントリは属性の集合として定義され、属性は値の集合であり、集合に順序付けは不要であるという正式な定義に基づいています。

オペレーション

追加

ADD操作は、ディレクトリサーバデータベースに新しいエントリを挿入します。[ 14 ]追加要求の識別名がディレクトリ内に既に存在する場合、サーバは重複エントリを追加せず、追加結果のコードに10進数の68「entryAlreadyExists」を設定します。[ 15 ]

  • LDAP 準拠のサーバーは、エントリを検索する際に、追加要求で送信された識別名を逆参照することはありません。つまり、識別名のエイリアスが解除されることはありません。
  • LDAP 準拠のサーバーは、識別名とすべての属性が命名標準に準拠していることを確認します。
  • 追加するエントリが存在してはならず、直上のエントリが存在する必要があります。
dn : uid = user 、ou = people 、dc = example 、dc = com changetype : add objectClass : top objectClass : person uid : user sn : last-name cn : common-name userPassword : password

上記の例では、uid=user,ou=people,dc=example,dc=comは存在してはならず、ou=people,dc=example,dc=comは存在している必要があります。

バインド（認証）

LDAPセッションが作成されると、つまりLDAPクライアントがサーバーに接続すると、セッションの 認証状態は匿名に設定されます。BIND操作によってセッションの認証状態が確立されます。

シンプルBINDとSASL PLAINは、ユーザーのDNとパスワードを平文で送信する可能性があるため、シンプルまたはSASL PLAINを使用する接続は、トランスポート層セキュリティ（TLS）を使用して暗号化する必要があります。サーバーは通常、指定されたエントリ内の属性とパスワードを照合しますuserPassword 。匿名BIND（DNとパスワードが空の場合）は、接続を匿名状態にリセットします。

SASL （簡易認証およびセキュリティ層）BINDは、 KerberosやTLSで送信されるクライアント証明書など、幅広いメカニズムを通じて認証サービスを提供します。 [ 16 ]

BINDは、バージョン番号を整数で送信することでLDAPプロトコルのバージョンも設定します。クライアントがサーバーがサポートしていないバージョンを要求した場合、サーバーはBINDの応答でプロトコルエラーのコードを返す必要があります。通常、クライアントはLDAPv3を使用する必要があります。これはプロトコルのデフォルトですが、LDAPライブラリでは必ずしもデフォルトではありません。

LDAPv2ではセッションの最初の操作としてBINDを実行する必要がありましたが、LDAPv3では必須ではありません。LDAPv3では、BIND要求が成功するたびにセッションの認証状態が変更され、BIND要求が失敗するたびにセッションの認証状態がリセットされます。

消去

エントリを削除するには、LDAPクライアントは適切に構成された削除要求をサーバーに送信します。[ 17 ]

  • 削除リクエストには、削除するエントリの識別名が含まれている必要があります。
  • 削除リクエストにリクエストコントロールを付加することもできます
  • サーバーは削除リクエストを処理する際にエイリアスを参照しません
  • 削除リクエストによって削除できるのは、リーフエントリ（下位エントリを持たないエントリ）のみです。一部のサーバでは、エントリに下位エントリが存在するかどうかを示す操作属性をサポートしており、また一部のサーバでは、その属性を含むエントリの下位エントリ数を示すhasSubordinates操作属性numSubordinates[ 18 ]numSubordinatesをサポートしています。
  • 一部のサーバーは、アクセス制御の対象となるDNとその下位のすべてのオブジェクトの削除を許可するサブツリー削除要求制御をサポートしています。削除要求はアクセス制御の対象であり、特定の認証状態の接続で特定のエントリの削除が許可されるかどうかは、サーバー固有のアクセス制御メカニズムによって制御されます。

検索して比較する

検索操作は、エントリの検索と読み取りの両方に使用されます。そのパラメータは次のとおりです。

ベースオブジェクト
検索を実行する基準となる基本オブジェクト エントリ (またはルート) の名前。
範囲
baseObject の下にあるどの要素を検索するかを指定します。これは、BaseObject（名前付きエントリのみを検索する、通常は1つのエントリを読み取るために使用される）、singleLevel（ベースDNの直下のエントリ）、またはwholeSubtree（ベースDNから始まるサブツリー全体）のいずれかになります。
フィルター
スコープ内の要素を選択する際に使用する基準。例えば、フィルタは(&(objectClass=person)(|(givenName=John)(mail=john*)))「persons」（objectClassの要素person）を選択しgivenName、mailそれらの属性の値がフィルタアサーションに一致するかどうかを判断します。LDAPデータは大文字と小文字が区別されるという誤解がよくありますが、実際には、一致規則と順序付け規則によって一致、比較、および相対的な値の関係が決定されます。例のフィルタで属性値の大文字と小文字を一致させる必要がある場合は、拡張可能な一致フィルタを使用する必要があります。例：(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))
エイリアス参照
エイリアスエントリ（他のエントリを参照するエントリ）を追跡するかどうか、またその方法
属性
結果エントリで返される属性。
サイズ制限、時間制限
返されるエントリの最大数と、検索実行の最大許容時間。ただし、これらの値は、サーバーが設定するサイズ制限と時間制限を上書きすることはできません。
タイプのみ
属性値ではなく、属性タイプのみを返します。

サーバーは一致するエントリと、場合によっては継続参照を返します。これらは任意の順序で返される場合があります。最終結果には結果コードが含まれます。

比較操作は、DN、属性名、および属性値を受け取り、名前付きエントリにその値を持つ属性が含まれているかどうかを確認します。

修正する

MODIFY操作は、LDAPクライアントがLDAPサーバーに既存のエントリの変更を要求するために使用されます。[ 19 ]存在しないエントリを変更しようとすると失敗します。MODIFY要求は、サーバーによって実装されたアクセス制御の対象となります。

MODIFY操作では、エントリの識別名（DN）と変更シーケンスを指定する必要があります。シーケンス内の各変更は、次のいずれかである必要があります。

  • 追加（属性にまだ存在していない新しい値を追加します）
  • 削除（既存の値を削除する）
  • 置換（既存の値を新しい値に置き換える）

属性に値を追加する LDIF の例:

dn : dc = example 、dc = com changetype : modify add : cn cn :追加する新しいcn値-

既存の属性の値を置き換えるには、replaceキーワードを使用します。属性が複数の値を持つ場合、クライアントは更新する属性の値を指定する必要があります。

エントリから属性を削除するには、キーワードdeleteと変更タイプ指定子を使用しますmodify。属性が複数の値を持つ場合、クライアントは削除する属性の値を指定する必要があります。

また、Modify-Increment拡張[ 20 ]も存在し、これを使用すると、増分可能な属性値を指定された量だけ増加させることができます。LDIFを用いた以下の例では、employeeNumber次のように増加します5。 

dn : uid = user.0 、ou = people 、dc = example 、dc = com changetype : modify increment : employeeNumber employeeNumber : 5 -

LDAPサーバーがレプリケーショントポロジーにある場合、LDAPクライアントは更新後の検索ではなく、更新後の検証にポストリード制御を使用することを検討すべきである。[ 21 ]ポストリード制御は、アプリケーションが更新後に検索要求を発行する必要がないように設計されている。レプリケーションの結果整合性モデルでは、更新が正常に行われたかどうかを確認するためだけにエントリを取得するのは適切ではない。LDAPクライアントは、設計者がLDAPクライアントとサーバーの間にロードバランサーやLDAPプロキシ、あるいはその両方を配置している可能性があるため、各要求で同じディレクトリサーバーに接続すると想定すべきではない。

DNの変更

DNの変更（エントリの移動/名前変更）は、新しいRDN（相対識別名）、オプションで新しい親のDN、そしてエントリ内の古いRDNに一致する値を削除するかどうかを示すフラグを受け取ります。サーバーはディレクトリのサブツリー全体の名前変更をサポートしている場合があります。

更新操作はアトミックです。他の操作は新しいエントリか古いエントリのいずれかを参照します。一方、LDAPは複数の操作のトランザクションを定義していません。エントリを読み込んでから変更した場合、その間に別のクライアントがそのエントリを更新している可能性があります。ただし、サーバーはこれをサポートする拡張機能[ 22 ]を実装する場合があります。

延長された操作

拡張操作は、元のプロトコル仕様には含まれていなかった新しい操作を定義できる汎用LDAP操作です。StartTLSは最も重要な拡張機能の一つです。その他の例としては、キャンセルやパスワード変更などがあります。

TLS を開始

StartTLS操作は、接続時にトランスポート層セキュリティ（ SSL の後継）を確立します。データの機密性（第三者によるデータの閲覧を防止）やデータ整合性保護（データの改ざんを防止）を提供できます。TLS ネゴシエーション中、サーバーは自身の ID を証明するために X.509 証明書を送信します。クライアントも自身の ID を証明するために証明書を送信できます。送信後、クライアントはSASL /EXTERNAL を使用できるようになります。SASL/EXTERNAL を使用することで、クライアントはサーバーに対し、より低いレベル（TLS など）で提供される資格情報から自身の ID を導出するよう要求します。技術的にはサーバーはより低いレベルで確立された任意の ID 情報を使用できますが、通常は TLS によって確立された ID 情報を使用します。

サーバーは、多くの場合、別のポート (デフォルトでは 636) で非標準の「LDAPS」(「セキュア LDAP」、一般に「LDAP over SSL」と呼ばれる) プロトコルもサポートしています。LDAPS は、次の 2 つの点で LDAP と異なります。1) 接続時に、クライアントとサーバーは、LDAP メッセージが転送される前に TLS を確立します (StartTLS 操作なし)。2) TLS の終了時に LDAPS 接続を閉じる必要があります。

一部の「LDAPS」クライアントライブラリは通信を暗号化するだけで、ホスト名と提供された証明書内の名前を照合しません。[ 23 ]

放棄する

Abandon操作は、メッセージIDで指定された操作をサーバーに中止するよう要求します。サーバーはこの要求に応じる必要はありません。Abandon操作も、正常に中止された操作も、応答を送信しません。同様のCancel拡張操作は応答を送信しますが、すべての実装でサポートされているわけではありません。

バインド解除

アンバインド操作は、未完了の操作をすべて破棄し、接続を閉じます。応答はありません。この名称は歴史的な由来であり、バインド操作の反対ではありません。 [ 24 ]

クライアントは接続を閉じるだけでセッションを中止できますが、Unbindを使用する必要があります。[ 25 ] Unbindを使用すると、サーバーは接続を正常に閉じ、クライアントが接続を放棄したことを検出するまでしばらくの間保持していたリソースを解放できます。また、サーバーはキャンセル可能な操作をキャンセルし、キャンセル不可能な操作に対しては応答を送信しないように指示します。[ 26 ]

URIスキーム

LDAP のURI (Uniform Resource Identifier)スキームが存在し、クライアントはこれをさまざまなレベルでサポートし、サーバーは参照と継続参照を返します (RFC 4516 を参照)。 

ldap://ホスト:ポート/DN?属性?スコープ?フィルター?拡張子

以下で説明するコンポーネントのほとんどはオプションです。

  • ホストは、検索する LDAP サーバーのFQDNまたは IP アドレスです。
  • port は、LDAP サーバーのネットワーク ポート(デフォルト ポート 389)です。
  • DNは検索ベースとして使用する識別名です。
  • 属性は取得する属性のコンマ区切りのリストです。
  • scope は検索範囲を指定し、「base」(デフォルト)、「one」、または「sub」を指定できます。
  • filterは検索フィルタです。例えば、(objectClass=*)RFC 4515 で定義されています。
  • 拡張機能は、LDAP URL 形式の拡張機能です。

例えば、「ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com」は にある John Doe のエントリ内のすべてのユーザー属性を参照しますldap.example.comが、「ldap:///dc=example,dc=com??sub?(givenName=John)」はデフォルトサーバのエントリを検索します（ホストを省略する3つのスラッシュと、属性を省略する2つの疑問符に注意してください）。他のURLと同様に、特殊文字はパーセントエンコードする必要があります。

LDAP over SSLにも同様の非標準ldapsURIスキームがあります。これは、標準スキームを用いたStartTLSオペレーションで実現されるLDAP over TLSと混同しないでくださいldap。

スキーマ

サブツリー内のエントリの内容は、ディレクトリ情報ツリー (DIT) の構造に関する一連の定義と制約である ディレクトリ スキーマによって管理されます。

ディレクトリサーバーのスキーマは、サーバーが保持できる情報の種類を規定する一連のルールを定義します。スキーマには、以下のような要素が含まれます。

  • 属性構文 - 属性に格納できる情報の種類に関する情報を提供します。
  • 一致ルール - 属性値との比較方法に関する情報を提供します。
  • 一致ルールの使用 - 特定の一致ルールと組み合わせて使用​​できる属性タイプを示します。
  • 属性タイプ -オブジェクト識別子(OID) と、特定の属性を参照できる名前のセットを定義し、その属性を構文と一致ルールのセットに関連付けます。
  • オブジェクト クラス - 属性の名前付きコレクションを定義し、必須属性とオプション属性のセットに分類します。
  • 名前形式 - エントリの RDN に含める必要がある属性セットのルールを定義します。
  • コンテンツ ルール - エントリと組み合わせて使用​​できるオブジェクト クラスと属性に関する追加の制約を定義します。
  • 構造ルール - 特定のエントリが持つことができる従属エントリの種類を制御するルールを定義します。

属性はディレクトリに情報を格納する要素であり、スキーマはエントリで使用できる属性のルール、それらの属性が持つことができる値の種類、およびクライアントがそれらの値と対話する方法を定義します。

クライアントは、適切なサブスキーマ サブエントリを取得することで、サーバーがサポートするスキーマ要素について知ることができます。

スキーマはオブジェクトクラスを定義します。各エントリは、スキーマで定義された名前付きクラスを含む objectClass 属性を持つ必要があります。エントリのクラスのスキーマ定義は、エントリが表すオブジェクトの種類（例：個人、組織、ドメイン）を定義します。オブジェクトクラス定義は、値を必ず含む属性のリストと、値を含むことができる属性のリストも定義します。

例えば、人物を表すエントリは、「top」クラスと「person」クラスに属するとします。「person」クラスに属するには、エントリに「sn」属性と「cn」属性を含める必要があり、「userPassword」、「telephoneNumber」などの属性も含めることができます。エントリは複数のObjectClasses値を持つことができるため、各エントリは、それが表すオブジェクトクラスの和集合から構成される、オプション属性と必須属性の複合体を持ちます。ObjectClassesは継承可能であり、1つのエントリは、エントリ自体の利用可能な属性と必須属性を定義する複数のObjectClasses値を持つことができます。objectClassのスキーマに相当するものは、オブジェクト指向プログラミングにおけるクラス定義とインスタンスであり、それぞれLDAPオブジェクトクラスとLDAPエントリを表します。

ディレクトリサーバーは、エントリの subschemaSubentry 操作属性で指定されたベース DN のエントリを制御するディレクトリスキーマを公開することができます。(操作属性はユーザー情報ではなくディレクトリの操作を記述し、明示的に要求された場合にのみ検索から返されます。)

サーバー管理者は、提供されているスキーマ要素に加えて、追加のスキーマエントリを追加できます。組織内の個々の人物を表すスキーマは、ホワイトページスキーマと呼ばれます。

セキュリティの脆弱性

LDAPインジェクション

LDAPインジェクションはSQLインジェクションに似たコンピュータセキュリティ攻撃であり、 LDAPを実装したアプリケーションがユーザー入力を適切にサニタイズできなかった場合に発生する可能性があります。[ 27 ]

例えば、LDAP検索クエリで、ユーザーが名前（cn属性）で人を検索できるとします。悪意のあるユーザーは、有効な名前を*、そのcn属性を持つ任意のオブジェクトに一致する文字に置き換える可能性があります。アプリケーションがこの攻撃に対して脆弱な場合、検索ユーザーが表示権限のない属性が表示される可能性があります。[ 28 ]

LDAPインジェクション脆弱性は、変数をエスケープすることで軽減されます。エスケープは、識別名用と検索文字列用の2つの異なるエンコード関数によって実現されます。これは、それぞれ異なる特殊文字を使用できるためです。一部のウェブフレームワークには、エスケープ機能が組み込まれています。[ 29 ]

中間者攻撃

TCP/IPの他の部分と同様に、LDAPは元々暗号化なしで作成されました。そのため、中間者攻撃（攻撃者がバインドプロセス中に資格情報を傍受する）に対して脆弱です。この攻撃は、資格情報を含むすべてのバインドにおいてLDAPSまたはStartLDAPを要求することで軽減できます。[ 30 ]

バリエーション

サーバー運用の大部分は実装者または管理者の判断に委ねられています。そのため、サーバーは様々なシナリオに対応できるように設定できます。

例えば、サーバー内のデータ保存形式は規定されておらず、サーバーはフラットファイルやデータベースを使用するか、あるいは他のサーバーへのゲートウェイとしてのみ機能します。アクセス制御は標準化されていませんが、一般的に使用されているモデルは存在します。ユーザーのパスワードは、各ユーザーのエントリ内、あるいは他の場所に保存される可能性があります。サーバーは、必要に応じて操作の実行を拒否したり、様々な制限を課したりする可能性があります。

LDAPの大部分は拡張可能です。例えば、新しい操作を定義できます。コントロールによってリクエストとレスポンスを変更し、例えば検索結果のソートを要求することができます。新しい検索スコープとバインドメソッドを定義できます。属性には、セマンティクスを変更できる オプションを持たせることができます。

その他のデータモデル

LDAPが普及するにつれ、ベンダーはそれを他のサービスへのアクセスプロトコルとして提供してきました。実装では、LDAP/X.500モデルを模倣するようにデータが再構成されますが、このモデルにどの程度忠実に従うかは様々です。例えば、 LDAP経由でSQLデータベースにアクセスするソフトウェアは存在しますが、LDAPはそのような用途には適していません。[ 31 ] X.500サーバーもLDAPをサポートする場合があります。

同様に、以前は他の種類のデータストアに保存されていたデータがLDAPディレクトリに移動されることもあります。例えば、Unixのユーザーとグループの情報はLDAPに保存され、PAMやNSSモジュールを介してアクセスできます。LDAPは、他のサービスによって認証や認可（認証済みのユーザーがどのサービスでどのような操作を実行できるか）によく使用されます。例えば、Active Directoryでは認証段階でKerberosが使用され、認可段階でLDAPが使用されます。

このようなデータモデルの例としては、GLUEスキーマ[ 32 ]があります。これはLDAPに基づく分散情報システムで使用され、ユーザー、アプリケーション、およびサービスがグリッドインフラストラクチャ内に存在するサービスとその構造や状態に関する詳細情報を検出できるようにします。

使用法

LDAPサーバーは、自身で処理できないリクエストに対して、他のサーバーへの参照を返すことがあります。そのため、LDAPエントリには命名構造が必要です。これにより、特定の識別名（DN）を持つサーバーを特定できます。DNはX.500ディレクトリで定義され、LDAPでも使用されている概念です。組織内のLDAPサーバーを特定するもう1つの方法は、DNSサーバーレコード（SRV）です。

example.orgというドメインを持つ組織は、トップレベルのLDAP DN dc=example, dc=org（dcはドメインコンポーネントを意味します）を使用できます。LDAPサーバーの名前もldap.example.orgの場合、組織のトップレベルのLDAP URLは になりますldap://ldap.example.org/dc=example,dc=org。

X.500 [2008] と LDAPv3 の両方で、主に 2 つの命名スタイルが使用されています。これらは ITU 仕様と IETF RFC で文書化されています。元の形式では、トップレベルオブジェクトを国オブジェクトとして扱います（例c=US： 、c=FR）。ドメインコンポーネントモデルでは、上記のモデルが使用されます。国に基づく命名の例としてはl=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR、 、または米国では などが挙げられますcn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US。

参照

参考文献

  1. ^ 「Network Working Group RFC 4511」 IETF.org. 2006年6月1日. 2014年4月4日閲覧。
  2. ^ 「ディレクトリサービスLDAP」 . Oracle.com . 2014年4月4日閲覧。
  3. ^ LDAPとは？ Gracion.com. 2013年7月17日閲覧。
  4. ^ 「OpenLDAPディレクトリサービスの紹介」OpenLDAP . 2016年2月1日閲覧。
  5. ^ J. Sermersheim (2006年6月). Lightweight Directory Access Protocol (LDAP): The Protocol . Network Working Group. doi : 10.17487/RFC4511 . RFC 4511 .提案された標準。RFC 3771、2830  、および2251は 廃止されます。この文書で定義されるコアプロトコル操作は、X.500 (1993) ディレクトリ抽象サービス [X.511] のサブセットにマッピングできます。ただし、LDAP操作とX.500ディレクトリアクセスプロトコル (DAP) 操作の間には1対1のマッピングはありません。
  6. ^ 「LDAP（Lightweight Directory Access Protocol）認証とは？」Red Hat . 2022年6月3日.
  7. ^ 「LDAP - 軽量ディレクトリアクセスプロトコル」 Webopedia.com、1996年12月4日。 2014年4月5日閲覧。
  8. ^ X.500シリーズ- ITU-T勧告X.500からX.521
  9. ^ Howes, Tim. 「軽量ディレクトリアクセスプロトコル：X.500 Lite」（PDF） . 2012年12月26日閲覧。
  10. ^ 「LDAPの歴史」 . Cyber​​ Matters . 2013年4月9日. 2014年10月5日閲覧。
  11. ^ 「サービス名とトランスポートプロトコルポート番号レジストリ」 IANA 。2021年3月24日閲覧。
  12. ^ RFC3494
  13. ^この記事は、2008 年 11 月 1 日より前にFree On-line Dictionary of Computing のLightweight+Directory+Access+Protocolから取得した資料に基づいており、 GFDLバージョン 1.3 以降 の「再ライセンス」条件に基づいて組み込まれています。
  14. ^ RFC4511のセクションを追加
  15. ^ LDAP結果コード
  16. ^ IANA における SASL メカニズム
  17. ^ RFC4511: 削除リクエスト
  18. ^ボアハムドラフト (numSubordinates)
  19. ^ RFC4511の修正セクション
  20. ^ Zeilenga, K. LDAP 変更増分拡張. doi : 10.17487/RFC4525 . RFC 4525 .
  21. ^ Zeilenga, K.軽量ディレクトリアクセスプロトコル（LDAP）読み取りエントリ制御。IETF。doi : 10.17487 / RFC4527。RFC 4527 。
  22. ^インターネットドラフト LDAP トランザクション draft-zeilenga-ldap-txn-15.txt
  23. ^ Shibboleth セキュリティアラート 20120227
  24. ^ Tools.ietf.org
  25. ^ Tools.ietf.org
  26. ^ Tools.ietf.org
  27. ^ 「LDAPインジェクションの説明」。OWASP。OWASP Foundation 。
  28. ^ Abdollahi, Ali (2025). Webアプリケーション侵入テスト初心者ガイド. Wiley. ISBN 9781394295609。
  29. ^ LDAPインジェクション防止チートシート（レポート）。OWASP Foundation。
  30. ^ジョンソン、リチャード (2025). LDAPアーキテクチャと実装：開発者とエンジニアのための決定版リファレンス. HiTeX Press.
  31. ^ Openldap.org
  32. ^ Open Grid フォーラム: プロジェクトホーム

出典

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Lightweight_Directory_Access_Protocol&oldid=1322707584」から取得