LDAPサーバーに接続してクエリを実行するさまざまなコードを記述しましたが、それは常に私にとっては無意味です。私が本当に理解していないことの1つは、バインドDNの概念です。ldapsearchopenldapから入手できるコマンドラインツールを使用した例を次に示します。（認証の欠如は無視してください。）
ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]
-D dc=example,dc=comこの部分の目的と機能は何ですか？ディレクトリ階層内の特定の場所にバインドする必要があるのはなぜですか？クエリを適用するディレクトリのどの部分を確立するのですか？たとえば、ディレクトリのルートノードがであり、dc=com2つの子（dc=fooおよびdc=bar）がある場合、クエリをdc=foo,dc=comサブツリーではなくdc=bar,dc=comサブツリーにしたいのでしょうか？
回答:
バインドDNは、LDAP内でバインドするオブジェクトであり、実行しようとしていることをすべて実行するためのアクセス許可を付与します。一部の（多くの？）LDAPインスタンスは、匿名バインドを許可しないか、特定の操作が匿名バインドで実行されることを許可しないため、bindDNを指定してその操作を実行するためのIDを取得する必要があります。
同様の非技術的な方法で-はい、これはストレッチです-銀行は、あなたに彼らに何らかのIDを与えることなく歩き回って金利を見ることができますが、口座を開設したりお金を引き出したりするには、彼らが知っているアイデンティティを持つために-そのアイデンティティはbindDNです。
間で混乱しないベースDNとバインドDN。
検索のbaseDNが出発点です。検索を開始する場所。かなり自明です。
バインドDN DNは基本的にあなたがLDAPに対して認証するために使用している資格です。bindDNを使用する場合、通常、それに関連付けられたパスワードが付属します。
つまり、bindDNを指定すると、そのオブジェクトセキュリティアクセスを使用してLDAPツリーを通過します。
現在、文字列dc = example、dc = comは、LDAPツリーの「ドメイン」であるため、bindDNの最良の例ではありません。dcはドメインコンポーネントを表し、すべてのLDAPツリーはdc = string、dc = string、...の形式の文字列でルートを定義しますが、これらの文字列はツリーの他の部分のような「パス」ではありません。
有効な例は次のとおりです。
しかし、これらのルート要素は分割できません。それらは、ツリーの他の部分と同様にパスを表すいくつかの要素のように見えますが、そうではありません。たとえば、最後の例では、オブジェクトdc = of、dc = domainsは存在しません。
C：ドライブに「D：\ my \ folder \」のような名前を付けることを想像してください。そこにあるすべてのパスは、「D：\ my \ folder \ my \ real \ path」のようになりますが、実際のファイルパスは\ my \ real \ pathになるので混乱しますか？それは、LDAPのベース（ルート）がdc =要素のセットでどのように見えるかです。
関連リンク：http : //docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html