openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#6668) MemberOf Overlay
by wf＠bitplan.com 10 Oct '10

10 Oct '10

Full_Name: Wolfgang Fahl Version: 2.4 OS: many URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.193.149.46) We have been struggling a full day with the memberOf issue and have now given up. In our humble opinon the complexity is well out of range for such a seemingly trival functionality.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> The configuration and test operations below should show exactly what's > going on, but first, allow me to describe the > process in a nutshell: > > 1. The client binds to the slave and issues a modification request > > 2. The slave creates the referral and tries to chase it automatically on > the client's behalf to the upstream master > using slapo-chain > > 3. The automatic referral chasing fails because the DN is not passed > through and the slave erroneously rebinds to the > master as anonymous (an empty DN) instead of the identity it's configured > to assert, as set by the olcDbIDAssertBind > attribute. > > 4. Because the automatic referral chasing fails, the slave kicks back the > referral to the client, stating that the > client "is not logged in" to the master and that "modifications require > authentication". > > 5. When the client provides credentials for the referral (manual referral > chasing), the rest of the operation works as > expected (updates made on master, which then cascades to the slaves). What the case description and the logs suggest is that the referral is chased anonymously because the protocol/host/port portion of the URI in the referral does not match the one configured in the chain-uri directive. In this case, slapo-chain defaults to anonymous. What slapo-chain does is take the referral string, pass it to URL parsing routines, isolate protocol, host and port, pass it back to URL unparsing, and compare the resulting string with the one configured in chain-uri (which had to go through the same "normalization" when configured). Perhaps if you try with a more detailed log level you'll be able to see the two strings and figure out if and how they differ. Hope this helps. p. > > The following LDIFs and sample operations exemplify the problem; please > let me know if this example suffices, or if you > need a more complete reference or further clarification: > > ################################################# > # CONFIGURATION # > ################################################# > > ### back-config base entry on slave (abbreviated) > dn: cn=config > objectClass: olcGlobal > cn: config > olcConfigDir: /etc/ldap/slapd.d > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcTLSCACertificateFile: /etc/ldap/ssl/certs/cacert.pem > olcTLSCertificateFile: /etc/ldap/ssl/certs/openldap.cert.pem > olcTLSCertificateKeyFile: /etc/ldap/ssl/keys/openldap.key.pem > olcAuthzPolicy: none > olcLogLevel: stats sync > olcPasswordHash: {SSHA}SUPERSECRET > olcServerID: 1 ldap://master1.example.com > olcServerID: 2 ldap://slave1.example.com > > ### back-config modules entry > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModulePath: /usr/lib/ldap > olcModuleLoad: {0}back_hdb.la > olcModuleLoad: {1}autogroup.la > olcModuleLoad: {2}syncprov.la > olcModuleLoad: {3}back_ldap.la > > ### back-config chain overlay entry > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcOverlayConfig > objectClass: olcChainConfig > olcOverlay: {0}chain > > ### back-config chain database > dn: > olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcLDAPConfig > objectClass: olcChainDatabase > olcDatabase: {0}ldap > olcDbURI: ldap://master1.example.com > olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" > credentials=SECRET mode=self > > > ################################################# > # SIMPLE OPERATIONAL EXAMPLE # > ################################################# > > ### NOTE: This example uses ldapvi, but results are identical to > ldapmodify, etc. > ### NOTE: The client binds initially to the slave as the admin here, but > results are identical to scenarios in which the > client binds as a regular user > > ### Attempting to modify 'displayColor' attribute belonging to entry > 'uid=ryans,ou=Users,dc=example,dc=com' > root@slave1:~# ldapvi -h localhost --bind=simple -D > cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover > 159 entries read > > add: 0, rename: 0, modify: 1, delete: 0 > Action? [yYqQvVebB*rsf+?] y > Received referral to > ldap://master1.example.com/uid=ryans,ou=Users,dc=example,dc=com. > You are not logged in to ldap://master1.example.com:389 yet. > Type '!' or 'y' to do so. > Rebind? [y!nB*qQ?] y > > --- Login > Type M-h for help on key bindings. > > Filter or DN: cn=admin,dc=example,dc=com > Password: *********** > Bound as cn=admin,dc=example,dc=com. > Done. > > ################################################# > # LOGS FOR OPERATIONAL EXAMPLE # > ################################################# > > ### Logs on slave showing referral was correctly generated (err=10) > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 ACCEPT from > IP=127.0.0.1:34118 (IP=0.0.0.0:389) > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 EXT > oid=1.3.6.1.4.1.1466.20037 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 STARTTLS > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 RESULT oid= err=0 text= > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 TLS established > tls_ssf=128 ssf=128 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND > dn="cn=admin,dc=example,dc=com" method=128 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND > dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 > text= > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH base="" scope=0 > deref=0 filter="(objectClass=*)" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH attr=+ * > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 ENTRY dn="" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 > err=0 nentries=1 text= > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SRCH > base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="cn=admin,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="ou=users,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="ou=groups,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="uid=ryans,ou=users,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY > dn="cn=ryans,ou=groups,dc=example,dc=com" > Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 > err=0 nentries=159 text= > Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD > dn="uid=ryans,ou=Users,dc=example,dc=com" > Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD attr=displayColor > Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 > text= > > > ### Logs on master showing that when the slave tried to chase the > referral, it erroneously bound as anonymous > ### NOTE: slave1.example.com = 10.0.1.196 > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 fd=273 ACCEPT from > IP=10.0.1.196:43376 (IP=0.0.0.0:389) > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 BIND dn="" > method=128 > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 > text= > Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=1 MOD > dn="uid=ryans,ou=Users,dc=example,dc=com" > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 MOD > attr=displayColor > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 > text=modifications require authentication > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=2 UNBIND > Oct 5 10:27:08 master1 slapd[8794]: conn=402475 fd=273 closed > Oct 5 10:27:08 master1 slapd[8794]: conn=402476 fd=273 ACCEPT from > IP=10.0.1.196:43377 (IP=0.0.0.0:389) > > > If there are any details not shown that you'd like, or any clarification > you require, or if there's anything at all you > need to help facilitate the investigation, please let me know and I'll do > my best to accommodate. Thanks! > > -Ryan > > >

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Note that the SSSVLV overlay can handle paged results locally too, thus > negating any need for back-ldap/back-meta to forward it to a remote > server. > Obviously for greatest generality, there needs to be a way to configure > which > set of controls to pass through, and which to process locally. (Much like > back-ldap's option to process the WhoAmI exop...) Right. With proxies the problem is twofold: a) clients request pr because they think they're talking to AD b) the proxy may need to use pr even if the client does not request it, because it knows it's talking to AD In (a), the issue could be handled the way sssvlv does, relieving the proxy from having to deal with server-side pr; this would be extremely beneficial, for example, for back-meta In (b), the proxy could be configured to use pr the way I mentioned above; in principle, the proxy could be so clever to avoid using pr, and simply accept to handle unrequested pr responses, but only if instructed to do so. Filtering what controls are passed thru should be easy, since both proxy backends always call ldap_back_controls_add()/meta_back_controls_add() to muck with request controls (usually to add proxied authorization and so); this function could easily strip or add pr if instructed to do so. p.

