Несколько дней я работал над интеграцией LDAP. Теперь, после настройки почти всего, что мне нужно, я пришел к последней стене: необходимость использования вторичных групп, которые берутся с сервера LDAP.
Поведение:
[root@sr-servicesLin ~]# id hmr
uid=2956(hmr) gid=10000(ldapusers) groups=10000(ldapusers)
[root@sr-servicesLin ~]# getent group repo
repo:*:25958:
[root@sr-servicesLin ~]# groups hmr
hmr : ldapusers
Состав группы репо (это группа LDAP):
[root@sr-dns ~]# ldapsearch -x -H ldaps://ldap.eibind.iss -b "dc=eibind,dc=iss" "(&(objectclass=posixGroup)(cn=repo)(gidNumber=*))"
# extended LDIF
#
# LDAPv3
# base <dc=eibind,dc=iss> with scope subtree
# filter: (&(objectclass=posixGroup)(cn=repo)(gidNumber=*))
# requesting: ALL
#
# repo, Groups, eibind.iss
dn: cn=repo,ou=Groups,dc=eibind,dc=iss
objectClass: posixGroup
objectClass: top
cn: repo
memberUid: hmr
memberUid: jcontreras
memberUid: hectoriss
gidNumber: 25958
# search result
search: 2
result: 0 Success
Сценарий:
ОС: Centos 6.7
Пакеты:
· Ldap работает с ssl
· Sssd установлен
· Nss-pam-ldapd
Проблема в:
Когда я использую id
command Я не получаю вторичные группы каждого пользователя, только основную (которая поступает из LDAP, поэтому соединение есть).
Собираюсь приклеить основные файлы конфигурации, думаю, что все расставил по своим местам. Во время серфинга между сайтами я читал, что не рекомендуется одновременно настраивать sssd и nsswitch, например configure ldap
и sss
для "синтаксического анализа" всех желаемых данных с сервера, что это может быть беспорядок для сервера или что-то в этом роде. Несмотря на это, я написал ldap и sss в качестве источников данных.
nsswitch.conf
#
# /etc/nsswitch.conf
#
passwd: files ldap sss
shadow: files ldap sss
group: files ldap sss
#hosts: db files nisplus nis dns
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files ldap sss
netgroup: files ldap sss
publickey: nisplus
automount: files ldap sss
aliases: files ldap nisplus
Как видите, я прошу ldap и sss (sssd) о passwd, shadow и группах. В сочетании с этой конфигурацией у меня также есть файл sssd.conf, который выглядит следующим образом:
sssd.conf
[sssd]
config_file_version = 2
services = nss, pam, autofs
domains = default
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[domain/default]
ldap_tls_reqcert = allow
auth_provider = ldap
ldap_schema = rfc2307bis
krb5_realm = eibind.iss
ldap_search_base = dc=eibind,dc=iss
ldap_group_member = uniqueMember
id_provider = ldap
ldap_id_use_start_tls = True
chpass_provider = ldap
ldap_uri = ldaps://ldap.eibind.iss/
#ldap_user_object_class = user
#ldap_group_object_class = group
#ldap_group_search_base = OU=Groups,DC=eibind,DC=iss
#ldap_group_search_scope = one
#ldap_group_object_class = group
ldap_chpass_uri = ldaps://ldap.eibind.iss/
krb5_kdcip = ldap.eibind.iss
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/cacerts
entry_cache_timeout = 600
ldap_network_timeout = 3
krb5_server = ldap.eibind.iss
autofs_provider = ldap
[autofs]
Здесь мы видим, что я использую ldap_schema = rfc2307bis
и ldap_group_member = uniqueMember
.
Я говорю это, потому что обнаружил в сети, что мне следует изменить ldap_schema = rfc2307bis
к ldap_schema = rfc2307
но все равно не работает.
Также есть некоторые закомментированные строки, которые я пробовал ранее, но безуспешно.
Чтобы закончить, я собираюсь вставить nslcd.conf. Здесь я просто следил за этим руководством: https://arthurdejong.org/nss-pam-ldapd/setup , поэтому мой файл конфигурации такой, как есть, плюс следующие строки:
# This comment prevents repeated auto-migration of settings.
uri ldap://ldap.eibind.iss/
base dc=eibind,dc=iss
uid nslcd
gid nslcd
Я должен что-то упустить, какую-то ценность, какую-то глупую конфигурацию. Наверное, я провожу около 3-4 дней, глядя на это, так что любая помощь будет очень благодарна.
Заранее спасибо.
Я сбит с толку, ваши группы используют memberuid: $ username, то есть RFC2307, так почему же в вашей конфигурации указываются rfc2307bis и uniqueMember?
Я бы предложил использовать rfc2307 (который используется по умолчанию), и если это не сработает, запустите отладку и посмотрите, какие запросы выполняются к серверу LDAP.
При замене значения по умолчанию:
ldap_schema = rfc2307
с участием
ldap_schema = rfc2307bis
в твоем sssd.conf
файла, вам необходимо следовать инструкциям из SSSD FAQ:
SSSD поддерживает три типа схем LDAP: RFC 2307, RFC 2307bis и IPA (последний является расширением RFC 2307bis, включая обратные ссылки memberOf).
По умолчанию SSSD будет использовать более распространенную схему RFC 2307. Разница между RFC 2307 и RFC 2307bis заключается в способе сохранения членства в группе на сервере LDAP. На сервере RFC 2307 члены группы хранятся как многозначный атрибут.
memberuid
который содержит имена пользователей, которые являются участниками. На сервере RFC2307bis члены группы хранятся как член многозначного атрибута (или иногдаuniqueMember
), который содержит DN пользователя или группы, которая является членом этой группы. RFC2307bis также позволяет поддерживать вложенные группы.Итак, первое, что нужно попробовать, когда вы попадаете в эту ситуацию, - это попробовать установить
ldap_schema = rfc2307bis
, удаление/var/lib/sss/db/cache_DOMAINNAME.ldb
и перезапуск SSSD. Если это все еще не работает, добавьтеldap_group_member = uniqueMember
, удалите кеш и перезапустите еще раз. Если это все еще не работает, пора сообщить об ошибке.