Я пытаюсь настроить openldap 2.4.33 (созданный из исходного кода в OS X 10.8) для поддержки аутентификации digest-md5, но безуспешно. Я не могу пройти аутентификацию, получаю сообщение об ошибке no secret in database, и я не могу понять почему.
Конфигурация пока ...
У меня есть пользователь, указанный следующим образом:
dn: cn=eb01,ou=bennet,o=meryton
objectclass: Person
objectclass: inetOrgPerson
cn: eb01
givenname: Elizabeth
sn: Bennet
userPassword: pw1
# or try...
#userPassword:: cHcx
#userPassword: {CLEARTEXT}pw1
(и конечных пробелов там нет, я проверял!). У меня есть соответствующие записи olcAuthzRegexp, настроенные для cn = config, чтобы сопоставить идентификаторы аутентификации с правильным dn:
olcAuthzRegexp: uid=([^,]*),cn=digest-md5,cn=auth
ldap:///o=meryton??sub?(cn=$1)
Однако при поиске я не могу пройти аутентификацию:
% ldapsearch -H ldap://localhost:8389 -LLL -b o=meryton \
-Y DIGEST-MD5 -X u:eb01 -w pw1
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
%
Отладочная болтовня с сервера подсказывает, что я правильно выполняю сопоставление:
5120be85 <==slap_sasl2dn: Converted SASL name to cn=eb01,ou=bennet,o=meryton
5120be85 slap_sasl_getdn: dn:id converted to cn=eb01,ou=bennet,o=meryton
5120be85 SASL Canonicalize [conn=1000]: slapAuthzDN="cn=eb01,ou=bennet,o=meryton"
5120be85 SASL [conn=1000] Failure: no secret in database
5120be85 send_ldap_result: conn=1000 op=1 p=3
5120be85 send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database"
Однако, хотя эта болтовня включает журналы запросов доступа:
5120be85 => access_allowed: auth access to "cn=eb01,ou=bennet,o=meryton" "cn" requested
болтовня делает не включать любые журналы запросов на доступ к userPassword атрибут.
То есть это появляется как будто сервер в этой конфигурации не знает, что userPassword Атрибут - это секрет, по которому он должен выполнять аутентификацию digest-md5. Я не настраивал это, но (а) у меня сложилось впечатление, что это секрет по умолчанию, (б) я не могу найти ничего в руководствах или руководстве по openldap, которое, кажется, указывает, как это настроить, и (в) не могу найти в различных частях онлайн-советов ничего, даже намекающего на необходимость этого.
Простая аутентификация - это нормально.
Это немного странная конфигурация - пароли в открытом виде и отсутствие базы данных SASL, потому что это должна быть фиктивная / облегченная конфигурация LDAP для запуска регрессионных тестов, но у меня полностью закончились идеи о том, что читать next, или любые другие ключевые слова или фрагменты файла журнала для Google. Похоже, что ни у кого на всей планете не было этой проблемы (это не который экзотика), поэтому я подозреваю, что я как-то нарушил это с другой частью конфигурации. Но я считаю, что понимаю, что делает все остальное в конфигурации, и ... нет ничего очевидного.
У меня неприятное предчувствие, что это будет потрясающе простое решение, но сейчас я открыт для любых идей.
Этот удар, удар, удар, удар, который вы слышите, - это звук головы и стены в великолепной гармонии.
Проблема была не в конфигурации, а в запросе. В вызове ldapsearch у меня было -X u:eb01. Но это для авторизации через прокси; для привязки к конкретному имени пользователя необходимо -U eb01.
Спасибо Ховард Чу в 2003 году.