Why is the user@domain and cn=user,dc=domain not equivalent?

Question

I've setup a Simple AD on AWS that I can finally authenticate against with LDAP. I don't understand why I was unable to use dc= which is widely suggested everywhere but am able to use @domain.

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

Are these not supposed to be equivalent? Will @domain always work or it specific to Simple AD?

Answer 1

The OP gave additional information of the location of the Administrator user so he has to use cn=Administrator,ou=Users,dc=ldap,dc=pathontheback,dc=org

EDIT: Made a typo, it has to be: cn=Administrator,cn=Users,dc=ldap,dc=pathontheback,dc=org

Users is a container, not OU.

Answer 2

A bit of reading on LDAP and DNs might be in order here.

A distinguished name (usually just shortened to DN) both uniquely identifies an entry and describes its position in the DIT. A DN is much like an absolute path on a filesystem, except whereas filesystem paths usually start with the root of the filesystem and descend the tree from left to right, LDAP DNs ascend the tree from left to right.

So if you want to specify the DN of the administrator account in your domain, you need to specify the full (and correct) path to it. As your screenshot shows (and the fact that it's standard in AD), the administrator account is in the Users container.

Note that I used the word container and not OU. Not every container in AD is an OU and most of the default ones that exist actually aren't. You can tell at a glance by comparing the icon for Users with the icon for Domain Controllers. If that's too subtle, you can also check the actual objectClass attribute for each one. OU's will contain organizationalUnit and normal containers will have container. In a DN value, OU's have "OU=" as their RDN key, and containers have "CN=" as their RDN key.

In any case, you don't really have to figure this all out manually when you're looking for something's DN day-to-day. Just open (or query) the properties of the object you're looking for and check the distinguishedName attribute. That will give you the full and correct path without trying to manually string together a bunch of RDNs and contexts yourself.

TL;DR The DN for the administrator account in your example domain is CN=Administrator,CN=Users,DC=ldap,DC=patontheback,DC=org

That said, it's better practice to keep doing what you're doing and use the UPN ([email protected]) for bind accounts against AD because they're less likely to change than a DN value.

Answer 3

@Ryan Bolger answer has a very good explanation. I wanted to include a more complete example for those who like to see what happens with various commands.

For example I use the following for the binddn distinguishedName: CN=auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan

-D 'CN=auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan'

or the UPN userPrincipalName: [email protected]

-D '[email protected]'

The following lines will produce the same output below

ldapsearch -x -h '192.168.0.10' -D 'CN=Auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan' -w password -b"cn=auser,OU=IT Dev,OU=localdomain Users,dc=localdomain,dc=lan" -s sub "objectclass=*"   

or

ldapsearch -x -h '192.168.0.10' -D '[email protected]' -w password -b"cn=auser,OU=IT Dev,OU=localdomain Users,dc=localdomain,dc=lan" -s sub "objectclass=*"

The same output will be generated

# extended LDIF
#
# LDAPv3
# base <cn=auser,OU=IT Dev,OU=localdomain Users,dc=localdomain,dc=lan> with scope subtree
# filter: objectclass=*
# requesting: ALL
#

# auser, IT Dev, localdomain Users, localdomain.lan
dn: CN=GitLab,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: auser
givenName: auser
distinguishedName: CN=auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan
instanceType: 4
whenCreated: 20190221073536.0Z
whenChanged: 20190221080923.0Z
displayName: auser
uSNCreated: 108114404
memberOf: CN=groupofusers,OU=localdomain Groups,DC=localdomain,DC=lan
uSNChanged: 108116177
name: auser
userAccountControl: 66048
codePage: 0
countryCode: 0
primaryGroupID: 513
accountExpires: 9223372036854775807
sAMAccountName: auser
sAMAccountType: 805306368
userPrincipalName: [email protected]
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=localdomain,DC=lan
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 131952101637691018

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1