Последние сообщения

Страницы: [1] 2 3 ... 10
1
Общий раздел / Re: И снова про memberOf
« Последний ответ от Игорь 11 Июнь 2019, 08:59:44 »
Спасибо, вроде помогло.
Отдал прикладникам на тестирование.
2
Общий раздел / Re: Обработка вложенных posixGroup
« Последний ответ от egor 11 Июнь 2019, 08:00:44 »
Может это как-то решается?
Думаю, что это баг, настройками вопрос не решить. Можете попытаться подать New Issue Report в ITS OpenLDAP и ждать выхода исправленной версии.

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

Егор
3
Общий раздел / Re: И снова про memberOf
« Последний ответ от egor 11 Июнь 2019, 07:50:09 »
Здравствуйте!

Подозреваю, что это из-за разных определений типа атрибута memberOf в AD и OpenLDAP (в частности, у них разные OID синтаксисов). Если вы не настраиваете наложение memberof, то не загружайте его модуль, тогда путаницы не будет.

Егор
4
Общий раздел / И снова про memberOf
« Последний ответ от Игорь 10 Июнь 2019, 14:46:48 »
Добрый день, Егор.
Недавно прикладники заметили такую штуку:
ldapsearch ... "(filter)" memberof | grep -i memberof
выводит нормальные значения memberOf

ldapsearch ... "(filter)" | grep -i memberof
Ничего не находит.

Причём:
[root@srv-ldap-tst01 ~]# slapcat -n0 -a "cn=module*"
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}back_ldap.la
olcModuleLoad: {2}rwm.la
olcModuleLoad: {3}dynlist.la
olcModuleLoad: {4}memberof

Такое происходит и при meta и при ldap backen-ах.
Да- backend-ы указывают на AD домены.
5
Общий раздел / Re: Обработка вложенных posixGroup
« Последний ответ от Игорь 10 Июнь 2019, 12:23:59 »
Добрый день, Егор.
Попробовал.
Оно действительно сваливается постоянно.
Причём после перезапуска один запрос выполняет нормально пока его не изменишь. На пример, при добавлении атрибута или смене фильтра в запросе.

Т.е. к работе совершенно не годен.
Может это как-то решается?
6
Общий раздел / Re: Обработка вложенных posixGroup
« Последний ответ от egor 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) и в новых эта ошибка уже исправлена. Проверяйте.

Егор
7
Общий раздел / Re: Обработка вложенных posixGroup
« Последний ответ от Игорь 31 Май 2019, 15:17:44 »
Добрый день, Егор.
Спасибо.
Надо обдумать Ваше решение.
Может есть возможность добавить атрибуты в запрос, или убрать оттуда?
8
Общий раздел / Re: Обработка вложенных posixGroup
« Последний ответ от egor 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

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

Егор
9
Общий раздел / Обработка вложенных 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 не возвращает ничего.

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

С уважением, Игорь
10
Нет, просто имена совпали.

Егор
Страницы: [1] 2 3 ... 10