[SOLVED] dynlist не закрывет соединение

[Игорь]

Добрый день.
Имею конфигурацию proxy openLdap на AD:
(slapcat -n0 выдержки в приложении)
Всё работает нормально, пока запрос не попадает на dynlist.
Как только он туда попадает, отвечает нормально, и зависает.
Дальнейший поиск останавливается и висит пока не отработает таймаут.

[egor]

Здравствуйте, Игорь!

Интересная конфигурация. Даже не знаю, сможет ли она вообще в принципе заработать =) . Какой вид записей Вы хотите наполнять динамическим содержимым с помощью наложения 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 всех её членов.
На мой взгляд, данный подход даст возможность иметь вложенность любого уровня. (Если заработает)

[egor]

Здравствуйте! Тут сразу столько тонких мест, что затык может случиться в любой момент.

Во-первых, я бы не стал применять наложение 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)

[egor]

Есть предположение, что осуществляется попытка обратиться туда, куда у пользователя, от которого подключается механизм 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)

не помогло- всё так и осталось.

[egor]

Пришлось делать стенд =) . 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 у Вас и для какой платформы?

[egor]

Ну тогда я вообще ничего не понимаю:
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 мне совсем не понятно.

[Игорь]

Да, здесь как-нибудь отображается, что проблема решена.