ライトウェイトディレクトリアクセスプロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ライトウェイトディレクトリアクセスプロトコルLDAP / ˈɛldæp / )はインターネットプロトコル(IP)ネットワークを介して分散ディレクトリ情報サービスにアクセスおよび保守するための、ベンダーに依存しないオープンな業界標準のアプリケーションプロトコルです。[2]ディレクトリサービスは、ネットワーク全体でユーザー、システム、ネットワーク、サービス、およびアプリケーションに関する情報を共有できるようにすることで、イントラネットおよびインターネットアプリケーションの開発において重要な役割を果たします。[3] 例として、ディレクトリサービスは、多くの場合、企業の電子メールディレクトリ などの階層構造を持つ、組織化された一連のレコードを提供する場合があります。同様に、電話帳は、住所と電話番号を持つ加入者のリストです。

LDAPは、記述言語ASN.1を使用して、 Request for Comments (RFC)と呼ばれる一連のインターネット技術特別調査委員会(IETF)の標準トラックの出版物で指定されています最新の仕様はバージョン3で、RFC 4511 [4]として公開されています(技術仕様へのロードマップはRFC4510によって提供されています)。

LDAPの一般的な使用法は、ユーザー名とパスワードを格納するための中央の場所を提供することです。これにより、さまざまなアプリケーションやサービスをLDAPサーバーに接続して、ユーザーを検証できます。[5]

LDAPは、 X.500標準に含まれる標準のより単純なサブセットに基づいていますこの関係のため、LDAPはX.500-liteと呼ばれることもあります。[6]

歴史

電話帳の作成と管理を約70年行った後、通信会社のディレクトリ要件に対する理解は十分に深まりました。これらの企業は、ディレクトリサービスの概念を情報技術コンピュータネットワークに導入し、その入力は包括的なX.500仕様[7]で、1980年代に国際電気通信連合(ITU) によって作成された一連のプロトコルになりました。

X.500ディレクトリサービスは、従来、X.500ディレクトリアクセスプロトコル(DAP)を介してアクセスされていました。これには、Open Systems Interconnection(OSI)プロトコルスタックが必要でした。LDAPは元々、より単純な(そして現在では広く普及している) TCP / IPプロトコルスタックを介してX.500ディレクトリサービスにアクセスするための軽量の代替プロトコルとなることを目的としていました。このディレクトリアクセスのモデルは、 DIXIEおよびDirectory AssistanceServiceプロトコル から借用されました。

このプロトコルは、1993年頃にミシガン大学のTim HowesIsodeLimitedのSteveKille 、 NexorのColin RobbinsおよびPerformance SystemsInternationalWengyikYeongによってDIXIEおよびDASの後継として最初に作成されました[8 ]Critical AngleInc。のMarkWahl、Tim Howes、およびSteve Killeは、インターネットエンジニアリングタスクフォース(IETF)の支援の下、新しいバージョンのLDAPであるLDAPv3の作業を1996年に開始しました。LDAPv3は、1997年に最初に公開され、LDAPv2に取って代わり、拡張性のサポートが追加され、Simple Authentication and Security Layerであり、プロトコルを1993年版のX.500に適切に適合させました。LDAPv3仕様自体、およびLDAPv3に機能を追加する多数の拡張機能のさらなる開発は、IETFを通じて行われました。

LDAPの初期のエンジニアリング段階では、ライトウェイトディレクトリブラウジングプロトコルLDBP )として知られていました。これは、ディレクトリの参照と検索を超えてプロトコルの範囲が拡張され、ディレクトリ更新機能が含まれるように名前が変更されました。DAPの前身ほどネットワークを集中的に使用せず、帯域幅の使用量が比較的少ないため、インターネット経由でより簡単に実装できるため 、 Lightweightという名前が付けられました。

LDAPは、X.500の新しいバージョン、 XML対応ディレクトリ(XED)、ディレクトリサービスマークアップ言語(DSML)、サービスプロビジョニングマークアップ言語(SPML)、サービスロケーションプロトコル(SLP)など、後続のインターネットプロトコルに影響を与えました。また、 MicrosoftActiveDirectoryの基盤としても使用されます

プロトコルの概要

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

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

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

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

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

