Форум проекта Pro-LDAP.ru
Общие вопросы по LDAP => Общий раздел => Тема начата: Игорь от 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 не возвращает ничего.
Как кто боролся с подобной проблемой?
С уважением, Игорь
-
Здравствуйте, Игорь!
С Solaris не сталкивался, поэтому ориентированное под эту систему решение предложить не могу. С другой стороны, в процессе размышления над Вашей проблемой, пришло понимание того, почему предложенная мною ранее конфигурация (https://pro-ldap.ru/forum/index.php?topic=994.msg2078#msg2078) не возвращает атрибуты членства в группе, если они запрашиваются явно. Дело в том, что наложение 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
Несколько притянутое за уши, но работоспособное решение, универсальное для всех системных библиотек.
Егор
-
Добрый день, Егор.
Спасибо.
Надо обдумать Ваше решение.
Может есть возможность добавить атрибуты в запрос, или убрать оттуда?
-
Здравствуйте, Игорь! А ведь действительно, есть такая возможность. Просто я перечитывал man-страницу slapd-ldap (https://pro-ldap.ru/tr/man/slapd-ldap.5.html) и не нашёл там ничего похожего. А нужно было заглянуть в man-страницу slapd.conf (https://pro-ldap.ru/tr/man/slapd.conf.5.html), там есть описание атрибута 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) и в новых эта ошибка уже исправлена. Проверяйте.
Егор
-
Добрый день, Егор.
Попробовал.
Оно действительно сваливается постоянно.
Причём после перезапуска один запрос выполняет нормально пока его не изменишь. На пример, при добавлении атрибута или смене фильтра в запросе.
Т.е. к работе совершенно не годен.
Может это как-то решается?
-
Может это как-то решается?
Думаю, что это баг, настройками вопрос не решить. Можете попытаться подать New Issue Report в ITS OpenLDAP (https://www.openldap.org/its/) и ждать выхода исправленной версии.
А пока использовать заглушку с back_shell.
Егор