Автор Тема: Обработка вложенных posixGroup  (Прочитано 307 раз)

Игорь

  • Новичок
  • *
  • Сообщений: 15
    • Просмотр профиля
Обработка вложенных posixGroup
« : 29 Май 2019, 08:03:52 »
Добрый день, дорогие друзья.
Нужна идеологическая помощь. (Идея нужна).
Наверняка кто-то такое уже делал.
Я ввёл solaris10 в два AD домена- для этого развернул прокси openLdap с ldap бэкендами.
Всё хорошо, и даже просто отлично работает. Solaris 11 даже отлично обрабатывает вложенные группы.
Но вот Solaris 10 отказывается это делать- он читает MemberUid атрибуты группы, и на основании их определяет членов групп.
Я пробовал настроить dynlist с запросом к AD memberOf:1.2.840.113556.1.4.1941: - это поиск по всей цепочке групп. простой ldapsearch ,без указания уточнения атрибутов работает на ура, но solaris 10 в запросе указывает атрибуты, что по описанию самого dynlist не возвращает ничего.

Как кто боролся с подобной проблемой?

С уважением, Игорь

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 433
    • Просмотр профиля
Re: Обработка вложенных posixGroup
« Ответ #1 : 31 Май 2019, 08:40:41 »
Здравствуйте, Игорь!

С Solaris не сталкивался, поэтому ориентированное под эту систему решение предложить не могу. С другой стороны, в процессе размышления над Вашей проблемой, пришло понимание того, почему предложенная мною ранее конфигурация не возвращает атрибуты членства в группе, если они запрашиваются явно. Дело в том, что наложение dynlist, прежде чем строить список динамических атрибутов, проверяет наличие в записи объектного класса и атрибута с LDAP-URL, которые указаны в настройке этого наложения.

Так вот, когда мы делаем запрос к LDAP-прокси без указания конкретных атрибутов, то механизм back_ldap возвращает из исходного каталога записи со ВСЕМИ пользовательскими атрибутами, в том числе с атрибутами objectClass и labeledURI, и наложение dynlist видит нужные данные и срабатывает на них. Если же при запросе к LDAP-прокси мы указываем конкретные атрибуты, то механизм back_ldap делает запрос к исходному каталогу с указанием этих же атрибутов и исходный каталог возвращает содержимое этих конкретных атрибутов. То есть, если при запросе к LDAP-прокси мы указываем получение только атрибута memberUid, то для отобранных записей исходный каталог вернёт только dn записи и содержимое этих атрибутов; dynlist не увидит в ответе исходного сервера нужных ему данных и не построит динамическое содержимое. Надеюсь, более-менее понятно.

Вывод: чтобы dynlist отработал, при запросе, кроме атрибута memberUid, нужно указать еще атрибуты objectClass и labeledURI:

$ ldapsearch -xLLL -o ldif-wrap=no -H ldap://127.1:9000 -b cn=users,dc=SomeDomain,dc=lan '(cn=TestGroup*)' memberUid objectClass labeledURI
Но это из командной строки. А как заставить системную библиотеку делать запрос с указанием нужных нам атрибутов? Честно говоря, красивого решения я не вижу, но придумал "костыль": запустить 2 процесса slapd. Первый будет висеть на каком-нибудь порту 9000 и представлять собой рабочий вариант LDAP-прокси к AD, который Вы уже настроили. Второй будет "обёрткой" для первого, висеть на системном порту 389 и передавать на LDAP-прокси (на порту 9000) запросы без указания атрибутов, а конечный отбор атрибутов выполнять сам.

Я придумал такую конфигурацию для второго сервера. slapd.conf:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

moduleload back_shell.la

database shell
suffix      "dc=SomeDomain,dc=lan"
search     /path/to/test.sh

Скрипт test.sh:
#!/bin/bash

while [ 1 ]; do
    read TAG VALUE
    if [ $? -ne 0 ]; then
        break
    fi
    case "$TAG" in
        base:)
        BASE=$VALUE
        ;;
        filter:)
        FILTER=$VALUE
        ;;
        # include other parameters here
    esac
done

# Search
ldapsearch -x -LLL -H ldap://127.0.0.1:9000 -b $BASE $FILTER '*'

# result
echo "RESULT"
echo "code: 0"

exit 0

Простой скрипт берёт из параметров, которые ему передаст slapd, базу поиска и фильтр, делает ldapsearch к серверу на порту 9000, запрашивая у того все атрибуты. Результат (с уже сформированным динамическим содержимым) возвращается обратно slapd и он уже может отобрать из полученных данных только нужные ему атрибуты.

