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?
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.
A bit of reading on LDAP and DNs might be in order here.
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 forDomain Controllers
. If that's too subtle, you can also check the actualobjectClass
attribute for each one. OU's will containorganizationalUnit
and normal containers will havecontainer
. 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.
@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
or the UPN
userPrincipalName: [email protected]
The following lines will produce the same output below
or
The same output will be generated