Форум проекта Pro-LDAP.ru
Интеграция => Учётные записи в *nix системах => Тема начата: wilful от 02 Апрель 2013, 09:15:33
-
Добрый день!
У меня есть сервер:
@(#) $OpenLDAP: slapd 2.4.23 (Aug 8 2012 16:29:21)
В конфигурации ЛДАП есть такая группа:
ldapsearch -x -b 'cn=groupname,ou=UnixShell,ou=Services,o=example,c=ru'
# extended LDIF
#
# LDAPv3
# base <cn=groupname,ou=UnixShell,ou=Services,o=example,c=ru> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# groupname, UnixShell, Services, example, ru
dn: cn=groupname,ou=UnixShell,ou=Services,o=example,c=ru
cn: groupname
objectClass: groupOfUniqueNames
objectClass: top
uniqueMember: cn=Name Second,ou=Sysadmins,ou=SoftwareDevelopment,ou=IT,ou=Accounts,o=example,c=ru
# search result
search: 2
result: 0 Success
И пользователь
# ldapsearch -x -b 'cn=Name Second,ou=Sysadmins,ou=SoftwareDevelopment,ou=IT,ou=Accounts,o=example,c=ru'
# extended LDIF
#
# LDAPv3
# base <cn=Name Second,ou=Sysadmins,ou=SoftwareDevelopment,ou=IT,ou=Accounts,o=example,c=ru> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# Name Second, Sysadmins, SoftwareDevelopment, IT, Accounts, example, ru
dn: cn=Name Second,ou=Sysadmins,ou=SoftwareDevelopment,ou=IT,ou=Accounts,o=
example,c=ru
homeDirectory: /home/user
loginShell: /bin/bash
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 15361
shadowMax: 99999
shadowMin: 0
shadowWarning: 7
uid: user
uidNumber: 7000
cn: Name Second
gidNumber: 702
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Долгое время я использовал простую аутентификацию через pam_ldap, с апгрейдом по умолчанию стал использоваться sssd.
В pam_ldap было следующее:
pam_groupdn cn=groupname,ou=UnixShell,ou=Services,o=example,c=ru
pam_member_attribute uniquemember
Теперь в sssd.conf этот фильтр не работает
access_provider = ldap
ldap_access_filter = memberOf=cn=groupname,ou=UnixShell,ou=Services,o=example,c=ru
Что я делаю не так? Клиентские машины подключаются к серверу, но не находит пользователя при подключении через sshd. "su - user" работает
Ошибка в sssd логе такая
(Thu Mar 28 12:44:43 2013) [sssd[be[default]]] [sdap_access_filter_get_access_done] (0x0100): User [user] was not found with the specified filter. Denying access.
Настраивал следующим образом:
authconfig --enablemkhomedir --updateall --enablesssd --enablesssdauth --enableldap --enableldapauth --disablenis --disablekrb5 --disablecachecreds --disablecache --ldaploadcacert=$certurl"
CentOS release 6.4 (Final)
Все настройки делал через утилиты дистрибутива, руками ничего сломать не мог =)
Просто не ищет по групповому фильтру, думаю может в ЛДАП сервере теперь неверно сформирована группа? Подскажите пожалуйста в чем может быть загвоздка или покажите пример своей конфигурации.
# cat /etc/sssd/sssd.conf
[domain/default]
ldap_uri = ldaps://ldap02.example.ru
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_id_use_start_tls = True
cache_credentials = False
ldap_search_base = o=example,c=ru
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = ldap
ldap_access_filter = uniqueMember=cn=grouname,ou=UnixShell,ou=Services,o=example,c=ru
debug_level = 255
auth_provider = ldap
chpass_provider = ldap
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
-
Здравствуйте! Сразу скажу, что с новомодными теченями аутентификации в RedHat я не знаком, поэтому могу дать лишь общие рекомендации. Во первых, сразу обращает на себя внимание, что оба приведённых Вами фильтра не вернут никаких результатов -- они просто неверные, поэтому в логе всё справедливо. Попробуйте сами и убедитесь:
# ldapsearch -x -LLL -b 'o=example,c=ru' '(memberOf=cn=groupname,ou=UnixShell,ou=Services,o=example,c=ru)'
или
# ldapsearch -x -LLL -b 'o=example,c=ru' '(uniqueMember=cn=grouname,ou=UnixShell,ou=Services,o=example,c=ru)'
Для начала я бы посоветовал внимательно почитать man sssd-ldap (http://linux.die.net/man/5/sssd-ldap) и всё-таки поправить sssd.conf руками =) . Прежде всего, я бы вообще отказался от фильтра (директива ldap_access_filter), поскольку, как я понял, он нужен только для ограничений. Во-вторых, обратите внимание на директивы ldap_schema, ldap_group_member, ldap_user_name, в Вашем случае, вероятно, это будет:
ldap_schema = rfc2307bis
ldap_group_member = uniqueMember
ldap_user_name = uid # или я не прав?
Поскольку проверить мне негде, поэкспериментируйте сами.
Егор
-
Егор, спасибо за ваш ответ и совет.
Без указанного фильтра клиентская машина правильно получает данные из DIT и работает аутентификация через sshd. В моём случае мне как раз необходимы ограничения по группам для доступа к серверу или сервисам.
Оба примера, приведенные вами, отдают пустой результат. Я думаю что мне как раз не хватает квалифицированной помощи именно в построении фильтра поиска записей для моей группы.
Вот что мне сообщил сам сервер:
Apr 3 08:59:36 ldap02 slapd[18099]: <= bdb_equality_candidates: (uniqueMember) not indexed
После добавления индекса:
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 fd=14 ACCEPT from IP=xxx.xxx.xxx.xxx:33400 (IP=0.0.0.0:636)
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 fd=14 TLS established tls_ssf=256 ssf=256
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 op=0 BIND dn="" method=128
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 op=0 RESULT tag=97 err=0 text=
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 op=1 SRCH base="o=example,c=ru" scope=2 deref=0 filter="(uniqueMember=cn=groupname.ru,ou=unixshell,ou=services,o=example,c=ru)"
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 op=2 UNBIND
Apr 3 09:02:36 ldap02 slapd[25460]: conn=1004 fd=14 closed
И соответственно нулевой результат поиска. На что еще можно обратить внимание в конфигурации сервера или клиента? Ведь такой фильтр работал в конфигурации без sssd и группы работали как полагается.
Спасибо.
-
Здравствуйте! Фильтр '(uniqueMember=cn=groupname.ru,ou=unixshell,ou=services,o=example,c=ru)' плох не потому, что атрибут uniqueMember не проиндексирован, а потому, что ему не соответствует ни одна запись. Фактически, в этом фильтре Вы говорите: найди мне те записи, в которых есть атрибут uniqueMember и его значение равно cn=groupname.ru,ou=unixshell,ou=services,o=example,c=ru. В приведённой Вами записи пользователя нет атрибута uniqueMember, а в записи группы он есть, но у него нет такого значения. Именно поэтому ничего и не находится. Концепция фильтров соответствия (equality) очень проста, попробуйте:
# ldapsearch -x -LLL -b 'o=example,c=ru' '(gidNumber=702)'
# ldapsearch -x -LLL -b 'o=example,c=ru' '(loginShell=/bin/bash)'
# ldapsearch -x -LLL -b 'o=example,c=ru' '(cn=groupname)'
Надеюсь, эти примеры говорят сами за себя. Выберите тот фильтр, по которому возвращаются только необходимые Вам пользователи, и используйте его в sssd.conf.
Насчёт индексации. Если OpenLDAP настраивается через файл slapd.conf, по после изменения настроек индексов необходимо перед запуском slapd выполнить slapindex, иначе поиск будет криво работать. Я уже говорил об этом здесь (http://pro-ldap.ru/forum/index.php?topic=49).
Егор
-
Да, теперь я понял свою ошибку в понимании процесса фильтрации. Спасибо.
Видимо родной механизм без использования SSSD был несколько хитрее, нежели с ним. Он мог сопоставлять DN найденный в группе с пользователем.
В текущей реализации моего дерева LDAP не хватает атрибута типа memberOf, который бы содержал группы членами которого является пользователь. Скажите, пожалуйста, нет ли возможности динамической связи созданных групп и такого атрибута?
Сейчас я не могу вообще найти такой атрибут в доступных на сервере.
Оказалось что атрибут виртуальный, я добавил в загрузку
moduleload memberof.la
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
Как тут (http://www.openldap.org/doc/admin24/overlays.html#Reverse Group Membership Maintenance) и исходя из моей конфигурации выше.
После чего перезапустил сервер, но в атрибутах все равно не вижу этого поля:
ldapsearch -x -LLL -b 'o=example,c=ru' '(uid=user)' memberOf
dn: cn=Name Second,ou=Sysadmins,ou=SoftwareDevelopment,ou=IT,ou=Accounts,o=
example,c=ru
P.S.: индексацию я производил по официальной документации и выполнял slapindex для демона, а так же синхронизировал в динамическую конфигурацию с помощью slaptest (вдруг когда-то дорасту и до нее :) )
Конфигурация:
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/openssh-lpk_openldap.schema
include /etc/openldap/schema/sudo.schema
---
allow bind_v2
---
moduleload accesslog.la
moduleload memberof.la
moduleload syncprov.la
---
database bdb
suffix "o=example,c=ru"
---
directory /var/lib/ldap
index uniqueMember eq
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryCSN,entryUUID eq
---
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
---
-
Здравствуйте!
Я попробовал у себя наложение memberof -- работает (правда, пришлось собирать openldap руками, поскольку этого наложения в стандартной сборке на gentoo не оказалось).
Мой slapd.conf:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
moduleload back_bdb.la
moduleload memberof.la
database bdb
suffix "dc=mycompany,dc=ru"
directory /tmp/test
rootdn "cn=root,dc=mycompany,dc=ru"
rootpw secret
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
LDIF, с которого я инициализировал БД:
dn: dc=mycompany,dc=ru
objectClass: organization
objectClass: dcObject
dc: mycompany
o: mycompany
dn: cn=user,dc=mycompany,dc=ru
objectClass: person
cn: user
sn: user
dn: cn=group,dc=mycompany,dc=ru
objectClass: groupOfUniqueNames
cn: group
uniqueMember: cn=user,dc=mycompany,dc=ru
Поиск:
# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(cn=user)' memberOf
dn: cn=user,dc=mycompany,dc=ru
memberOf: cn=group,dc=mycompany,dc=ru
Работает =) . Правда, я собирал последнюю версию OpenLDAP -- 2.4.35, но не думаю, что есть существенная разница. Так что даже не знаю. slaptest на конфигурацию не ругается?
Егор
-
Еще раз доброго дня!
Собрал базу в точности как в вашем примере и что вы думаете... не работает =(
Покажите пожалуйста свою конфигурацию этого:
dn: olcOverlay={0}memberof
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: FALSE
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: uniqueMember
structuralObjectClass: olcMemberOf
entryUUID: 056d54be-3121-1032-80e5-5594f033b123
creatorsName: cn=config
createTimestamp: 20130404031100Z
entryCSN: 20130404031100.523605Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130404031100Z
Меня смущает olcMemberOfRefInt: FALSE, хотя я не совсем понимаю что это, но в примерах у "белых" людей в этом атрибуте TRUE и как задать я не понимаю. Делали вы что-то после добавления групп, как пишет вот этот человек со стека:
It does not automatically update the existing data in the database, so I needed to use slapcat to copy everything out into a temporary file, and visit each group, delete the group and add the same group back in again (forces the memberOf attributes to update correctly). If you are starting with an empty database, then it will correctly update the attributes as objects are added.
# slapd -V
@(#) $OpenLDAP: slapd 2.4.23 (Aug 8 2012 16:29:21) $
mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
Судя по ченжлогу модуль вкомпилен в сборку под Цент, да и ругался бы на этапе подгрузки, но сейчас никаких ошибок при рестарте нет и при заливке LDIFF тоже. Вот так я перезапускаю:
#!/bin/bash
/etc/init.d/slapd stop
rm -rf slapd.d/*
sudo -u ldap slapindex
sudo -u ldap slaptest -f slapd.conf -F slapd.d/
/etc/init.d/slapd restart
Я в замешательстве.
Грустная история в картинках:
[root@ldap02 openldap]# rm -rf /var/lib/ldap/*
-------------------------------
[root@ldap02 openldap]# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
-------------------------------
[root@ldap02 openldap]# cat slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
TLSCertificateFile /etc/openldap/cacerts/ldapscert.pem
TLSCertificateKeyFile /etc/openldap/cacerts/keys/ldapskey.pem
TLSCipherSuite TLSv1+RSA:!NULL
moduleload back_bdb.la
moduleload memberof.la
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
database bdb
suffix "dc=mycompany,dc=ru"
rootdn "cn=root,dc=mycompany,dc=ru"
rootpw secret
directory /var/lib/ldap
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
-------------------------------
[root@ldap02 openldap]# cat /root/test.ldiff
dn: dc=mycompany,dc=ru
objectClass: organization
objectClass: dcObject
dc: mycompany
o: mycompany
dn: cn=user,dc=mycompany,dc=ru
objectClass: person
cn: user
sn: user
dn: cn=group,dc=mycompany,dc=ru
objectClass: groupOfUniqueNames
cn: group
uniqueMember: cn=user,dc=mycompany,dc=ru
-------------------------------
[root@ldap02 openldap]# slapadd -l /root/test.ldiff
bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
_#################### 100.00% eta none elapsed none fast!
Closing DB...
-------------------------------
[root@ldap02 openldap]# chown ldap. -R /var/lib/ldap/
-------------------------------
[root@ldap02 openldap]# ./reload.sh
Stopping slapd: [FAILED]
bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
config file testing succeeded
Stopping slapd: [FAILED]
Starting slapd: [ OK ]
-------------------------------
[root@ldap02 openldap]# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(cn=user)'
dn: cn=user,dc=mycompany,dc=ru
objectClass: person
cn: user
sn: user
-------------------------------
[root@ldap02 openldap]# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(cn=user)' memberOf
dn: cn=user,dc=mycompany,dc=ru
У меня нет сервера на Gentoo. Собрал сервер на FreeBSD с включенным memberOf и тот же результат, видимо дело не в бабине всё таки, пожалуйста просмотрите лог действий, я где-то допускаю ошибку на этапе конфигурирования и не могу увидеть.
# pkg_info | grep openldap
openldap-client-2.4.34_1 Open source LDAP client implementation
openldap-server-2.4.34_1 Open source LDAP server implementation
-
Здравствуйте! Моя последовательность действий попроще. В папке /tmp/test 3 файла:
# ls /tmp/test
DB_CONFIG init.ldif slapd.conf
Первый -- стандартный, содержимое двух других я приводил в прошлом посте.
Запускаю slapd на нестандартном порту, чтобы не конфликтовал с основным демоном:
# /usr/libexec/slapd -f /tmp/test/slapd.conf -h 'ldap://127.0.0.1:9001'
Добавляю записи с помощью ldapadd:
# ldapadd -x -D 'cn=root,dc=mycompany,dc=ru' -w secret -H 'ldap://127.0.0.1:9001' -f /tmp/test/init.ldif
adding new entry "dc=mycompany,dc=ru"
adding new entry "cn=user,dc=mycompany,dc=ru"
adding new entry "cn=group,dc=mycompany,dc=ru"
Делаю поиск:
# ldapsearch -x -LLL -H 'ldap://127.0.0.1:9001' -b 'dc=mycompany,dc=ru' '(cn=user)' memberOf
dn: cn=user,dc=mycompany,dc=ru
memberOf: cn=group,dc=mycompany,dc=ru
Потом убиваю мой slapd kill-ом.
Если перегнать slapd.conf slaptest-ом, то olcMemberOfRefInt: FALSE -- как и у Вас. Должно работать.
Егор
-
Спасибо! Увидел ошибку, я загружал дамп с помощью slapadd, и по этому динамические атрибуты не создавались.
К сожалению для моего боевого сервера есть дампы только в формате slapcat в котором содержатся и скрытые не изменяемые атрибуты. При заливке я получаю следующую понятную ошибку:
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification allowed
Наверное последний вопрос и я больше не буду вас беспокоить. Сделал дамп рабочей базы с помощью ldapsearch и пытаюсь влить, получаю:
ldap_initialize( <DEFAULT> )
add objectClass:
dcObject
organization
add o:
example
add dc:
example
adding new entry "o=example,c=ru"
modify complete
add objectClass:
organizationalUnit
top
add ou:
UnixShell
adding new entry "ou=UnixShell,ou=Services,o=example,c=ru"
ldap_add: No such object (32)
matched DN: o=example,c=ru
Почему он не находит корневой DN, хотя только что его же и создал %)
Начало ldif:
version: 1
dn: o=example,c=ru
objectClass: dcObject
objectClass: organization
o: example
dc: example
dn: ou=UnixShell,ou=Services,o=example,c=ru
objectClass: organizationalUnit
objectClass: top
ou: UnixShell
---
-
жопиздан!
Спасибо! Разобрался, я делал не правильный дамп и он делал неправильный мёд. Сделал правильный, залил, получил memberOf, sssd+sshd полетел.
Осталось проверить как эти поля будут создаваться при репликации.
Спасибо!