☰

在 LDAP 中，绑定 DN 到底是什么？

tag-icon • tag-icon ldap
在 LDAP 中，绑定 DN 到底是什么？

我编写了各种连接到 LDAP 服务器并运行查询的代码，但对我来说，它们总是很神奇。有一件事我不太理解，那就是绑定 DN 的概念。下面是一个使用ldapsearchopenldap 提供的命令行工具的示例。（忽略缺少身份验证。）

ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]

这部分的目的和功能是什么-D dc=example,dc=com？为什么我们需要绑定到目录层次结构中的特定位置？是为了确定我的查询应该应用于目录的哪个部分吗？例如，如果目录的根节点是dc=com，并且它有两个子节点（dc=foo和dc=bar），也许我希望我的查询针对dc=foo,dc=com子树而不是dc=bar,dc=com子树？

答案1

绑定 DN 是您在 LDAP 中绑定的对象，它授予您执行任何操作的权限。一些（许多？）LDAP 实例不允许匿名绑定，或者不允许使用匿名绑定执行某些操作，因此您必须指定 bindDN 以获取执行该操作的身份。

以类似的非技术方式 - 是的，这有点牵强 - 银行会允许您走进去查看他们的利率而无需向他们提供任何身份证明，但是为了开设账户或取款，您必须拥有他们知道的身份 - 这个身份就是 bindDN。

答案2

不要混淆基本 DN和绑定DN。

  • 这基本 DN搜索的起点。搜索将从哪里开始。非常不言自明。

  • 这绑定DNDN 基本上是您用来对 LDAP 进行身份验证的凭证。
    使用 bindDN 时，它通常会附带一个与之关联的密码。

换句话说，当您指定 bindDN 时，您正在使用该对象安全访问权限来遍历 LDAP 树。

现在，琴弦dc=example,dc=com不是最好的例子对于 bindDN，因为它是 LDAP 树的“域”。直流代表领域组件每个 LDAP 树都用 dc=string,dc=string,... 形式的字符串定义其根。但这些字符串不像树的其余部分那样是“路径”。

有效示例为：

  • dc=example,dc=com
  • dc=mydomain
  • dc=avery,dc=long,dc=list,dc=of,dc=domains

但是，这些根元素是不可分割的。虽然它们看起来可能像树的其余部分一样由几个元素组成，代表一条路径，但它们不是. （因此对于这些元素，逗号“，”不是元素分隔符。）

因此，对于该dc=avery,dc=long,dc=list,dc=of,dc=domains示例，这意味着这是整个元素名称。它不是元素的路径。它不能分解为子元素：没有对象dc=of,dc=domains。

与文件系统路径进行类比：

想象一下将C:驱动器命名为D:\my\folder\。 其中的每个路径看起来都会像这样D:\my\folder\my\real\path，这会令人困惑，因为真正的文件路径应该是 \my\real\path，对吗？ 好吧，这就是 LDAP 的基础（根）的样子，带有一组 dc= 元素。

相关链接：Oracle 文档：“ldapsearch 工具”http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html

进一步阅读

没有标准规定 LDAP DIT 的任何特定结构，因此目录服务器可以以任何类型的层次结构保存条目。但是，有一些共同的约定。[...]
例如，如果组织的域为 example.com，则命名上下文可能类似于 dc=example,dc=com。命名上下文有多个组件是完全合法的，因此仅仅因为服务器具有 DN 为 dc=example,dc=com 的条目，并不一定必须存在 DN 为 dc=com 的条目。

相关内容