PAM/NSS через TLS

[I have no name!@ldap ~]$

Проблема только в этом? Или в чем?

Права на файлы смотрите, пользователю с «no name» не хватает прав, чтобы прочитать libnssldap.conf или ldap.secret

>пользователю с «no name» не хватает прав, чтобы прочитать libnssldap.conf или ldap.secret

крутая идея...

nscd запущен?

крутая идея...

Всё зависит от конфигурации. само собой, если в ldap.secret пароль менеджера с правом записи, то к нему доступ давать не нужно.

nscd запущен?

Это не ко мне. Но если запущен - замочить.

[I have no name!@ldap ~]$ Проблема только в этом? Или в чем?

Да, проблема в этом. Это говорит о том, что где-то ошибка, не правда ли? =)И логин по полторы минуты меня не устраивает.
в ldap.secret лежит не admin, а специально созданный аккаунт.
Даже если бы лежал admin, это не вопрос данной темы. Это вопрос безопасности.
Вот права на файлы:

-rw-------  1 root root        * May 30 18:12 ldap.secret
-rw-r--r--  1 root root     9556 May 30 15:29 nss_ldap.conf
-rw-r--r--  1 root root     8833 May 30 15:28 pam_ldap.conf

[root@pki etc]# service nscd stop
Service nscd is not running.                                  [PASSED]

Это говорит о том, что где-то ошибка, не правда ли? =)

Конечно! Это говорит о том, что права на файлы у вас выданы неверные. Если бы я использовал linux почаще, я бы указал конкретные файлы. А так у вас банально после входа проблемного пользователя getent passwd не работает, отсюда и проблемы. Показывайте nss_ldap.conf

И логин по полторы минуты меня не устраивает.

В nss_ldap.conf:
bind_timelimit 2
bind_policy soft

И, вероятно, login по полторы минуты уйдет в прошлое.

Даже если бы лежал admin, это не вопрос данной темы. Это вопрос безопасности.

Совершенно очевидно, что это вопрос безопасности, однако за ради поиска сути проблемы (т.е. дебага) можно и дать право на чтение, например так:

Создаем пользователя в ldap, помещаем его в специальную группу, этой группе и даем право на чтение ldap.secret

Ну это если вы конечно заинтересованы в поиске проблемы.

Долгий логин уйдет после того, как источник проблемы будет устранен. Там, где логин нормально работает, он не долгий.
В том-то и дело, что даже

-rw-rw-rw-  1 root root        * May 30 16:00 ldap.secret

Просто мне не понятно, на какие файлы права могут быть не верно выданы. Ибо на те файлы, что приходят в голову сразу (мы все тут про них говорим), права на всех машинах идентичны.
И да, зря не упомянул, что без TLS везде все работает прекрасно.

bind_policy soft

Добавьте, что-то изменилось?

На что только люди не готовы, лишь бы не покупать божественную инфраструктуру AD

ну да, изменилось. Теперь он не переподключается к LDAP по несколько попыток.
Сразу говорит, что «I have no name»

Т.е. одну проблему мы решили, осталось разобраться с ihnn.

Покажите slapd.conf без комментариев (только пароль не нужно)

slapd.conf

concurrency 32
defaultsearchbase "dc=uriit, dc=local"
gentlehup on
sizelimit -1
loglevel -1
password-hash {SSHA}
pidfile                 /var/run/slapd.pid
argsfile                /var/run/slapd.args
rootDSE /etc/openldap/rootdse.ldif
threads 32
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/openldap/ssl/cacert.pem
TLSCertificateFile /etc/openldap/ssl/newcert.pem
TLSCertificateKeyFile /etc/openldap/ssl/newkey.pem
TLSVerifyClient demand
include /etc/openldap/slapd-access.conf

slapd-access.conf:

.....
access to dn="ou=People,dc=uriit,dc=local"
        by dn="cn=pamnss,ou=Services,dc=uriit,dc=local" read

access to dn="ou=Groups,dc=uriit,dc=local"
        by dn="cn=pamnss,ou=Services,dc=uriit,dc=local" read
.....

И да, вспомнилась старая проблема. Когда-то я на нее забил, теперь вспомнил.
Дело в том, что поиск по базе LDAP через TLS работает. Но если делать

openssl s_client -connect host.domain.ru:389  -CAfile /etc/openldap/ssl/cacert.pem -cert /etc/openldap/ssl/newcert.pem -key /etc/openldap/ssl/newkey.pem -cipher SSLv2

Если все так, как вы говорите, а именно

1) с этим же сервером LDAP другие nss_ldap-tls клиенты работают нормально
2) если на проблемном сервере отключить ldap-tls то тоже все нормально

значит остается предположить, что что-то не так с правами на

tls_cacertfile /etc/openldap/ssl/cacert.pem
tls_cert /etc/openldap/ssl/newcert.pem
tls_key /etc/openldap/ssl/newkey.pem

Либо отключайте проверку tls клиента/сервера и проверяйте без неё.

то получаю ошибку рукопожатия. Вот и думаю, критично ли это.

Как вариант, для проверки:
/etc/openldap/ldap.conf:

TLS_REQCERT never

а в nss_ldap.conf:

tls_checkpeer no

Спасибо большое за помощь, проблема была в правах на папку
/etc/openldap/ssl
привел права в соответствие, и все заработало.
P.S. Действительно ведь, стоило обратить внимание на то, что ldapsearch через TLS работал только от рута...