为什么user @ domain和cn = user，dc = domain不等效？

我已经在AWS上设置了一个简单的AD，我最终可以使用LDAP进行身份validation。我不明白为什么我无法使用dc=这是广泛build议无处不在，但能够使用@domain 。

 ldap_bind($ldapconn, "cn=Administrator,dc=ldap,dc=patontheback,dc=org", "<password>"); ldap_bind($ldapconn, "[email protected]", "<password>");

这些不应该是相当的？ @domain会一直工作还是特定于简单AD？

在这里输入图像说明

OP提供了有关pipe理员用户的位置的额外信息，因此他必须使用cn=Administrator,ou=Users,dc=ldap,dc=pathontheback,dc=org

编辑：犯了一个错字，它必须是： cn=Administrator,cn=Users,dc=ldap,dc=pathontheback,dc=org

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

在这里可能需要阅读一下LDAP和DN。

一个可分辨的名字（通常缩写为DN）都唯一标识了一个条目并描述了它在DIT中的位置。 DN非常类似于文件系统上的绝对path，除了文件系统path通常以文件系统的根目录开始并从左向右下降树，LDAP DN从左到右依次上升树。

所以如果你想在你的域中指定pipe理员账户的DN，你需要指定完整的（和正确的）path。如您的屏幕截图所示（以及AD中的标准），pipe理员帐户位于“用户”容器中。

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

无论如何，当你每天都在寻找某个DN的时候，你并不需要手工把这些全部弄清楚。只要打开（或查询）您正在寻找的对象的属性，并检查distinguishedName属性。这将给你完整而正确的path，而不会尝试自己手动串起一堆RDN和上下文。

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

也就是说，最好的做法是继续做你正在做的事情，并使用UPN （[email protected]）来绑定AD账户，因为它们不太可能改变为DN值。