Здравствуйте, Игорь!
С 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
Несколько притянутое за уши, но работоспособное решение, универсальное для всех системных библиотек.
Егор
