Вопросы Теги

Я не могу авторизоваться с клиента с помощью 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 не работает на некорневой учетной записи.

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

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

0
задан 3 September 2019 в 14:28
2 ответа

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

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

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

0
ответ дан 5 December 2019 в 01:00

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

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

0
ответ дан 5 December 2019 в 01:00

Теги

Похожие вопросы