Форум проекта Pro-LDAP.ru
Администрирование OpenLDAP => Конфигурация через cn=config => Тема начата: Игорь от 10 Май 2019, 16:22:32
-
Добрый день.
Имею конфигурацию proxy openLdap на AD:
(slapcat -n0 выдержки в приложении)
Всё работает нормально, пока запрос не попадает на dynlist.
Как только он туда попадает, отвечает нормально, и зависает.
Дальнейший поиск останавливается и висит пока не отработает таймаут.
-
Здравствуйте, Игорь!
Интересная конфигурация. Даже не знаю, сможет ли она вообще в принципе заработать =) . Какой вид записей Вы хотите наполнять динамическим содержимым с помощью наложения dynlist? Если можно, приведите пример записи из Вашего каталога с классом posixGroup и LDAP-URL в атрибуте labeledURI.
Если убрать наложение dynlist из БД frontend всё работает так, как Вам нужно?
Егор
-
Добрый день, Егор.
Всё работает нормально, в том числе и dynlist возвращает правильную информацию, но после этого всё зависает, пока на клиенте не дашь ^C
Группа:
dn: cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by
ufn: ext_bscs, Groups, external.company.by
objectClass: top
objectClass: posixGroup
objectClass: GROUP
cn: ext_bscs
member: cn=Sytoss,ou=Groups,dc=external,dc=company,dc=by
distinguishedName: cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by
labeledURI: ldap:///dc=company,dc=by?userPrincipalName?sub?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by)
Мне нужно обработать вложенные группы и получить для группы значения userPrincipalName всех её членов.
На мой взгляд, данный подход даст возможность иметь вложенность любого уровня. (Если заработает)
-
Здравствуйте! Тут сразу столько тонких мест, что затык может случиться в любой момент.
Во-первых, я бы не стал применять наложение dynlist к БД frontend -- теоретически настройки из frontend должны применяться ещё до того, как идёт обращение к какой-то конкретной БД. IMHO, наложение dynlist нужно применить к БД hdb.
Во-вторых, нужно убедиться, что перезапись для механизма meta отрабатывает нормально, то есть в Вашем случае запрос
ldapsearch -xLLL -b dc=company,dc=by '(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by)' userPrincipalNameвозвращает все нужные записи.
В-третьих, не совсем понятно, как работает майкрософтовское правило 1.2.840.113556.1.4.1941, не возникает ли при выполнении этого правила какого-нибудь зацикливания (я имею ввиду, что сама записи cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by и cn=Sytoss,ou=Groups,dc=external,dc=company,dc=by попадают в диапазон dc=company,dc=by , и где-то здесь может образоваться "бесконечный цикл"). Можно сначала отработать запрос напрямую в AD, а потом, если что, подправить LDAP-URL в записи динамической группы.
Пока такие мысли. Егор
-
ДОбрый день, Егор.
ldapsearch '(RecursiveMemberOf...)" отрабатывает без проблем. Проверял не один раз.
К hdb, на мой взгляд, dynlist применять нет смысла- так как при таких запросах туда никто не обращается.
Я применял dynlist к обоим meta- без изменений.
Сейчас ещё раз попробую.
1.2.840.113556.1.4.1941 без rewrite работать не хочет, а при обращении непосредственно к AD работаем без проблем.
Да и как указано выше: ldapsearch "(RecursiveMemberOf...)" отрабатывает нормально- всё возвращает и не виснет.
Перепривязал dynlist к hdb- результат тот же.
Перепривязал dynlist к обоим meta- без изменений.
С уважением, Игорь.
PS. RHEL 7.6 OpenLDAP 2.4.44-21.el7_6
-
slapd -d -1
показывет следующее:
ldap_write: want=1441, written=1441
0000: 30 82 05 9d 02 01 02 64 82 05 96 04 4c 63 6e 3d 0......d....Lcn=
0010: 53 47 5f 4f 53 5f 53 4f 4c 41 52 49 53 2c 6f 75 SG_OS_SOLARIS,ou
0020: 3d 53 65 63 75 72 69 74 79 20 47 72 6f 75 70 73 =Security Groups
.....
0590: 5f 48 40 4d 41 49 4e 2e 56 45 4c 43 4f 4d 2e 42 _H@MAIN.company.B
05a0: 59 Y
5cd8ff56 <= send_search_entry: conn 1000 exit.
ldap_msgfree
И ждёт. После того как я на клиенте ^C
5cd8ff5f daemon: activity on 1 descriptor
5cd8ff5f daemon: activity on: 15r
5cd8ff5f daemon: read active on 15
5cd8ff5f daemon: epoll: listen=7 active_threads=0 tvp=NULL
5cd8ff5f daemon: epoll: listen=8 active_threads=0 tvp=NULL
5cd8ff5f connection_get(15)
5cd8ff5f connection_get(15): got connid=1000
5cd8ff5f connection_read(15): checking for input on id=1000
ber_get_next
ldap_read: want=8, got=0
5cd8ff5f ber_get_next on fd 15 failed errno=0 (Success)
5cd8ff5f connection_read(15): input error=-2 id=1000, closing.
5cd8ff5f connection_closing: readying conn=1000 sd=15 for close
5cd8ff5f connection_close: deferring conn=1000 sd=15
5cd8ff5f daemon: activity on 1 descriptor
5cd8ff5f daemon: activity on:
5cd8ff5f daemon: epoll: listen=7 active_threads=0 tvp=NULL
5cd8ff5f daemon: epoll: listen=8 active_threads=0 tvp=NULL
5cd8ff5f connection_resched: attempting closing conn=1000 sd=15
5cd8ff5f connection_close: conn=1000 sd=15
5cd8ff5f =>meta_back_conn_destroy: fetching conn=1000 DN="cn=solaris,dc=company,dc=by"
5cd8ff5f =>meta_back_conn_destroy: destroying conn 1000 refcnt=0 flags=0x00000100
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 17
0000: 30 05 02 01 04 42 00 0....B.
ldap_write: want=7, written=7
0000: 30 05 02 01 04 42 00 0....B.
ldap_free_connection: actually freed
ldap_msgfree
5cd8ff5f =>meta_back_conn_destroy: fetching conn=1000 DN="cn=solaris,dc=company,dc=by"
5cd8ff5f daemon: removing 15
5cd8ff5f conn=1000 fd=15 closed (connection lost)
-
Есть предположение, что осуществляется попытка обратиться туда, куда у пользователя, от которого подключается механизм meta, нет доступа (ou=Security Groups).
Что если в labeledURI записи динамической группы всё-таки ограничить область поиска, например:
labeledURI: ldap:///ou=Users,dc=external,dc=company,dc=by?userPrincipalName?sub?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by)
Егор
-
labeledURI: ldap:///ou=Users,ou=Sytoss,ou=Organization,dc=external,dc=company,d
c=by?userPrincipalName?sub?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=extern
al,dc=company,dc=by)
не помогло- всё так и осталось.
-
Пришлось делать стенд =) . AD на Win2003R2, OpenLDAP 2.4.31 на Ubuntu 16.04
Конфигурация такая:
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 )
objectClass ( 1.2.840.113556.1.5.8 NAME 'Group' SUP top STRUCTURAL MUST cn )
database ldap
suffix "dc=SomeDomain,dc=lan"
readonly yes
rebind-as-user yes
uri ldap://192.168.x.x
idassert-bind xxxxxxxxxxxxxxxxxx
idassert-authzFrom "dn:"*
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
Добавил фиктивные определения класса Group (так и не разобрался, как в AD сделать запись с posixGroup, поэтому для dynlist использовал Group) и атрибута userPrincipalName (без этого данный атрибут не выводился в итоговом наполнении динамической группы). В остальном всё практически как у Вас.
В AD добавил две группы TestGroup2 с членом egor (пользователь) и TestGroup1 с членами kostya (пользователь) и TestGroup2 (группа), добавил в эти группы labeledURI для составления динамического содержимого:
$ ldapsearch -xLLL -o ldif-wrap=no -H ldap://127.1:9000 -b cn=users,dc=SomeDomain,dc=lan '(cn=TestGroup*)' member labeledURI
dn: cn=TestGroup1,cn=Users,dc=SomeDomain,dc=lan
member: cn=TestGroup2,cn=Users,dc=SomeDomain,dc=lan
member: cn=kostya,cn=Users,dc=SomeDomain,dc=lan
labeledURI: ldap:///cn=Users,dc=SomeDomain,dc=lan?userPrincipalName?one?(RecursiveMemberOf=cn=TestGroup1,cn=users,dc=SomeDomain,dc=lan)
dn: cn=TestGroup2,cn=Users,dc=SomeDomain,dc=lan
member: cn=egor,cn=Users,dc=SomeDomain,dc=lan
labeledURI: ldap:///cn=Users,dc=SomeDomain,dc=lan?userPrincipalName?sub?(memberOf=cn=TestGroup2,cn=Users,dc=SomeDomain,dc=lan)
В группе TestGroup1 рекурсивный поиск членов, в TestGroup2 -- обычный. Если теперь сделать поиск без указания атрибутов, динамическое содержимое возвращается, причём с учётом вложенной группы:
$ ldapsearch -xLLL -o ldif-wrap=no -H ldap://127.1:9000 -b cn=users,dc=SomeDomain,dc=lan '(cn=TestGroup*)'
dn: cn=TestGroup1,cn=Users,dc=SomeDomain,dc=lan
objectClass: top
objectClass: Group
<...>
userPrincipalName: egor@SomeDomain.lan
userPrincipalName: kostya@SomeDomain.lan
dn: cn=TestGroup2,cn=Users,dc=SomeDomain,dc=lan
objectClass: top
objectClass: Group
<...>
userPrincipalName: egor@SomeDomain.lan
Если при поиске указать атрибуты, то динамическое содержимое не возвращается:
$ ldapsearch -xLLL -o ldif-wrap=no -H ldap://127.1:9000 -b cn=users,dc=SomeDomain,dc=lan '(cn=TestGroup*)' userPrincipalName
dn: cn=TestGroup1,cn=Users,dc=SomeDomain,dc=lan
dn: cn=TestGroup2,cn=Users,dc=SomeDomain,dc=lan
Такие результаты. Зависаний никаких замечено не было.
Егор
-
Ну тогда я вообще ничего не понимаю:
1. поменял laberedURI на labeledURI: ldap:///ou=Groups,dc=external,dc=company,dc=by?userPrincipalName?one?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by)
перестало выдавать userprincipalname
2. Пробовал различные комбинации вплоть до ldap:///ou=Users,ou=Sytoss,ou=Organization,dc=external,dc=company,dc=by?userPrincipalName?sub?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by) c различными комбинациями one/sub - либо взвисает, либо не показывает userprincipalname.
Какая версия openldap у Вас и для какой платформы?
-
Ну тогда я вообще ничего не понимаю:
1. поменял laberedURI на labeledURI: ldap:///ou=Groups,dc=external,dc=company,dc=by?userPrincipalName?one?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by)
перестало выдавать userprincipalname
Логично, в ветке ou=Groups,dc=external,dc=company,dc=by нет записей пользователей, соответственно нет атрибутов memberof.
2. Пробовал различные комбинации вплоть до ldap:///ou=Users,ou=Sytoss,ou=Organization,dc=external,dc=company,dc=by?userPrincipalName?sub?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by) c различными комбинациями one/sub - либо взвисает, либо не показывает userprincipalname.
Какая версия openldap у Вас и для какой платформы?
AD на Win2003R2, OpenLDAP 2.4.31 на Ubuntu 16.04 (я это указывал в предыдущем посте). Мне кажется, дело всё-таки в AD: у меня простая "плоская" структура (всё в cn=Users), у Вас всё раскидано по разным веткам, на каком-то этапе поиск может не попасть в ветку, где хранятся записи пользователей или групп. Анализ debug-а slapd, к сожалению, мало помогает -- слишком много вываливается информации, трудно определить, где затык.
Можно попробовать в labeledURI динамической группы указать такой URL:
ldap:///dc=external,dc=company,dc=by?userPrincipalName?sub?(&(objectClass=user)(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=external,dc=company,dc=by))
Егор
-
Спасибо, завтра попробую.
-
попробовал, эффект тот же
-
Добрый день, Егор.
Вроде заработало:
1. сменил meta backend на ldap
2. Соответственно встоееный meta rewrite заменил на RWM overlay.
Почему не хотел работать meta мне совсем не понятно.
-
Да, здесь как-нибудь отображается, что проблема решена.
-
Здравствуйте, Игорь! Рад, что получилось.
1. сменил meta backend на ldap
2. Соответственно встоееный meta rewrite заменил на RWM overlay.
Почему не хотел работать meta мне совсем не понятно.
Механизм meta несколько для других целей. В том виде, в котором Вы собирались настраивать прокси (привязка subordinate к БД hdb), действительно больше подходит механизм ldap.
Да, здесь как-нибудь отображается, что проблема решена.
Обычно на форумах меняют заголовок самого первого поста темы, добавляя перед ним SOLVED: (или РЕШЕНО:).
Егор