1
Общий раздел / Re: И снова про memberOf
« : 11 Июнь 2019, 08:59:44 »
Спасибо, вроде помогло.
Отдал прикладникам на тестирование.
Отдал прикладникам на тестирование.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Страницы: [1]
2
Общий раздел / И снова про 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 домены.
Недавно прикладники заметили такую штуку:
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 домены.
3
Общий раздел / Re: Обработка вложенных posixGroup
« : 10 Июнь 2019, 12:23:59 »
Добрый день, Егор.
Попробовал.
Оно действительно сваливается постоянно.
Причём после перезапуска один запрос выполняет нормально пока его не изменишь. На пример, при добавлении атрибута или смене фильтра в запросе.
Т.е. к работе совершенно не годен.
Может это как-то решается?
Попробовал.
Оно действительно сваливается постоянно.
Причём после перезапуска один запрос выполняет нормально пока его не изменишь. На пример, при добавлении атрибута или смене фильтра в запросе.
Т.е. к работе совершенно не годен.
Может это как-то решается?
4
Общий раздел / Re: Обработка вложенных posixGroup
« : 31 Май 2019, 15:17:44 »
Добрый день, Егор.
Спасибо.
Надо обдумать Ваше решение.
Может есть возможность добавить атрибуты в запрос, или убрать оттуда?
Спасибо.
Надо обдумать Ваше решение.
Может есть возможность добавить атрибуты в запрос, или убрать оттуда?
5
Общий раздел / Обработка вложенных 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 не возвращает ничего.
Как кто боролся с подобной проблемой?
С уважением, Игорь
Нужна идеологическая помощь. (Идея нужна).
Наверняка кто-то такое уже делал.
Я ввёл solaris10 в два AD домена- для этого развернул прокси openLdap с ldap бэкендами.
Всё хорошо, и даже просто отлично работает. Solaris 11 даже отлично обрабатывает вложенные группы.
Но вот Solaris 10 отказывается это делать- он читает MemberUid атрибуты группы, и на основании их определяет членов групп.
Я пробовал настроить dynlist с запросом к AD memberOf:1.2.840.113556.1.4.1941: - это поиск по всей цепочке групп. простой ldapsearch ,без указания уточнения атрибутов работает на ура, но solaris 10 в запросе указывает атрибуты, что по описанию самого dynlist не возвращает ничего.
Как кто боролся с подобной проблемой?
С уважением, Игорь
6
Конфигурация через cn=config / dynlist не закрывет соединение
« : 20 Май 2019, 13:40:15 »
Да, здесь как-нибудь отображается, что проблема решена.
7
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 20 Май 2019, 13:38:32 »
Добрый день, Егор.
Вроде заработало:
1. сменил meta backend на ldap
2. Соответственно встоееный meta rewrite заменил на RWM overlay.
Почему не хотел работать meta мне совсем не понятно.
Вроде заработало:
1. сменил meta backend на ldap
2. Соответственно встоееный meta rewrite заменил на RWM overlay.
Почему не хотел работать meta мне совсем не понятно.
8
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 15 Май 2019, 08:56:47 »
попробовал, эффект тот же
9
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 15 Май 2019, 08:29:49 »
Спасибо, завтра попробую.
10
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 14 Май 2019, 16:30:26 »
Ну тогда я вообще ничего не понимаю:
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
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 у Вас и для какой платформы?
11
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 13 Май 2019, 10:27:50 »
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)
не помогло- всё так и осталось.
c=by?userPrincipalName?sub?(RecursiveMemberOf=cn=ext_bscs,ou=Groups,dc=extern
al,dc=company,dc=by)
не помогло- всё так и осталось.
12
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 13 Май 2019, 08:28:14 »
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)
показывет следующее:
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)
13
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 13 Май 2019, 08:05:28 »
ДОбрый день, Егор.
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
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
14
Конфигурация через cn=config / Re: dynlist не закрывет соединение
« : 11 Май 2019, 14:19:30 »
Добрый день, Егор.
Всё работает нормально, в том числе и 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 возвращает правильную информацию, но после этого всё зависает, пока на клиенте не дашь ^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 всех её членов.
На мой взгляд, данный подход даст возможность иметь вложенность любого уровня. (Если заработает)
15
Конфигурация через cn=config / [SOLVED] dynlist не закрывет соединение
« : 10 Май 2019, 16:22:32 »
Добрый день.
Имею конфигурацию proxy openLdap на AD:
(slapcat -n0 выдержки в приложении)
Всё работает нормально, пока запрос не попадает на dynlist.
Как только он туда попадает, отвечает нормально, и зависает.
Дальнейший поиск останавливается и висит пока не отработает таймаут.
Имею конфигурацию proxy openLdap на AD:
(slapcat -n0 выдержки в приложении)
Всё работает нормально, пока запрос не попадает на dynlist.
Как только он туда попадает, отвечает нормально, и зависает.
Дальнейший поиск останавливается и висит пока не отработает таймаут.
Страницы: [1]