ディレクトリ構造

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

  • エントリは、一連の属性で構成されます。
  • 属性には、名前(属性タイプまたは属性の説明)と1つ以上の値があります。属性はスキーマで定義されます(以下を参照)。
  • 各エントリには一意の識別子があります:その識別名(DN)。これは、エントリ内のいくつかの属性から構築された相対識別名(RDN)と、それに続く親エントリのDNで構成されます。DNを完全なファイルパスと見なし、RDNを親フォルダー内の相対ファイル名と見なします(たとえば/foo/bar/myfile.txt、DNの場合myfile.txt、RDNになります)。

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

LDAPデータ交換フォーマット(LDIF)で表される場合、エントリは次のようになります(LDAP自体はバイナリプロトコルです)。

dn:cn = John Doe、dc = example、dc = com
 cn:John Doe
 与えられた名前:ジョン
 sn:Doe
 電話番号:+1 888 555 6789
 電話番号:+1 888 555 1232
 メール:[email protected]
 マネージャー:cn = Barbara Doe、dc = example、dc = com
 objectClass:inetOrgPerson
 objectClass:organizationalPerson
 objectClass:人
 objectClass:トップ

" dn"はエントリの識別名です。これは属性でもエントリの一部でもありません。" cn=John Doe"はエントリのRDN(Relative Distinguished Name)であり、 " dc=example,dc=com"は親エントリのDNです。ここで、 " dc"は 'ドメインコンポーネント'を示します。他の行は、エントリの属性を示しています。cn属性名は通常、一般名の場合は「dc」、ドメインコンポーネントの場合は「mail」、電子メールアドレスの場合は「 」、姓の場合は「」などのニーモニック文字列snです。

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

LDAPが順序を定義することはめったにありません。サーバーは、属性の値、エントリ内の属性、および検索操作によって検出されたエントリを任意の順序で返す場合があります。これは正式な定義に基づいています。エントリは属性のセットとして定義され、属性は値のセットであり、セットを並べ替える必要はありません。

操作

追加

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

  • LDAP準拠のサーバーは、エントリを検索しようとしたときに、追加要求で送信された識別名を逆参照することはありません。つまり、識別名のエイリアスが解除されることはありません。
  • LDAP準拠のサーバーは、識別名とすべての属性が命名規則に準拠していることを確認します。
  • 追加するエントリは存在してはならず、直属の上司が存在している必要があります。
dn:uid = user、ou = people、dc = example、dc = com
changetype:追加
objectClass:top
objectClass:person
uid:ユーザー
sn:姓
cn:一般名
userPassword:パスワード

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

バインド(認証)

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

SimpleBINDおよびSASLPLAINは、ユーザーのDNとパスワードをプレーンテキストで送信できるため、SimpleまたはSASL PLAINを使用する接続は、トランスポート層セキュリティ(TLS)を使用して暗号化する必要があります。userPassword サーバーは通常、名前付きエントリの属性に対してパスワードをチェックします。Anonymous BIND(空のDNとパスワードを使用)は、接続を匿名状態にリセットします。

SASL (Simple Authentication and Security Layer)BINDは、 KerberosTLSで送信されるクライアント証明書など、さまざまなメカニズムを通じて認証サービスを提供します。[14]

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

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

削除

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

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

検索して比較

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

baseObject
検索が実行されるベースオブジェクトエントリ(または場合によってはルート)の名前。
範囲
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*)))
derefAliases
エイリアスエントリ(他のエントリを参照するエントリ)をフォローするかどうか、およびフォローする方法。
属性
結果エントリで返す属性。
sizeLimit、timeLimit
返されるエントリの最大数、および検索を実行できる最大時間。ただし、これらの値は、サーバーがサイズ制限と時間制限に課す制限を上書きすることはできません。
typesOnly
属性値ではなく、属性タイプのみを返します。

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

比較操作は、DN、属性名、および属性値を取得し、指定されたエントリにその値を持つ属性が含まれているかどうかを確認します。

変更

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

MODIFY操作では、エントリーの識別名(DN)を指定し、一連の変更を行う必要があります。シーケンスの各変更は、次のいずれかである必要があります。

  • add(属性にまだ存在していてはならない新しい値を追加します)
  • 削除(既存の値を削除)
  • 置換(既存の値を新しい値に置き換えます)

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

dn:dc = example、dc = com
changetype:変更
追加:cn
cn:追加される新しいcn値
-

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

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

