Форум проекта Pro-LDAP.ru
Интеграция => Учётные записи в *nix системах => Тема начата: marawu от 19 Сентябрь 2016, 14:53:27
-
Добрый день, пытаюсь настроить аутентификацию на Debian 8 с помощью вашей книжки OpenLDAP и Ubuntu на практике и застрял на 5 пункте, не могу аутентифицироваться ни по ssh ни локально:
Sep 19 17:46:37 LDAPClient sshd[807]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.92 user=name.user
Sep 19 17:46:37 LDAPClient sshd[807]: pam_ldap(sshd:auth): Authentication failure; user=name.user
Sep 19 17:46:39 LDAPClient sshd[807]: Failed password for name.user from 192.168.60.92 port 63122 ssh2
Sep 19 17:46:43 LDAPClient sshd[807]: pam_ldap(sshd:auth): Authentication failure; user=name.user
Sep 19 17:46:45 LDAPClient sshd[807]: Failed password for name.user from 192.168.60.92 port 63122 ssh2
Sep 19 17:49:49 LDAPClient login[475]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=name.user
Sep 19 17:49:49 LDAPClient login[475]: pam_ldap(login:auth): Authentication failure; user=name.user
Sep 19 17:49:53 LDAPClient login[475]: FAILED LOGIN (1) on '/dev/tty1' FOR 'name.user', Authentication failure
Поискал в гугле, не могу найти ничего толкового, больше запутался. Можете подсказать с чем связана проблема?
-
Здравствуйте! В том материале, который Вы упоминаете, механизмы PAM и NSS настраиваются на использование демона nlscd (то есть это отличается от упомянутой Вами ранее библиотеки pam_ldap от PADL). Посмотрите этот материал (http://pro-ldap.ru/forum/index.php?topic=55.msg235#msg235).
По существу вопроса трудно сказать что-то определённое: до пятой главы там было произведено огромное количество настроек, где-то можно было элементарно запутаться. Судя по логам, вероятнее всего что у учётки, от которой аутентифицируется nlscd, нет доступа к паролям учёток пользователей. Нужно смотреть в сторону ACL.
Егор
-
Здравствуйте! В том материале, который Вы упоминаете, механизмы PAM и NSS настраиваются на использование демона nlscd (то есть это отличается от упомянутой Вами ранее библиотеки pam_ldap от PADL). Посмотрите этот материал (http://pro-ldap.ru/forum/index.php?topic=55.msg235#msg235).
По существу вопроса трудно сказать что-то определённое: до пятой главы там было произведено огромное количество настроек, где-то можно было элементарно запутаться. Судя по логам, вероятнее всего что у учётки, от которой аутентифицируется nlscd, нет доступа к паролям учёток пользователей. Нужно смотреть в сторону ACL.
Егор
У меня уже был openLDAP сервер, я просто не много "допилил". Я добавил в свою учетную запись objectClass: shadowAccount и атрибуты shadowLastChange: 15140, shadowMin: 0, shadowMax: 99999, shadowWarning: 7 и моя учетная запись выглядит вот так:
dn: uid=user.name,ou=People,dc=example,dc=com
uidNumber: 1537
mailQuota: 1048576
gidNumber: 3174
objectClass: top
objectClass: inetOrgPerson
objectClass: mailRecipient
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
userPassword::
homeDirectory: /home/user.name
mailHost: imap.example.com
displayName::
ou: ou=People,dc=example,dc=com
cn:
mail: user.name@example.com
sn:
givenName:
preferredLanguage: ru_RU
uid: user.name
loginShell: /bin/bash
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
А вот ACL касающийся паролей:
olcAccess: {0}to attrs=userPassword,shadowLastChange
by peername.ip="xx.xx.xx.xx" read
by self write
by anonymous auth
by dn="cn=admin,dc=example,dc=com" write
by dn="uid=ldap-proxy,ou=Special Users,dc=example,dc=com" read
by dn="cn=replica,dc=example,dc=com" read
by group.exact="cn=Directory Administrators,dc=example,dc=com" manage
by * none
/etc/nslcd.conf
uid nslcd
gid nslcd
uri ldap://wsldap.example.com
base dc=example,dc=com
binddn uid=ldap-proxy,ou=Special Users,dc=example,dc=com
bindpw #######
rootpwmoddn cn=admin,dc=example,dc=com
base group ou=groups,dc=example,dc=com
base passwd ou=people,dc=example,dc=com
base shadow ou=people,dc=example,dc=com
bind_timelimit 5
timelimit 10
idle_timelimit 60
ssl start_tls
tls_reqcert allow
tls_cacertfile /etc/ldap/ssl/godaddyCA.crt
nss_initgroups_ignoreusers bin,daemon,games,lp,mail,nobody,nslcd,root,sshd,sync,uucp
nss_initgroups_ignoreusers sys,man,news,proxy,www-data,backup,list,irc,gnats
Пробовал даже от имени admin сделать, но всё равно пароль не принимается. Хотя с этой же учетной запись делаю синхронизацию на OS X и там я могу без проблем залогиниться
-
Здравствуйте! Все настройки выглядят вполне себе неплохо.
Простой запрос пароля от ldap-proxy возвращает пароль?
ldapsearch -x -LLL -D 'uid=ldap-proxy,ou=Special Users,dc=example,dc=com' -W 'uid=user.name' userPassword
Подсоединение к каталогу от имени пользователя работает?
ldapsearch -x -LLL -D 'uid=user.name,ou=People,dc=example,dc=com' -W 'uid=user.name' dn
NSS работает?
id user.name
Зачем нужны все эти shadow-атрибуты? Я их никогда не использовал и не знаю их смысла. Возможно, они что-то ограничивают =( . Попробуйте без них.
Наконец, возможно, коряво настроился сам PAM. Вы же никаких настроек там не меняли, Debian всё прописал автоматически? Бывает, автоматические настройки нужно дорабатывать вручную. Но это не просто, поэтому попробуйте сначала все предыдущие тесты. Если не получится, покажите /etc/pam.d/common-auth
Егор
-
Здравствуйте! Все настройки выглядят вполне себе неплохо.
Простой запрос пароля от ldap-proxy возвращает пароль?
ldapsearch -x -LLL -D 'uid=ldap-proxy,ou=Special Users,dc=example,dc=com' -W 'uid=user.name' userPassword
root@LDAPClient:~# ldapsearch -x -LLL -D 'uid=ldap-proxy,ou=Special Users,dc=example,dc=com' -W 'uid=user.name' userPassword
Enter LDAP Password:
dn: uid=user.name,ou=People,dc=example,dc=com
userPassword:: e1NTSEF9MkxDZDFNK0VQc2dpSmt0ZHRlb0JkQXlvY3RKNEdUVzk=
Подсоединение к каталогу от имени пользователя работает?
Код: [Выделить]
ldapsearch -x -LLL -D 'uid=user.name,ou=People,dc=example,dc=com' -W 'uid=user.name' dn
Не могу присоединиться от имени своего пользователя
root@LDAPClient:~# ldapsearch -x -LLL -D 'uid=user.name,ou=People,dc=example,dc=com' -W 'uid=user.name' dn
Enter LDAP Password:
No such object (32)
Вот еще часть ACL, из-за которых может быть проблема
olcAccess: {2}to dn.subtree="ou=People,dc=example,dc=com"
by peername.ip="192.168.250.78" read
by peername.ip="xx.xx.xx.xx" read
by peername.ip="192.168.250.204" read
by dn="cn=replica,dc=example,dc=com" read
by group.exact="cn=Directory Administrators,dc=example,dc=com" manage
by dn.subtree="ou=Special Users,dc=example,dc=com" read
by dn.subtree="ou=Special Users,dc=example,dc=com" read
by * none
olcAccess: {5}to *
by peername.ip="xx.xx.xx.xx" read
by peername.ip="192.168.250.204" read
by group.exact="cn=Directory Administrators,dc=example,dc=com" manage
by dn="cn=admin,dc=example,dc=com" write
by dn="cn=replica,dc=example,dc=com" read
by dn.subtree="ou=Special Users,dc=example,dc=com" read
by * none
Правильно ли я понимаю, что не работает, потому, что у пользователя нет прав на чтение каталогов?
NSS работает?
id user.name
root@LDAPClient:~# id user.name
uid=1537(user.name) gid=3174 groups=3174
Зачем нужны все эти shadow-атрибуты? Я их никогда не использовал и не знаю их смысла. Возможно, они что-то ограничивают =( . Попробуйте без них.
С ними я пока не разбирался, просто старался максимально приблизиться к образцу в инструкции. Без них тоже самое:(
Наконец, возможно, коряво настроился сам PAM. Вы же никаких настроек там не меняли, Debian всё прописал автоматически? Бывает, автоматические настройки нужно дорабатывать вручную. Но это не просто, поэтому попробуйте сначала все предыдущие тесты. Если не получится, покажите /etc/pam.d/common-auth
Егор
root@LDAPClient:~# grep -v '^#' /etc/pam.d/common-auth
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so minimum_uid=1000 use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
-
Правильно ли я понимаю, что не работает, потому, что у пользователя нет прав на чтение каталогов?
Думаю, что в проблема в этом. Есть ли смысл ограничивать для пользователей доступ на чтение? Целесообразней хотя бы вместо
by * none
сделать
by anonymous none
by * read
Если же пользователям всё-таки нельзя читать каталог, то нужно добиться, чтобы пользователь мог читать хотя бы свою запись, типа
by self read
Но это не так просто, поскольку ACL просматриваются последовательно и нужно, чтобы у пользователя были права на аутентификацию (и, возможно, чтение) на всех уровнях, начиная с базовой записи поиска (dc=example,dc=com). Придётся придумывать очень хитрые ACL.
Егор
-
Правильно ли я понимаю, что не работает, потому, что у пользователя нет прав на чтение каталогов?
Думаю, что в проблема в этом. Есть ли смысл ограничивать для пользователей доступ на чтение? Целесообразней хотя бы вместо
by * none
сделать
by anonymous none
by * read
Если же пользователям всё-таки нельзя читать каталог, то нужно добиться, чтобы пользователь мог читать хотя бы свою запись, типа
by self read
Но это не так просто, поскольку ACL просматриваются последовательно и нужно, чтобы у пользователя были права на аутентификацию (и, возможно, чтение) на всех уровнях, начиная с базовой записи поиска (dc=example,dc=com). Придётся придумывать очень хитрые ACL.
Егор
Да, действительно проблема была в этом, хотя в OS X это не мешало проходить аутентификацию. Самое смешное, что как только я добрался до ACL это была первая мысль, что проблема в этом. Сейчас мне нужно разобраться ещё с несколькими вещами (кэширование паролей, ограничение доступа на основе групп и т.д.), а затем я вернусь к ACL. Могу ли я опять написать в эту ветку, чтобы удостовериться, что я правильно составил ACL?
-
Да, действительно проблема была в этом, хотя в OS X это не мешало проходить аутентификацию.
У Вас в ACL с некоторых ip-адресов есть доступ на чтение всем. Возможно, поэтому на OS X и можно было аутентифицироваться. Либо (Вы где-то упоминали о синхронизации с OS X) при аутентификации в ней данные берутся из локальной копии каталога.
Могу ли я опять написать в эту ветку, чтобы удостовериться, что я правильно составил ACL?
Пишите.