Запрос ко второму серверу (на 389 порту):

$ ldapsearch -xLLL -b cn=users,dc=SomeDomain,dc=lan '(cn=TestGroup*)' memberUid
dn: cn=TestGroup1,cn=Users,dc=SomeDomain,dc=lan
memberUid: egor
memberUid: kostya

dn: cn=TestGroup2,cn=Users,dc=SomeDomain,dc=lan
memberUid: egor

Несколько притянутое за уши, но работоспособное решение, универсальное для всех системных библиотек.

Егор

Игорь

  • Новичок
  • *
  • Сообщений: 15
    • Просмотр профиля
Re: Обработка вложенных posixGroup
« Ответ #2 : 31 Май 2019, 15:17:44 »
Добрый день, Егор.
Спасибо.
Надо обдумать Ваше решение.
Может есть возможность добавить атрибуты в запрос, или убрать оттуда?

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 433
    • Просмотр профиля
Re: Обработка вложенных posixGroup
« Ответ #3 : 01 Июнь 2019, 02:04:48 »
Здравствуйте, Игорь! А ведь действительно, есть такая возможность. Просто я перечитывал man-страницу slapd-ldap и не нашёл там ничего похожего. А нужно было заглянуть в man-страницу slapd.conf, там есть описание атрибута extra_attrs (в cn=config olcExtraAttrs), который как раз реализует функционал добавления дополнительных атрибутов к запросу. Вот что получилось:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/dyngroup.schema

moduleload back_mdb.la
moduleload back_ldap.la
moduleload rwm.la
moduleload dynlist.la

attributetype ( 1.2.840.113556.1.4.656 NAME 'userPrincipalName' SUP name )
attributetype ( 1.2.840.113556.1.4.221 NAME 'samAccountName' SUP name )
objectClass ( 1.2.840.113556.1.5.8 NAME 'Group' SUP top STRUCTURAL MUST cn )

database ldap
suffix "cn=Users,dc=SomeDomain,dc=lan"
extra_attrs objectClass,labeledURI
readonly yes
rebind-as-user yes
uri ldap://192.168.x.x
idassert-bind xxxxxxxxxxxxxxxxxx
idassert-authzFrom "dn:"*

subordinate TRUE

overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext searchFilter
rwm-rewriteRule "RecursiveMemberOf=(.*),dc=lan" "memberof:1.2.840.113556.1.4.1941:=%1,dc=lan" ":"

overlay dynlist
dynlist-attrset Group labeledURI memberUid:samAccountName

database mdb
suffix "dc=SomeDomain,dc=lan"
directory /path/to/db/
rootdn cn=root,dc=SomeDomain,dc=lan
rootpw xxxxxxxxxxxxxxxxxxxxxx


Запрос с указанием атрибута:
$ ldapsearch -xLLL -H ldap://127.1:9000 -b cn=Users,dc=SomeDomain,dc=lan '(cn=TestGroup*)' memberUid
dn: cn=TestGroup1,cn=Users,dc=SomeDomain,dc=lan
memberUid: egor
memberUid: kostya
memberUid: TestGroup2

dn: cn=TestGroup2,cn=Users,dc=SomeDomain,dc=lan
memberUid: egor


Чтобы получить все атрибуты, теперь нужно явно указывать '*':
$ ldapsearch -xLLL -H ldap://127.1:9000 -b cn=Users,dc=SomeDomain,dc=lan '(cn=TestGroup*)' '*'
Всё, вроде, работает, но есть нюанс: периодически slapd аварийно завершается. Возможно, у меня просто старая версия (2.4.31) и в новых эта ошибка уже исправлена. Проверяйте.

Егор

Игорь

  • Новичок
  • *
  • Сообщений: 15
    • Просмотр профиля
Re: Обработка вложенных posixGroup
« Ответ #4 : 10 Июнь 2019, 12:23:59 »
Добрый день, Егор.
Попробовал.
Оно действительно сваливается постоянно.
Причём после перезапуска один запрос выполняет нормально пока его не изменишь. На пример, при добавлении атрибута или смене фильтра в запросе.

Т.е. к работе совершенно не годен.
Может это как-то решается?

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 433
    • Просмотр профиля
Re: Обработка вложенных posixGroup
« Ответ #5 : 11 Июнь 2019, 08:00:44 »
Может это как-то решается?
Думаю, что это баг, настройками вопрос не решить. Можете попытаться подать New Issue Report в ITS OpenLDAP и ждать выхода исправленной версии.

А пока использовать заглушку с back_shell.

Егор