Я новичок в SSSD, но думаю, что правильно настроил его, учитывая id {ldap user} возвращает ожидаемые значения uid и gid для нескольких тестовых пользователей. Я использую два сервера CentOS 6.4 в качестве тестовых машин. Один работает с ApacheDS, а другой - с SSSD. Однако, когда я пытаюсь войти в систему через ssh или непосредственно на консоли, используя любого из этих пользователей, мне отказывают в доступе. Я провел последние несколько дней, просматривая журналы SSSD, и я не уверен, где еще искать. Вместо того, чтобы включать все файлы конфигурации, я просто скажу сейчас, что я выполнил следующие authconfig --enablesssd --enablesssdauth --enablelocauthorize --update на клиентском сервере. Проверьте ниже мою конфигурацию SSSD и Вот для журнала SSSD_Default. Сообщите мне, какие дополнительные журналы вы хотели бы увидеть, и я извлечу их как можно скорее.
Спасибо за вашу помощь!
cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = default debug_level = 4 [nss] filter_users = root debug_level = 4 [pam] debug_level = 4 [domain/default] debug_level = 4 ldap_tls_reqcert = never auth_provider = ldap ldap_schema = rfc2307 ldap_search_base = dc=example,dc=net #ldap_group_member = memberUid id_provider = ldap ldap_id_use_start_tls = True chpass_provider = ldap ldap_uri = ldap://sea-ldap-01.app.example.net:10389 cache_credentials = False ldap_tls_cacertdir = /etc/openldap/certs ldap_tls_cacert = /etc/openldap/certs/sea-ldap-01.pem entry_cache_timeout = 600 ldap_network_timeout = 3 #ldap_access_filter = ldap_user_search_base = ou=people,dc=example,dc=net ldap_group_search_base = ou=groups,dc=example,dc=net
Согласно этому журналу, похоже, что поставщик LDAP SSSD потерпел крах и его пришлось перезапустить. Вот почему вам отказано в доступе.
См. В частности:
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND]
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [simple_bind_done] (0x2000): Server returned control [1.3.6.1.4.1.42.2.27.8.5.1].
а затем он переходит в
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [recreate_ares_channel] (0x0100): Initializing new c-ares channel
(Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [resolv_get_family_order] (0x1000): Lookup order: ipv4_first
Эти строки указывают на то, что сервер снова запускается. Предположительно, я бы сказал, что что-то пошло не так при обработке политики паролей ldap на клиенте, поскольку последней вещью перед ее сбоем была ссылка на код LDAP для ldap_pwd_exop.
Проверьте / var / log / messages на наличие признаков сбоя и сообщите об ошибке в CentOS. В идеале установите debuginfo для пакетов sssd, openldap и ding-libs, затем подключитесь к процессу sssd_be с помощью gdb и получите трассировку сбоя для включения в отчет об ошибке.