Автор Тема: [SOLVED] LDAP аутентификация сломалась после апгрейда до CentOS 6.4 (sssd)  (Прочитано 29123 раз)

wilful

  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Добрый день!
У меня есть сервер:
@(#) $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]
« Последнее редактирование: 04 Апрель 2013, 11:48:59 от wilful »

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 434
    • Просмотр профиля
Здравствуйте! Сразу скажу, что с новомодными теченями аутентификации в 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 и всё-таки поправить sssd.conf руками =) . Прежде всего, я бы вообще отказался от фильтра (директива ldap_access_filter), поскольку, как я понял, он нужен только для ограничений. Во-вторых, обратите внимание на директивы ldap_schema, ldap_group_member, ldap_user_name, в Вашем случае, вероятно, это будет:
ldap_schema = rfc2307bis
ldap_group_member = uniqueMember
ldap_user_name = uid      # или я не прав?

Поскольку проверить мне негде, поэкспериментируйте сами.

Егор

wilful

  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Егор, спасибо за ваш ответ и совет.

Без указанного фильтра клиентская машина правильно получает данные из 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 и группы работали как полагается.

Спасибо.

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 434
    • Просмотр профиля
Здравствуйте! Фильтр '(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, иначе поиск будет криво работать. Я уже говорил об этом здесь.

Егор

wilful

  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Да, теперь я понял свою ошибку в понимании процесса фильтрации. Спасибо.
Видимо родной механизм без использования SSSD был несколько хитрее, нежели с ним. Он мог сопоставлять DN найденный в группе с пользователем.

В текущей реализации моего дерева LDAP не хватает атрибута типа memberOf, который бы содержал группы членами которого является пользователь. Скажите, пожалуйста, нет ли возможности динамической связи созданных групп и такого атрибута?

Сейчас я не могу вообще найти такой атрибут в доступных на сервере.

Оказалось что атрибут виртуальный, я добавил в загрузку
moduleload memberof.la
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
Как тут и исходя из моей конфигурации выше.

После чего перезапустил сервер, но в атрибутах все равно не вижу этого поля:
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
---
« Последнее редактирование: 03 Апрель 2013, 12:43:06 от wilful »

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 434
    • Просмотр профиля
Здравствуйте!
Я попробовал у себя наложение 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 на конфигурацию не ругается?

Егор

wilful

  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Еще раз доброго дня!

Собрал базу в точности как в вашем примере и что вы думаете... не работает =(

Покажите пожалуйста свою конфигурацию этого:
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
« Последнее редактирование: 04 Апрель 2013, 08:26:34 от wilful »

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 434
    • Просмотр профиля
Здравствуйте! Моя последовательность действий попроще. В папке /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 -- как и у Вас. Должно работать.

Егор

wilful

  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Спасибо! Увидел ошибку, я загружал дамп с помощью 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
---

wilful

  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
жопиздан!

Спасибо! Разобрался, я делал не правильный дамп и он делал неправильный мёд. Сделал правильный, залил, получил memberOf, sssd+sshd полетел.
Осталось проверить как эти поля будут создаваться при репликации.

Спасибо!