為什麼 user@domain 和 cn=user,dc=domain 不等價？
我已經在 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？
OP 提供了有關管理員使用者位置的附加資訊，因此他必須使用
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 很像文件系統上的絕對路徑，除了文件系統路徑通常從文件系統的根開始並從左到右下降樹，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 值更改的可能性更小。