我写了各种代码连接到LDAP服务器并运行查询，但对我来说，这一直是巫术。 有一件事情我不太了解的是绑定DN的概念。 以下是使用openldap提供的ldapsearch命令行工具的示例。 （忽略缺乏身份validation。）
ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]
-D dc=example,dc=com部分是什么目的和function？ 为什么我们需要绑定到目录层次中的特定位置？ 是否要确定我的查询应该应用于哪个目录？ 例如，如果该目录的根节点是dc=com ，并且它有两个孩子（ dc=foo和dc=bar ），也许我希望我的查询是针对dc=foo,dc=com子树而不是dc=bar,dc=com子树？
绑定DN是您绑定到LDAP内部的对象，为您提供执行所有操作的权限。 一些（很多？）LDAP实例不允许匿名绑定，或者不允许使用匿名绑定进行某些操作，所以您必须指定一个bindDN来获取执行该操作的标识。
以类似的非技术性的方式 – 是的，这是一个延伸 – 银行将允许你走进去，看看他们的利率，而不给他们任何types的身份证，但为了开立一个帐户或提取资金，有一个他们知道的身份 – 身份是bindDN。
不要混淆baseDN和bindDN 。
search的baseDN是起点。 它将在哪里开始search。 相当不言自明。
bindDN DN基本上是您用来对LDAP进行身份validation的证书。 当使用bindDN时，通常会附带一个与之相关的密码。
换句话说，当你指定一个bindDN的时候，你正在使用这个对象的安全访问来遍历LDAP树。
现在，stringdc = example，dc = com不是bindDN的最佳示例 ，因为它是LDAP树的“域”。 dc代表域组件 ，每个LDAP树以dc = string，dc = string，…forms的string定义其根，但是这些string不像树的其余部分那样是“path”。
有效的例子是：
但是，这些根源是不可分割的。 他们看起来像是树的其他部分代表path的几个元素，但他们不是 。 例如，在最后一个例子中，对象dc = of，dc = domains不存在。
想象一下，命名你的C：盘符如“D：\ my \ folder \”。 那里的每一条path都会看起来像“D：\ my \ folder \ my \ real \ path”，这会令人迷惑，因为真正的文件path是\ my \ real \ path。 那么，这就是LDAP的基础（根），看起来像一组dc =元素。
相关链接： http : //docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html