Проблема с вертикальным расположением центра в Safari

Кажется, что функция ldap_bind требует DN, а не RDN, независимо от того, что говорит документ. Если это так, то:

• Номер 1. {$user}@{$domain} не является правильно отформатированным DN, следовательно: Invalid DN syntax
• Номер 2: test не правильно отформатированное DN, следовательно: Invalid DN syntax

Информацию о строчном представлении форматирования DN см. в RFC4514

проверьте с помощью известного хорошего инструмента

Насколько я могу судить, номер 3 является единственным правильным одним из четырех предоставленных. Сервер каталогов указал в ответе BIND, что он не смог проверить, что предоставленный пароль testpass соответствует паролю, который хранится в его базе данных. В этом случае я рекомендую проверять пароль с помощью известного хорошего инструмента, такого как ldapsearch.

ldapsearch -h hostname -p port              \
    -D 'uid=test,dc=ci,dc=mycompany,dc=com' \
    -w 'testpass' -s base '(&)' 1.1

Этот ldapsearch BIND в каталог как «uid = test, dc = ci, dc = mycompany , dc = com ', используя пароль testpass и извлекает DN записи uid=test. Если это не удается с ошибкой «недопустимые учетные данные», то есть следующие возможности:

• testpass неверный пароль
• некоторые серверы каталогов могут быть настроены для установки выводит код на «недопустимые учетные данные» независимо от истины. Причиной этого является удержание информации от злоумышленника
• , запись uid=test не существует. Вышеупомянутый балл указывает, что это приведет к «недопустимым учетным данным». Нет смысла сообщать злоумышленнику, что запись не существует, что обеспечило бы злоумышленнику дополнительную информацию (у него есть меньше DN, чтобы попробовать).

жаргон и LDAP-talk

В интересах использования правильного жаргона:

• $ldaprdn не является RDN, это DN. RDN являются компонентами DN

см. Также

• LDAP: Освоение поисковых фильтров
• LDAP: методы программирования