Почему user@domain и cn=user,dc=domain не эквивалентны?

Я установил Simple AD на AWS, с помощью которого я смогу наконец аутентифицироваться с помощью 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?

Источник

3 ответа

Решение

ОП дал дополнительную информацию о местонахождении пользователя-администратора, поэтому он должен использовать 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 очень похож на абсолютный путь в файловой системе, за исключением того, что пути файловой системы обычно начинаются с корня файловой системы и спускаются по дереву слева направо, а DN LDAP поднимаются по дереву слева направо.

Поэтому, если вы хотите указать DN учетной записи администратора в своем домене, вам необходимо указать полный (и правильный) путь к нему. Как показывает ваш скриншот (и тот факт, что он является стандартным в A D), учетная запись администратора находится в контейнере Users.

Обратите внимание, что я использовал слово контейнер, а не OU. Не каждый контейнер в A D является 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) для привязки учетных записей к A D, поскольку вероятность их изменения меньше, чем значение DN.

Источник

Ответ @Ryan Bolger имеет очень хорошее объяснение. Я хотел бы привести более полный пример для тех, кто любит видеть, что происходит с различными командами.

Например, я использую следующее для 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'

или UPN userPrincipalName: gitlab@nmm.lan

-D 'auser@localdomain.lan'

Следующие строки приведут к тому же выводу ниже

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=*"

или же

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

Тот же вывод будет сгенерирован

# 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: auser@localdomain.lan
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
Источник
Другие вопросы по тегам