为什么 user@domain 和 cn=user,dc=domain 不等价？

Question

我在 AWS 上设置了一个 Simple AD，我最终可以使用 LDAP 对其进行身份验证。我不明白为什么我无法使用dc=到处都被广泛建议但能够使用@domain.

ldap_bind($ldapconn, "cn=Administrator,dc=ldap,dc=patontheback,dc=org", "<password>");
ldap_bind($ldapconn, "Administrator@ldap.patontheback.org", "<password>");

这些不应该是等效的吗？@domain 会一直工作还是特定于 Simple AD？

Answer 1

OP 提供了管理员用户位置的附加信息，因此他必须使用 cn=Administrator,ou=Users,dc=ldap,dc=pathontheback,dc=org

编辑：打错了，它必须是： cn=Administrator,cn=Users,dc=ldap,dc=pathontheback,dc=org

用户是一个容器，而不是 OU。

Answer 2

一个读取位对LDAP和DN可能是为了在这里。

专有名称（通常简称为 DN）既可以唯一标识条目，又可以描述其在 DIT 中的位置。DN 很像文件系统上的绝对路径，除了文件系统路径通常从文件系统的根开始并从左到右下降树，LDAP DN 从左到右上升树。

因此，如果要指定域中管理员帐户的 DN，则需要指定其完整（且正确）的路径。正如您的屏幕截图所示（以及它在 AD 中的标准事实），管理员帐户位于用户容器中。

请注意，我使用了容器这个词，而不是 OU。并非 AD 中的每个容器都是 OU，而且大多数存在的默认容器实际上都不是。您可以通过比较 的图标Users和 的图标一目了然Domain Controllers。如果这太微妙，您还可以检查objectClass每个的实际属性。OU 将包含organizationalUnit，普通容器将包含container. 在 DN 值中，OU 的 RDN 键为“OU=”，容器的 RDN 键为“CN=”。

在任何情况下，当您每天都在寻找某些东西的 DN 时，您实际上不必手动解决所有这些问题。只需打开（或查询）您要查找的对象的distinguishedName属性并检查属性。这将为您提供完整且正确的路径，而无需尝试自己手动将一堆 RDN 和上下文串在一起。

TL;DR 示例域中管理员帐户的 DN 是CN=Administrator,CN=Users,DC=ldap,DC=patontheback,DC=org

也就是说，更好的做法是继续做你正在做的事情并使用 UPN (user@domain.example.com)来绑定 AD 帐户，因为它们比 DN 值更不可能改变。