1 0

Re: (ITS#6665) back_ldap and back_meta chasing referrals authentication
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Full_Name: Javier Sanz > Version: 2.4.17 > OS: Debian Linux 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.38.203.12) > > > back_ldap and back_meta should be able to do a non-anonymous bind to the > referrals returned by the external LDAP servers. > > This is a regression since 2.3, because the old directives "pseudorootdn" > and > "pseudorootpw" allowed specifying the binddn and password that would be > used to > chase the referrals, but their 2.4 replacements "idassert-bind" and > "idassert-authzFrom" do not allow that, so these binds are always done > anonymously. Back-ldap seems to work as expected if you set chase-referrals yes rebind-as-user yes idassert-bind bindmethod=simple binddn=<dn> credentials=<cred> mode=self and binddn <dn> with credentials <cred> exists on both the remote server and the one pointed to by the referral. With back-meta, it should work with the same parameters; however, I've checked and the specific code used to bind during searches does not set the rebind procedure correctly. I've fixed this in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by hyc＠symas.com 08 Oct '10

08 Oct '10

masarati(a)aero.polimi.it wrote: >> Full_Name: Javier Sanz >> Version: 2.4.17 >> OS: Debian Linux 5.0 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.38.203.12) >> >> >> back_meta and back_ldap should forward server controls that clients use in >> their >> queries to the corresponding external LDAP servers. > > Both back-ldap and back-meta forward controls to the remote servers. > >> For example, the inhability to send controls to external servers currently >> causes that RFC2696 paged results control cannot be used, so it is >> impossible to >> retrieve more results for a query than the page size configured in the >> external >> server, which often is not a big number. > > As far as I can tell, back-ldap supports paged results correctly (just > tested with HEAD and 2.4.23 code). Back-meta does not, and likely will > never do. Please note that while all back-ldap needs to do is blindly > forward control request/response, back-meta would need to separately > handle requests server-side (i.e. when the client requests the control) > and client-side (i.e. when non LDAP-compliant remote servers return the > control while the client did not request it). In between, it would need > to return the page size requested by the client and store the (possibly > paged) response of each remote server. Not worth the effort. The > solution consists in increasing the page size returned by default by > non-LDAP compliant remote servers. > > Perhaps the problem could be split in two: > > 1) allow to configure per-target mandatory use of paged results, with a > specified page size; this means that search requests hitting a specific > target would always add the paged results control to the request, and > handle control responses accordingly. > > 2) handle server-side control response in an overlay that takes care of > storing search results and returning them as appropriate. This would > (maybe inefficiently) handle paged results regardless of the backend that > is actually handling a request. > > Even if only (1) is implemented, clients would no longer need to use pr > when talking to slapd, since back-meta would handle non-LDAP compliant > remote servers that return pr response when the control is not requested. > > I think this ITS should be closed (back-ldap and back-meta do forward > controls); maybe another ITS with a back-meta feature request to handle > non-LDAP compliant remote servers could be filed. Note that the SSSVLV overlay can handle paged results locally too, thus negating any need for back-ldap/back-meta to forward it to a remote server. Obviously for greatest generality, there needs to be a way to configure which set of controls to pass through, and which to process locally. (Much like back-ldap's option to process the WhoAmI exop...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Full_Name: Javier Sanz > Version: 2.4.17 > OS: Debian Linux 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.38.203.12) > > > back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP servers. Both back-ldap and back-meta forward controls to the remote servers. > For example, the inhability to send controls to external servers currently > causes that RFC2696 paged results control cannot be used, so it is > impossible to > retrieve more results for a query than the page size configured in the > external > server, which often is not a big number. As far as I can tell, back-ldap supports paged results correctly (just tested with HEAD and 2.4.23 code). Back-meta does not, and likely will never do. Please note that while all back-ldap needs to do is blindly forward control request/response, back-meta would need to separately handle requests server-side (i.e. when the client requests the control) and client-side (i.e. when non LDAP-compliant remote servers return the control while the client did not request it). In between, it would need to return the page size requested by the client and store the (possibly paged) response of each remote server. Not worth the effort. The solution consists in increasing the page size returned by default by non-LDAP compliant remote servers. Perhaps the problem could be split in two: 1) allow to configure per-target mandatory use of paged results, with a specified page size; this means that search requests hitting a specific target would always add the paged results control to the request, and handle control responses accordingly. 2) handle server-side control response in an overlay that takes care of storing search results and returning them as appropriate. This would (maybe inefficiently) handle paged results regardless of the backend that is actually handling a request. Even if only (1) is implemented, clients would no longer need to use pr when talking to slapd, since back-meta would handle non-LDAP compliant remote servers that return pr response when the control is not requested. I think this ITS should be closed (back-ldap and back-meta do forward controls); maybe another ITS with a back-meta feature request to handle non-LDAP compliant remote servers could be filed. p.

1 0

Re: (ITS#6667) memberof infinite recursion on node rename
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

Can you provide a minimal example that triggers the problem? You should boil it down to: - the slapd.conf or the contents of the cn=config database - the LDIF needed to populate the database - the operation that causes the problem (I presume it's a modify or a write operation, so you should be able to provide it in form of LDIF and main parameters, e.g. the identity that is performing the operation). Thanks, p.

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

Valgrind shows more issues possibly related to this ITS when SLAP_NO_SL_MALLOC is defined. When running test047, whoami results in conn=1013 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 conn=1013 op=1 WHOAMI ==11941== Thread 5: ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B122: rwm_op_rollback (rwm.c:62) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==11941== ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B13A: rwm_op_rollback (rwm.c:65) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) conn=1013 op=1 RESULT oid= err=0 text= Possibly, although not directly, related leaks: ==11941== ==11941== 244 bytes in 4 blocks are definitely lost in loss record 10 of 11 ==11941== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==11941== by 0x826BB67: ber_memalloc_x (memory.c:226) ==11941== by 0x80F5229: slap_sl_malloc (sl_malloc.c:285) ==11941== by 0x826BB82: ber_memalloc_x (memory.c:229) ==11941== by 0x824C16E: ldap_dn2bv_x (getdn.c:3015) ==11941== by 0x80A53E2: dnPrettyNormal (dn.c:745) ==11941== by 0x820D4DC: rwm_exop_passwd (rwm.c:1048) ==11941== by 0x820D7C5: rwm_extended (rwm.c:1116) ==11941== by 0x810E87D: overlay_op_walk (backover.c:659) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) Will look at this ASAP. p.

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 07 Oct '10

07 Oct '10

Hallvard B Furuseth wrote: > Maybe an overlay version of back-sock, with an overlay option > which says whether or not to wait for responses from the socket? Sure. Someone could easily start with e.g. chain.c or pbind.c and write an overlay wrapper for back-sock. Patches welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by h.b.furuseth＠usit.uio.no 07 Oct '10

07 Oct '10

Maybe an overlay version of back-sock, with an overlay option which says whether or not to wait for responses from the socket?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs