- openldap-bugs - openldap.org

RE: (ITS#5392) Some traces are lost
by emmanuel.duru＠atosorigin.com 15 Jul '08

15 Jul '08

As these traces are the traces generated by Statslog macro, is it possible to replace the definition of Statslog in case LDAP_DEBUG is defined and LDAP_SYSLOG is not, to use lutil_debug instead of fprintf (stderr) ? That is, in slap.h, replace [...] #elif defined(LDAP_DEBUG) #define Statslog( level, fmt, connid, opid, arg1, arg2, arg3 ) \ do { \ if ( ldap_debug & (level) ) \ fprintf( stderr, (fmt), (connid), (opid), (arg1), (arg2), (arg3) );\ } while (0) [...] with [...] #elif defined(LDAP_DEBUG) #define Statslog( level, fmt, connid, opid, arg1, arg2, arg3 ) \ do { \ if ( ldap_debug & (level) ) \ { \ lutil_debug( ldap_debug, (level), (fmt), (connid), (opid), (arg1), (arg2), (arg3) ); \ }\ } while (0) [...]

1 0

Re: (ITS#5584)
by abartlet＠samba.org 15 Jul '08

15 Jul '08

--=-OCQI7+YC0WINty5M6nQu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-07-01 at 02:49 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > --=3D-GddVbqVLc61XV3X/kWQ/ > > Content-Type: text/plain > > Content-Transfer-Encoding: quoted-printable > > > > I've uploaded the patch to http://abartlet.net/memberof.patch >=20 > I committed a different patch to HEAD. Please test. I just wanted to note that I have looked at this, but it seems that some other change in the meantime has meant that the invalid DN check is missed - in setting member attributes (I doubt it was ever intentional, but it allowed the test to proceed to this point). I may have to write a validation module on the Samba side for this, until we get this validation in OpenLDAP. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-OCQI7+YC0WINty5M6nQu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIfJXiz4A8Wyi0NrsRAtHRAJ9fY0s6fkAI0I8OmcQUL6NeHxPuFQCglAQT TlftIPNYEIqc1o1j31dgNF0= =qwa/ -----END PGP SIGNATURE----- --=-OCQI7+YC0WINty5M6nQu--

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by michael＠stroeder.com 15 Jul '08

15 Jul '08

fawadlateef(a)gmail.com wrote: > > By looking at RFC4533 AND slapo-accesslog I __don't__ think they can > be used against what my contributed overlay can do. Judging from your description using syncrepl is __exactly__ what you need. Especially since some HTTP requests might get lost. > Now the thing is: in our case, the web-page is not used to display > modifications to users or on the browser __rather__ it perform some > operations on other enterprise applications based on the event > triggered from LDAP overlay hence polling kind of mechanism can't work > for us. Use syncrepl's refreshAndPersist mode. Also write your sync component in such a fashion that if connection is down for some times you can catch up with changes happened in between. Ciao, Michael.

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by fawadlateef＠gmail.com 14 Jul '08

14 Jul '08

Thanks for your replies. By looking at RFC4533 AND slapo-accesslog I __don't__ think they can be used against what my contributed overlay can do. The overlay actually monitors add/delete/modify operations based on attributes/dn/classobject and if they matches it triggers event to the URL (like interrupt). Now the thing is: in our case, the web-page is not used to display modifications to users or on the browser __rather__ it perform some operations on other enterprise applications based on the event triggered from LDAP overlay hence polling kind of mechanism can't work for us. We are going to use this overlay in our open-source-product "Zivios - Open Source Enterprise Management". Zivios will be used for management of all enterprise applications (like OpenLDAP, Kerberos, Mail-Server, Network Time Server etc) from a single web-based panel, so all modifications done through Zivios on LDAP will be made/reflected on other applications/servers at the same time. Now if somebody perform some operation on OpenLDAP directly (means by skipping Zivios) then Zivios should be triggered for such a change and then it can act on other servers accordingly. Thus event received by Zivios is __not__ for displaying data; rather its for doing some background processing although this overlay can be used to display LDAP operations on web too. Please suggest me someother way which can work on scenario mentioned above if my overlay isn't good enough. Let me know if overlay name or description isn't clear and is creating misundestanding about the functionality of the overlay. -- Fawad Lateef

1 0

Re: (ITS#5614) Ignore invalid search filters
by ando＠sys-net.it 14 Jul '08

14 Jul '08

hyc(a)symas.com wrote: > I don't think ldap_munge_filter() is adequate any more. Note that filter2bv > doesn't use (?=undefined) for unknown attributeTypes or illegal values any > more, it uses (?<attr>=<value>). This change was made to allow the log > messages to show what the actual offending values were. A better strategy here > may be to walk the Filter tree and look for > (f->f_choice&SLAPD_FILTER_UNDEFINED) before making the search request, so that > no retries are needed. That's what the new patch does, for example, for back-meta. However, we still need somehow to "unparse" the filter to allow those substitutions the proxy must honor, like "(?=true)", "(?=false)". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5614) Ignore invalid search filters
by hyc＠symas.com 14 Jul '08

14 Jul '08

ando(a)sys-net.it wrote: > andrew.graham(a)agustawestland.com wrote: > >> In line with the behavious specified in ITS 3785, any invalid search filter >> applied against back-meta will force a query including the search filter >> (!(objectClass=*)). As this filter can result in slow performance for certain >> brands of LDAP server, please provide an option to ignore invalid search filters >> in back-meta. > > A patch is in HEAD for back-ldap& back-meta. Use the "noundeffilter > {true|FALSE}" statement. Please test. p. I don't think ldap_munge_filter() is adequate any more. Note that filter2bv doesn't use (?=undefined) for unknown attributeTypes or illegal values any more, it uses (?<attr>=<value>). This change was made to allow the log messages to show what the actual offending values were. A better strategy here may be to walk the Filter tree and look for (f->f_choice&SLAPD_FILTER_UNDEFINED) before making the search request, so that no retries are needed. -- -- 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#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by quanah＠zimbra.com 14 Jul '08

14 Jul '08

--On Monday, July 14, 2008 9:04 PM +0000 hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> fawadlateef(a)gmail.com wrote: >> >>> Contributing an overlay which submits modification in LDAP to a >>> web-page through libcurl. >> >> Thanks for the contribution. Without having looked too much into the >> solution you designed, however, I believe you moved too much effort at >> the DSA side. An alternative approach to your problem consists in using >> the RFC4533 LDAP Sync to design a client that is persistently returned >> any change in data matching a search request, letting the client adapt >> the results into the desired form for the web page. The client could be >> easily embedded in a web server, e.g. using the scripting capabilities >> that most web servers have, or even coded using those scripting >> capabilities, provide they support the capability to implement the LDAP >> extensions used by RFC 4533. > > Actually, even without RFC4533, all that's needed is to use > slapo-accesslog and let the web server query the log DB whenever a user > accesses the page. -- Along Pierangelo's answer, I'll note that Net::LDAPapi perl module can be an LDAP sync client, and thus used to drive any number of things based off changes made to an accesslog DB. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by hyc＠symas.com 14 Jul '08

14 Jul '08

ando(a)sys-net.it wrote: > fawadlateef(a)gmail.com wrote: > >> Contributing an overlay which submits modification in LDAP to a web-page through >> libcurl. > > Thanks for the contribution. Without having looked too much into the > solution you designed, however, I believe you moved too much effort at > the DSA side. An alternative approach to your problem consists in using > the RFC4533 LDAP Sync to design a client that is persistently returned > any change in data matching a search request, letting the client adapt > the results into the desired form for the web page. The client could be > easily embedded in a web server, e.g. using the scripting capabilities > that most web servers have, or even coded using those scripting > capabilities, provide they support the capability to implement the LDAP > extensions used by RFC 4533. Actually, even without RFC4533, all that's needed is to use slapo-accesslog and let the web server query the log DB whenever a user accesses the page. -- -- 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#5614) Ignore invalid search filters
by ando＠sys-net.it 14 Jul '08

14 Jul '08

andrew.graham(a)agustawestland.com wrote: > In line with the behavious specified in ITS 3785, any invalid search filter > applied against back-meta will force a query including the search filter > (!(objectClass=*)). As this filter can result in slow performance for certain > brands of LDAP server, please provide an option to ignore invalid search filters > in back-meta. A patch is in HEAD for back-ldap & back-meta. Use the "noundeffilter {true|FALSE}" statement. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by ando＠sys-net.it 14 Jul '08

14 Jul '08

fawadlateef(a)gmail.com wrote: > Contributing an overlay which submits modification in LDAP to a web-page through > libcurl. Thanks for the contribution. Without having looked too much into the solution you designed, however, I believe you moved too much effort at the DSA side. An alternative approach to your problem consists in using the RFC4533 LDAP Sync to design a client that is persistently returned any change in data matching a search request, letting the client adapt the results into the desired form for the web page. The client could be easily embedded in a web server, e.g. using the scripting capabilities that most web servers have, or even coded using those scripting capabilities, provide they support the capability to implement the LDAP extensions used by RFC 4533. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5592) Quarantine in back-meta
by andrew.graham＠agustawestland.com 14 Jul '08

14 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I patched the changes into 2.4.10, quarantine now works perfectly. Thanks for yet another speedy response! Drew Andrew Graham AgustaWestland UK andrew.graham(a)agustawestland.com >>> <ando(a)sys-net.it> 12/07/2008 14:23 >>> andrew.graham(a)agustawestland.com wrote: > The quarantine function in back-meta will permanently disable a target if a > query is received while the quarantine has been imposed. Fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it ----------------------------------- *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

1 0

(ITS#5614) Ignore invalid search filters
by andrew.graham＠agustawestland.com 14 Jul '08

14 Jul '08

Full_Name: Andrew Graham Version: 2.4.10 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.169.32.250) In line with the behavious specified in ITS 3785, any invalid search filter applied against back-meta will force a query including the search filter (!(objectClass=*)). As this filter can result in slow performance for certain brands of LDAP server, please provide an option to ignore invalid search filters in back-meta.

1 0

(ITS#5613) slapd determines hostname by PTR even if host url defined, breaking ServerID
by joe＠julianfamily.org 14 Jul '08

14 Jul '08

Full_Name: Joe Julian Version: 2.4.10 OS: Linux (Fedora 7 distribution) URL: Submission from: (NULL) (68.178.24.202) Description of problem: slapd is called with "-h ldap://ldap1.domain.dom" where ldap1 is a CNAME for the actual server name "moe.domain.dom" and "-h ldap://ldap2.domain.dom" for "curly.domain.dom". The cn=config entries for olcServerID are "1 ldap://ldap1.domain.dom" and "2 ldap://ldap2.domain.dom" In config_generic (bconfig.c) case CFG_SERVERID lud->lud_host is compared with global_host. As the PTR record for moe is moe.domain.dom and not ldap1.domain.dom, moe does not get assigned a serverID. The same is true for curly. Version-Release number of selected component (if applicable): openldap_2.4.8 Steps to Reproduce: 1. configure a server's dns entries for the actual name of the server 2. configure a cname that's different 3. call slapd with "-h": the url referring to the cname of the server Actual results: no serverID defined Expected results: the serverID should be selected (in part) based on the "-h" url configuration matching an olcServerID entry

1 0

(ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by fawadlateef＠gmail.com 14 Jul '08

14 Jul '08

Full_Name: Fawad Lateef Version: 2.4.10 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/fawadlateef-contrib-updopstoweb-080714.tgz Submission from: (NULL) (202.133.78.60) Contributing an overlay which submits modification in LDAP to a web-page through libcurl. Description: ------------ This package contains a slapd overlay, updopstoweb, that provides support for monitoring add/modify/delete operations performed on LDAP and sends the information related to operation going to be performed on LDAP to a web-site through libcurl api. It also provides support for specifying an IP address which will not be monitored, e.g. if you want to monitor operations from remote system then you can specify local-host IP and then it will ignore local-host operations. Monitoring of operations is based on dn, attributes and object classes which are provided through entries in slapd.conf file. Web-site URL and IP address for ignoring operations from are also provided to overlay through slapd.conf file. Although all these parameters can be provided at run-time through back-config. The overlay is tested on openldap-2.4.10 although it can work on any version of openldap-2.4 For details please consult README provided in the package

1 0

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by mbackes＠symas.com 14 Jul '08

14 Jul '08

> To further elaborate, even if the virtual DN is set instead of the > real one in c_ndn, the operation fails because ACL checking passes > through bi_entry_get_rw(), which is not provided by slapo-rwm, and > can't be provided according to the current design, since it does not > allow to massage the arguments. As a quick'n'dirty fix, what you > can do is make the proxy database serve both naming contexts, namely > > database ldap > suffix "dc=remote,dc=local" > suffix "dc=remote" This works for getting the query to the right place; thanks! Remapped attributes in the acl obviously don't work, but working around that is straight-forward also. > This is a hack; the real fix requires to redesign the API of > bi_entry_get_rw(), to let it modify the request arguments while > letting the real function do the hard job. Right, okay. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by ando＠sys-net.it 13 Jul '08

13 Jul '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> michael(a)stroeder.com wrote: >>> First this raises the question what to do if filters are not valid in >>> configuration. I'd prefer if slapo-constraint would cause invalidFilter >>> with an appropriate diagnosticMessage pointing to slapo-constraint >>> configuration to be returned instead of silently assuming the attribute >>> value is wrong. >> AFAIK, an invalid filter in the configuration would prevent slapd from >> starting, although right now checks are not that tight. > > ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit)) > > obviously contains an invalid filter. But slapd starts without complaining. OK, this type of error is not caught basically because no real check is done besides parsing the URI. I was more concerned about erroneous filters as a result of constructing the constraint filter. However, I notice that even in case of an incorrect filter, str2filter() will not fail, but rather generate a filter with erroneous terminal filters marked as erroneous, without complaining. Moreover, the internal search will return as successful but likely with no results. This is the expected behavior for a real search. So tracing an incorrect filter is not that obvious. >>> Still it does not work for me. The filter seems to be ok now and returns >>> the correct search result. But still the attribute value "Abteilung 1" >>> is not accepted. >> Can you provide the filter, the relevant data (or an excerpt of it) and >> the operation you're trying to perform? > > I could provide a complete canned config in a personal e-mail if you want. I'll let you know if that's needed. Maybe what you posted below is enough. p. > Just for the ITS: > > ---------------------- excerpt slapd.conf ---------------------- > overlay constraint > constraint_attribute gender regex ^[0129]?$ > constraint_attribute departmentNumber uri > ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit) > constraint_attribute manager uri > ldap:///ou=Managers,ou=schulung,dc=stroeder,dc=local?entryDN?one?(objectClass=inetOrgPerson) > ---------------------- entry to be modified ---------------------- > dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local > cn: Michael Stroeder > givenName: Michael > hasSubordinates: FALSE > objectClass: inetOrgPerson > sn: Stroeder > > ---------------------- modification operation ---------------------- > dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local > changetype: modify > add: departmentNumber > departmentNumber: Abteilung 1 > - > > ---------------------- departments ---------------------- > dn: ou=Departments,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Departments > > dn: ou=Abteilung 1,ou=Departments,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Abteilung 1 > > dn: ou=Abteilung 2,ou=Departments,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Abteilung 2 > > -------------------------------------------------------------- > > Ciao, Michael > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by michael＠stroeder.com 13 Jul '08

13 Jul '08

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> First this raises the question what to do if filters are not valid in >> configuration. I'd prefer if slapo-constraint would cause invalidFilter >> with an appropriate diagnosticMessage pointing to slapo-constraint >> configuration to be returned instead of silently assuming the attribute >> value is wrong. > > AFAIK, an invalid filter in the configuration would prevent slapd from > starting, although right now checks are not that tight. ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit)) obviously contains an invalid filter. But slapd starts without complaining. >> Still it does not work for me. The filter seems to be ok now and returns >> the correct search result. But still the attribute value "Abteilung 1" >> is not accepted. > > Can you provide the filter, the relevant data (or an excerpt of it) and > the operation you're trying to perform? I could provide a complete canned config in a personal e-mail if you want. Just for the ITS: ---------------------- excerpt slapd.conf ---------------------- overlay constraint constraint_attribute gender regex ^[0129]?$ constraint_attribute departmentNumber uri ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit) constraint_attribute manager uri ldap:///ou=Managers,ou=schulung,dc=stroeder,dc=local?entryDN?one?(objectClass=inetOrgPerson) ---------------------- entry to be modified ---------------------- dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local cn: Michael Stroeder givenName: Michael hasSubordinates: FALSE objectClass: inetOrgPerson sn: Stroeder ---------------------- modification operation ---------------------- dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local changetype: modify add: departmentNumber departmentNumber: Abteilung 1 - ---------------------- departments ---------------------- dn: ou=Departments,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Departments dn: ou=Abteilung 1,ou=Departments,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Abteilung 1 dn: ou=Abteilung 2,ou=Departments,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Abteilung 2 -------------------------------------------------------------- Ciao, Michael

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by ando＠sys-net.it 12 Jul '08

12 Jul '08

michael(a)stroeder.com wrote: > Pierangelo Masarati wrote: >> michael(a)stroeder.com wrote: >> >>> Looking at the logs slapo-constraint seems to generate a filter which is >>> considered bad by slapd: >>> >>> constraint_violation uri filter = >>> (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) >>> >>> This filter would work and finds the correct entry containing the valid >>> attribute value: >>> (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) >> The overlay assumes you don't put brackets around your filter. This is >> now fixed in HEAD; please test. p. > > First this raises the question what to do if filters are not valid in > configuration. I'd prefer if slapo-constraint would cause invalidFilter > with an appropriate diagnosticMessage pointing to slapo-constraint > configuration to be returned instead of silently assuming the attribute > value is wrong. AFAIK, an invalid filter in the configuration would prevent slapd from starting, although right now checks are not that tight. > Still it does not work for me. The filter seems to be ok now and returns > the correct search result. But still the attribute value "Abteilung 1" > is not accepted. Can you provide the filter, the relevant data (or an excerpt of it) and the operation you're trying to perform? I just checked slapo-constraint, after fixing it, and it seemed to work as expected. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by michael＠stroeder.com 12 Jul '08

12 Jul '08

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: > >> Looking at the logs slapo-constraint seems to generate a filter which is >> considered bad by slapd: >> >> constraint_violation uri filter = >> (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) >> >> This filter would work and finds the correct entry containing the valid >> attribute value: >> (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) > > The overlay assumes you don't put brackets around your filter. This is > now fixed in HEAD; please test. p. First this raises the question what to do if filters are not valid in configuration. I'd prefer if slapo-constraint would cause invalidFilter with an appropriate diagnosticMessage pointing to slapo-constraint configuration to be returned instead of silently assuming the attribute value is wrong. Still it does not work for me. The filter seems to be ok now and returns the correct search result. But still the attribute value "Abteilung 1" is not accepted. Ciao, Michael. --------------------------------- snip --------------------------------- ==> constraint_violation uri filter = (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) put_filter: "(&(objectClass=organizationalUnit)(|(ou=Abteilung 1)))" put_filter: AND put_filter_list "(objectClass=organizationalUnit)(|(ou=Abteilung 1))" put_filter: "(objectClass=organizationalUnit)" put_filter: simple put_simple_filter: "objectClass=organizationalUnit" put_filter: "(|(ou=Abteilung 1))" put_filter: OR put_filter_list "(ou=Abteilung 1)" put_filter: "(ou=Abteilung 1)" put_filter: simple put_simple_filter: "ou=Abteilung 1" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=Departments,ou=schulung,dc=stroeder,dc=local") => hdb_dn2id("ou=Departments,ou=schulung,dc=stroeder,dc=local") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => access_allowed: disclose access to "ou=schulung,dc=stroeder,dc=local" "entry" requested <= root access granted => access_allowed: disclose access granted by manage(=mwrscxd) send_ldap_result: conn=1 op=28 p=3 send_ldap_result: err=10 matched="ou=schulung,dc=stroeder,dc=local" text="" ==> constraint_violation uri rc = 32, found = 0 send_ldap_result: conn=1 op=28 p=3 send_ldap_result: err=19 matched="" text="modify breaks constraint on departmentNumber" send_ldap_response: msgid=29 tag=103 err=19 ber_flush2: 58 bytes to sd 17 conn=1 op=28 RESULT tag=103 err=19 text=modify breaks constraint on departmentNumber

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by ando＠sys-net.it 12 Jul '08

12 Jul '08

michael(a)stroeder.com wrote: > Looking at the logs slapo-constraint seems to generate a filter which is > considered bad by slapd: > > constraint_violation uri filter = > (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) > > This filter would work and finds the correct entry containing the valid > attribute value: > (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) The overlay assumes you don't put brackets around your filter. This is now fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5592) Quarantine in back-meta
by ando＠sys-net.it 12 Jul '08

12 Jul '08

andrew.graham(a)agustawestland.com wrote: > The quarantine function in back-meta will permanently disable a target if a > query is received while the quarantine has been imposed. Fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5599) slapd dies on erroneous MOD input
by ando＠sys-net.it 12 Jul '08

12 Jul '08

suomi(a)ayni.com wrote: > Full_Name: suomi hasler > Version: 2.4.8-3 > OS: fedora 9 > URL: http://www.ayni.com/slap-prob.txt > Submission from: (NULL) (194.158.243.162) Note that the current release is 2.4.10, and 2.4.11 is about to be released. I couldn't notice any issue in current code after performing erroneous modifications like the one you indicated. Please recheck with the latest release (the pre-release 2.4 from the CVS would be best). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by ando＠sys-net.it 12 Jul '08

12 Jul '08

ando(a)sys-net.it wrote: > mbackes(a)symas.com wrote: > > The reason is quite simple: set expansion uses the rewritten DN as the > user's name, so a local lookup of the entry "cn=user,dc=remote" fails > since no local database serves the naming context "dc=remote". The root > cause is that back-ldap binds as the rewritten DN, which is later stored > as the real identity. I think this was done on purpose, and is to some > extent appropriate, but makes the type of ACL you want to design > basically impossible. A solution would be to make slapo-rwm intercept > successful binds (in the cleanup callback) and rewrite back the bound DN > into the virtual naming context. I'll see if it is possible, but then > we need to decide whether this is the desired behavior. Otherwise, we'd > need to have two o_ndn fields: the real DN and the real-real DN. To further elaborate, even if the virtual DN is set instead of the real one in c_ndn, the operation fails because ACL checking passes through bi_entry_get_rw(), which is not provided by slapo-rwm, and can't be provided according to the current design, since it does not allow to massage the arguments. As a quick'n'dirty fix, what you can do is make the proxy database serve both naming contexts, namely database ldap suffix "dc=remote,dc=local" suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" This allows the proxy database to be found by select_backend() when searching the right backend using the real naming context. At the same time, internal searches occur as expected. This is a hack; the real fix requires to redesign the API of bi_entry_get_rw(), to let it modify the request arguments while letting the real function do the hard job. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by ando＠sys-net.it 12 Jul '08