インクリメント可能な属性値を指定された量だけインクリメントできるようにするModify-Increment拡張機能[18]もあります。LDIFを使用した次の例では、次のようにインクリメントemployeeNumber5ます。

dn:uid = user.0、ou = people、dc = example、dc = com
changetype:変更
増分:employeeNumber
従業員番号:5
-

LDAPサーバーがレプリケートされたトポロジにある場合、LDAPクライアントは、更新後の検索ではなく、読み取り後のコントロールを使用して更新を検証することを検討する必要があります。[19]読み取り後の制御は、アプリケーションが更新後に検索要求を発行する必要がないように設計されています。レプリケーションの結果整合性モデルのために更新が機能したことを確認することのみを目的としてエントリを取得するのは不適切な形式です。LDAPクライアントは、アーキテクトがLDAPクライアントとサーバーの間にロードバランサーまたはLDAPプロキシ、あるいはその両方を配置している可能性があるため、要求ごとに同じディレクトリサーバーに接続していると想定しないでください。

DNの変更

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

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

拡張操作

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

StartTLS

StartTLS操作は、接続でトランスポート層セキュリティSSLの子孫)を確立します。データの機密性(第三者による監視からデータを保護するため)および/またはデータの整合性保護(データを改ざんから保護するため)を提供できます。TLSネゴシエーション中に、サーバーはX.509証明書を送信してIDを証明します。クライアントは、そのIDを証明するために証明書を送信することもできます。その後、クライアントはSASLを使用できます/外部の。SASL / EXTERNALを使用することにより、クライアントはサーバーに、下位レベルで提供される資格情報(TLSなど)からIDを取得するように要求します。技術的には、サーバーは下位レベルで確立されたID情報を使用できますが、通常、サーバーはTLSによって確立されたID情報を使用します。

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

一部の「LDAPS」クライアントライブラリは、通信のみを暗号化します。提供された証明書の名前に対してホスト名をチェックしません。[21]

放棄

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

バインド解除

Unbind操作は、未処理の操作をすべて破棄し、接続を閉じます。応答がありません。この名前は歴史的な由来であり、バインド操作の反対ではありません。[22]

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

URIスキーム

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

ldap:// host:port / DN?attributes?scope?filter?extensions

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

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

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

ldapsLDAP overSSLにも同様の非標準URIスキームがあります。ldapこれは、標準スキーム を使用したStartTLS操作を使用して実現されるTLSを使用したLDAPと混同しないでください。

スキーマ

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

Directory Serverのスキーマは、サーバーが保持できる情報の種類を管理する一連のルールを定義します。これには、次のような多くの要素があります。

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

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

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

スキーマはオブジェクトクラスを定義します。各エントリには、スキーマで定義された名前付きクラスを含むobjectClass属性が必要です。エントリのクラスのスキーマ定義は、エントリが表す可能性のあるオブジェクトの種類(個人、組織、ドメインなど)を定義します。オブジェクトクラス定義は、値を含む必要がある属性のリストと、値を含む可能性のある属性のリストも定義します。

たとえば、人を表すエントリは、クラス「top」および「person」に属している可能性があります。「person」クラスのメンバーシップでは、エントリに「sn」属性と「cn」属性を含める必要があり、エントリに「userPassword」、「telephoneNumber」、およびその他の属性を含めることもできます。エントリには複数のObjectClasses値が含まれる場合があるため、各エントリには、それが表すオブジェクトクラスの結合から形成されたオプションおよび必須の属性セットの複合体があります。ObjectClassesは継承でき、単一のエントリには、エントリ自体の使用可能で必要な属性を定義する複数のObjectClasses値を含めることができます。、LDAPobjectClassおよびLDAPエントリをそれぞれ表します。

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

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

バリエーション

サーバー操作の多くは、実装者または管理者が決定する必要があります。したがって、サーバーはさまざまなシナリオをサポートするように設定できます。

たとえば、サーバー内のデータストレージが指定されていません。サーバーはフラットファイルやデータベースを使用する場合もあれば、他のサーバーへのゲートウェイになる場合もあります。アクセス制御は標準化されていませんが、作業が行われており、一般的に使用されているモデルがあります。ユーザーのパスワードは、エントリまたは他の場所に保存される場合があります。サーバーは、必要に応じて操作の実行を拒否し、さまざまな制限を課す場合があります。

LDAPのほとんどの部分は拡張可能です。例:新しい操作を定義できます。 コントロールは、たとえばソートされた検索結果を要求するために、要求と応答を変更する場合があります。新しい検索スコープとBindメソッドを定義できます。属性には、セマンティクスを変更する可能性 のあるオプションを含めることができます。

その他のデータモデル

LDAPが勢いを増すにつれて、ベンダーはLDAPを他のサービスへのアクセスプロトコルとして提供しています。次に、実装はLDAP / X.500モデルを模倣するようにデータを再キャストしますが、このモデルがどの程度厳密に実行されるかは異なります。たとえば、LDAPは簡単には対応できませんが、LDAPを介してSQLデータベースにアクセスするソフトウェアがあります。[25] X.500サーバーはLDAPもサポートする場合があります。

同様に、以前に他のタイプのデータストアに保持されていたデータがLDAPディレクトリに移動されることがあります。たとえば、Unixのユーザーおよびグループ情報をLDAPに保存し、PAMおよびNSSモジュールを介してアクセスできます。LDAPは、認証や承認(特定の認証済みユーザーがどのサービスで実行できるアクション)のために他のサービスによってよく使用されます。たとえば、Active Directoryでは、認証ステップでKerberosが使用され、承認ステップでLDAPが使用されます。

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

使用法

LDAPサーバーは、それ自体では実行できない要求に対して、他のサーバーへの参照を返す場合があります。これには、LDAPエントリの命名構造が必要です。これにより、X.500ディレクトリで定義され、LDAPでも使用される概念である特定の識別名(DN)を保持するサーバーを見つけることができます。組織のLDAPサーバーを見つける別の方法は、DNSサーバーレコード(SRV)です。

ドメインexample.orgを持つ組織は、最上位のLDAP DN dc=example,dc=orgdcはドメインコンポーネントを意味します)を使用できます。LDAPサーバーの名前もldap.example.orgの場合、組織の最上位のLDAPURLはになりldap://ldap.example.org/dc=example,dc=orgます。

X.500 [2008]とLDAPv3の両方で、主に2つの一般的な命名スタイルが使用されています。これらは、ITU仕様およびIETFRFCに文書化されています。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. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ 「ネットワークワーキンググループRFC4511」IETF.org。2006-06-01 2014年4月4日取得
  3. ^ 「ディレクトリサービスLDAP」Oracle.com 2014年4月4日取得
  4. ^ LDAPとは何ですか?Gracion.com。2013年7月17日に取得。
  5. ^ 「OpenLDAPディレクトリサービスの紹介」OpenLDAP 2016年2月1日取得
  6. ^ 「LDAP-ライトウェイトディレクトリアクセスプロトコル」Webopedia.com 2014年4月5日取得
  7. ^ X.500シリーズ-ITU-TRec。X.500からX.521
  8. ^ ハウズ、ティム。「ライトウェイトディレクトリアクセスプロトコル:X.500 Lite」(PDF)2012年12月26日取得
  9. ^ 「LDAPの先史時代」サイバー事項2013-04-09 2014年10月5日取得
  10. ^ 「サービス名およびトランスポートプロトコルポート番号レジストリ」IANA 2021年3月24日取得
  11. ^ RFC3494
  12. ^ RFC4511のセクションを追加
  13. ^ LDAP結果コード
  14. ^ IANAでのSASLメカニズム
  15. ^ RFC4511:削除リクエスト
  16. ^ ボアハムドラフト(numSubordinates)
  17. ^ RFC4511のセクションを変更
  18. ^ Zeilenga、K。LDAPModify -IncrementExtension土井10.17487 / RFC4525RFC4525_
  19. ^ Zeilenga、K。ライトウェイトディレクトリアクセスプロトコル(LDAP)読み取りエントリコントロールIETF土井10.17487 / RFC4527RFC4527_
  20. ^ インターネットドラフトLDAPトランザクションdraft-zeilenga-ldap-txn-15.txt
  21. ^ Shibbolethセキュリティアラート20120227
  22. ^ Tools.ietf.org
  23. ^ Tools.ietf.org
  24. ^ Tools.ietf.org
  25. ^ Openldap.org
  26. ^ オープングリッドフォーラム:プロジェクトホーム

メモ

さらに読む

外部リンク