Назад | Перейти на главную страницу

Я не могу авторизоваться от клиента с помощью ldap, когда пароль пользователя зашифрован с помощью {SHA} {SSHA}, когда это {CRYPT} работает

Сервер: Centos 7.2, Клиент: Debian 8.6

Проблема в том, что я не могу войти в систему на клиенте, если пароль зашифрован с помощью SHA / SSHA на стороне сервера.

Ldapsearch с клиентской станции работает. Я могу получить attrs с сервера, когда я запрашиваю сервер как пользователь raj3. Он работает с паролем пользователя в кодировке SSHA i CRPYPT.

На стороне сервера пароль был сгенерирован

ldappasswd -s password123 -W -D "cn = admin, dc = pydio, dc = sum, dc = edu, dc = pl" -x "uid = raj3, ou = People, dc = pydio, dc = xxx, dc = edu, dc = pl "

Команда:

getent passwd raj3

хорошо резонирует со стороны клиента.

Что еще, когда у меня есть пароль, закодированный с помощью SHA / SSHA, я могу войти в систему под пользователем raj3 через JXpolorer (из окон в той же сети) на сервер ldap, и я могу увидеть attrs этого пользователя.

Новые подробности 02.09.2019:

На стороне клиента: ibpam-ldap и установка была подготовлена:

aptitude -y  install libnss-ldap libpam-ldap ldap-utils

/etc/pam.d/common-password

password        [success=2 default=ignore]      pam_unix.so obscure
password        [success=1 user_unknown=ignore default=die]     pam_ldap.so try_first_pass
password        requisite                       pam_deny.so
password        required                        pam_permit.so

Я тестировал выше с sha512 в строке:

password        [success=2 default=ignore]      pam_unix.so obscure sha512 

и такая же проблема тоже.

/etc/nsswitch.conf

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] dns
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       ldap

/etc/pam_ldap.conf

pam_password crypt

getent passwd raj3 - работа на клиенте только с локальной учетной записью root на другом локальном счете нет.

Я неправильно понимаю, почему CRYPT работает, но SSHA нет, когда команда getent не работает на учетной записи без полномочий root.

ACL olcAccess: {0} to * by dn = "cn = admin, dc = pydio, dc = sum, dc = edu, dc = pl" записать самостоятельно записать пользователями, прочитанными * auth

Является ли ACL неправильным запрещать пользователю anonymouse видеть дерево ldap? Но почему я могу войти с паролем, зашифрованным CRYPT, с таким ACL? ЭТО сложно решить мной.

Я обнаружил, что "проблема с {SSHA} i {CRYPT}" возникает сама собой:

У меня был неправильный пароль администратора в /etc/pam_ldap.secret. Хорошо, это была моя ошибка. Загадка: почему пользователь с паролем, зашифрованным CRYPT, может авторизоваться / пароль пользователя, зашифрованный SSHA, не может, если пароль в /etc/pam_ldap.secret плохой? Это вызывает головную боль.

Я просто догадываюсь, потому что здесь очень мало информации.

У вас установлен и правильно настроен pam ldap? Кажется, что nss ldap установлен и настроен, однако это только половина того, что вам здесь нужно.

РЕДАКТИРОВАТЬ: у вас, похоже, есть несколько основных проблем, а не одна. Поэтому я предлагаю прочитать это руководство, чтобы начать работу. http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/pamnss.html Это старый и проверенный документ. Это должно помочь вам заставить это работать.