12 Jul '08

mbackes(a)symas.com wrote: The reason is quite simple: set expansion uses the rewritten DN as the user's name, so a local lookup of the entry "cn=user,dc=remote" fails since no local database serves the naming context "dc=remote". The root cause is that back-ldap binds as the rewritten DN, which is later stored as the real identity. I think this was done on purpose, and is to some extent appropriate, but makes the type of ACL you want to design basically impossible. A solution would be to make slapo-rwm intercept successful binds (in the cleanup callback) and rewrite back the bound DN into the virtual naming context. I'll see if it is possible, but then we need to decide whether this is the desired behavior. Otherwise, we'd need to have two o_ndn fields: the real DN and the real-real DN. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

ldapi:// SASL EXTERNAL on solaris10
by David Markey 11 Jul '08

11 Jul '08

Hi, I'm trying to implement heimdal with an LDAP backend on solaris 10 and im getting issues with authentication when initialising a realm: kadmin> init DMARKEY.COM kadmin: hdb_open: ldap_sasl_bind_s: Authentication method not supported __________________________ ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 send_ldap_result: err=7 matched="" text="SASL(-4): no mechanism available: " connection_get(12) ber_dump: buf=82c5408 ptr=82c5408 end=82c540d len=5 0000: 02 01 02 42 00 slapd.conf(snippet): sasl-secprops minssf=0 sasl-regexp .*uidNumber=0.*,cn=peercred, cn=external,cn=auth uid=heimdal,dc=services,dc=dmarkey,dc=com Would anyone be able to help me? Solaris 10 x86, Heimdal 1.0.2, slapd 2.3.39 I've established this is a solaris specific problem, i compiled everything from scratch on CentOS with the same options and it worked fine. Anyone have any ideas? are sockets different on solaris? Much appreciated.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs