Мне удалось заставить некоторые из моих серверов linux аутентифицировать пользователей на моем сервере каталогов LDAP, но у меня возникли проблемы с попытками сделать это с помощью nss_ldap и pam_ldap во FreeBSD.
Исходя из официальных документов FreeBSD здесь: http://www.freebsd.org/doc/en/articles/ldap-auth/client.html
Я устанавливаю 2 пакета и создаю файл конфигурации /usr/local/etc/ldap.conf, а также символическую ссылку на этот файл в том же каталоге, nss_ldap.conf. Согласно документации, они оба могут использовать один и тот же файл конфигурации. Я делаю это очень простым, пока не смогу заставить его работать:
ldap.conf / nss_ldap.conf:
base dc=corp,dc=example,dc=org
host 192.168.0.100
ldap_version 3
binddn cn=admin,dc=corp,dc=example,dc=org
bindpw secret
Насколько я могу судить, NSS работает. «Getent passwd» показывает информацию из каталога LDAP, а также локальные данные.
Теперь я хочу пройти аутентификацию, поэтому добавляю строку в /etc/pam.d/sshd:
# auth
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
auth sufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass debug
auth required pam_unix.so no_warn try_first_pass
Я перезапускаю ssh (не уверен, что это необходимо), а затем пытаюсь войти в систему с пользователем LDAP, который не существует локально (coryj). Он не работает тихо, и журналы показывают:
Sep 9 13:13:54 freebsd-testbox sshd[12684]: pam_ldap: error trying to bind as user "uid=coryj,ou=Users,dc=corp,dc=example,dc=org" (Invalid credentials)
Почему он пытается установить связь с пользователем, которого я пытаюсь аутентифицировать, когда я указал binddn / bindpw? Я также пробовал rootbinddn с файлом .secret с тем же результатом. В linux binddn вроде работает, а здесь его игнорируют.
Я знаю, что мои файлы ldap.conf и pam потребуют дополнительной работы, просто пытаюсь убедить эту штуку привязать как admin при аутентификации на этом этапе.
Вот как вкратце работает аутентификация LDAP:
joeblow. Ваш клиент дает это имя серверу вместе с вашим паролем (который вы вводите).pam_opie.so. Вы сказали, что этого достаточно, поэтому он просто будет двигаться дальше, если не найден. Думаю, дело не в этом.pam_opieaccess.so. В этом случае это необходимо, поэтому pam_opieaccess.so должен сказать «да, он в порядке». Я предполагаю, что этот модуль просто проверяет список учетных записей, помеченных как «должен пройти авторизацию через OPIE», что joeblow не включен. Там написано ОК./usr/local/lib/pam_ldap.so получает очередь. Это то, о чем вы заботитесь. binddn и bindpw, чтобы спросить "эй, у меня есть это joeblow здесь, как его настоящее имя? »Сервер отвечает uid=joeblow,ou=Users,dc=corp,dc=example,dc=org.pam_ldap.so отключается и пытается привязать как uid=joeblow,ou=Users,dc=corp,dc=example,dc=org с введенным вами паролем. Если он может связать, вы в деле. Если нет, то нет.Таким образом, ошибка, которую вы получаете, означает, что на шаге 2.3.2 произошел сбой, вероятно, из-за неправильного пароля. Возможно, есть другая проблема с joeblow привязки к серверу, проверьте журналы сервера LDAP для получения дополнительных сведений.
В binddn и bindpw параметры управляют начальным поиском, который преобразует имя пользователя в отличительное имя LDAP - проверка пароля LDAP выполняется путем привязки к каталогу LDAP в качестве пользователя, пытающегося аутентифицироваться (если вы смогли выполнить привязку, значит, проверка прошла успешно).
Видеть man pam_ldap для получения дополнительной информации об этом.
В вашем случае я подозреваю, что либо пароль, который вы вводите для coryj неверно (возможно, их пароль LDAP поврежден?), или coryj не может подключиться к каталогу по другим причинам. Попробуйте связать с ldapwhoami или ldapsearch и посмотрите, не появится ли полезное сообщение об ошибке.