openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#5040) modifyTimestamp being updated on login (bind) failure
by dan.cushing＠netideasinc.com 05 Jul '07

05 Jul '07

Full_Name: Dan Cushing Version: 2.3.36 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.76.187.82) When running OpenLDAP with the ppolicy overlay, the modifyTimestamp for a user entry is updated if the user attempts to login (bind) with an incorrect password. This is happening because the password lockout feature is enabled and the operational attribute 'pwdFailureTime' is being updated. It seems like this results in a misleading modifyTimestamp. Is it intended that the modifyTimestamp attribute be updated when operational attributes are updated? To reproduce the issue, compile with the ppolicy overlay and enable password lockout. Below I've included the entries for a minimal policy.ldif file that I tested with. Then perform the following actions. 1) As the directory administrator execute the following search: ldapsearch -x -D "cn=Manager,o=testorg.com" -w password -b o=testorg.com uid=testuser pwdFailureTime modifyTimestamp. This will return something like "modifyTimestamp: 20070705142825Z" 2) As testuser execute the following search: ldapsearch -x -D "uid=testuser,o=testorg.com" -w correctPassword -b o=testorg.com uid=testuser modifyTimestamp. This will also return something like "modifyTimestamp: 20070705142825Z" 3) As testuser execute the following search (note the INCORRECT password): ldapsearch -x -D "uid=testuser,o=testorg.com" -w WRONGPassword -b o=testorg.com uid=testuser modifyTimestamp. This will also return something like "ldap_bind: Invalid credentials (49)" 4) As the directory administrator execute the following search: ldapsearch -x -D "cn=Manager,o=testorg.com" -w password -b o=testorg.com uid=testuser pwdFailureTime modifyTimestamp. This will return something like "pwdFailureTime: 20070705144735Z modifyTimestamp: 20070705144735Z". Note that the 'pwdFailureTime attribute has been created and the 'modifyTimestamp' attribute has been updated to the time that the bind attempt failed. Contents of my Standard policy file are ... dn: cn=Standard, ou=Policies, o=testorg.com pwdLockout: TRUE pwdMaxFailure: 3 objectClass: top objectClass: device objectClass: pwdPolicy pwdFailureCountInterval: 120 pwdLockoutDuration: 3600 cn: Standard pwdAttribute: userPassword

1 0

Re: (ITS#5035) Warning patrol
by ando＠sys-net.it 04 Jul '07

04 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > #1. slapd/frontend.c:frontend_init() has the statement > if ( slap_known_controls ) > which is always true since slap_known_controls is an array. > Maybe it should be if ( slap_known_controls[0] )? > > Except... controls.c says slap_known_controls[0] == NULL, which is > not true - at least not at the time of the if-test above. What's > that about? Probably a leftover of a time when slap_known_controls was a pointer > #2. The return value from op->o_callback->sc_cleanup() is never > used. Should it be? I noticed because the pcache_op_cleanup() > function does not return anything. What should it return? two possibilities: a) ignore it: cleanup could occur too late, when response has already been returned to client; in this case a return code is there only because of the standard API b) handle it: cleanup return code could be usefully returned to caller if (a), then the return code can be safely ignored > #3. RE23 struct sync_cookie.rid and struct syncinfo_s.si_rid are > 'long', but are printed as 'int'. Could change the formats, but - > any reason not to instead change their types to 'int' as in HEAD? > I haven't looked at the HEAD syncrepl changes, so I don't know > what other issues might be involved. There should be no impact, since they're both limited to 0,999 > #4. bconfig.c: Integer overflow in (1 << (sizeof(int)*8 - 1)) in > slap_loglevel_get(). If anything else have been trusting signed > integer overflow to resemble unsigned integers, it's time to cease > that. The behaviour is undefined, and compilers make use of this > fact to optimize. > > The loglevel functions are confused about types anyway. They > collect masks in slap_mask_t, but the API uses an int for the > masks. Agree > Either the API should use slap_mask_t Agree > or masks should be > stored in (unsigned) ints. Not for 2.3, I think. Agree 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5036) test034-translucent fails on HEAD
by ghenry＠suretecsystems.com 04 Jul '07

04 Jul '07

<quote who="hyc(a)symas.com"> > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Full_Name: Hallvard B Furuseth >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 >>> Submission from: (NULL) (129.240.202.105) >>> Submitted by: hallvard >>> >>> >>> test034-translucent fails. Output: >> >>> Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd >>> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers >>> --disable-backends --enable-bdb --enable-ldap --enable-relay >>> --enable-null >>> --enable-meta --enable-overlays CC=gcc-4.2.0 >>> 'CPPFLAGS=-DLDAP_DEPRECATED >>> -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' >> >> Strange. I got the same result with those options. But with this >> configuration, >> the test works fine: >> >> --enable-modules --enable-backends=mod --enable-overlays=mod >> --enable-slapi >> --disable-sql >> >> The test also fails with your options, but without any of the CPPFLAGS >> set. >> > Duh... In your test back-monitor is missing. Usually the monitor would be > olcDatabase={1} in the config, so the bdb instance would be > olcDatabase={2}, > and that's the name that's coded into the script. > I'm trying to get push based Syncrepl going for the docs and this test is also failing for me with HEAD updated 2 hrs ago. My options: env CC=gcc CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include" \ LDFLAGS="-L/usr/local/BerkeleyDB.4.2/lib" \ LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.2/lib" ./configure \ --prefix=/opt/suretec/ldap --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ --disable-sql --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers Gavin.

1 0

Re: (ITS#5032) cannot build on x86_64, needs newer libtool
by h.b.furuseth＠usit.uio.no 04 Jul '07

04 Jul '07

Buchan Milne writes: >> libtool translates -ldb-4.3 to /usr/lib/libdb-4.3.so, which breaks. >> "cc -ldb-4.3" uses /lib64/libdb-4.3.so. > > Only if the 32bit package is installed (which unfortunately happens by > default e.g. with 'yum install db4-devel' you get both i386 and > x86_64). OK. A libtool bug triggered by a RedHat irritant (but still non-bug). > On RHEL5: > # rpm -e db4-devel-4.3.29-9.fc6.i386 > works around this. Thanks. The system folks here say we need some of the 32-bit stuff, though:-( I wrote: > Is OpenLDAP using a patched libtool? One of the differences is that > ltmain.sh contains VERSION=1.5.22-OpenLDAP, while I get VERSION=1.5.22. Er, yes, it seems so. I was even one of the sinners, though those patches are gone now. It doesn't mention that it is a generated file. -- Regards, Hallvard

1 0

(ITS#5039) Support config for start_tls in ldap.conf
by ahasenack＠terra.com.br 04 Jul '07

04 Jul '07

Full_Name: Andreas Hasenack Version: 2.3.36 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.98) This is an enhancement request. It would be helpfull if there were some configuration option for /etc/openldap/ldap.conf to mimic the -ZZ command line, that is, behave as if the user added -ZZ to it. Perhaps something along the lines of the sasl secprops, or the server's "security" keyword. My scenario is that it doesn't matter if I block clear text communication with the ldap server via ACL or security: if the client initiates a simple bind operation in clear text, the password is exposed even if the server rejects the operation. The point here is to avoid accidents, like leaving out the -ZZ option when doing command line operations. It would be like an initial default. It also saves typing, of course ;) I can easily workaround this with shell aliases, or wrapper scripts, of course. That's why this is an enhancement request.

1 0

Re: (ITS#5037) slapd-bdb filterindex.c: out of order if statement in filter
by quanah＠zimbra.com 03 Jul '07

03 Jul '07

--On Wednesday, July 04, 2007 1:30 AM +0000 openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** nm, the function call sets db. But still the if needs to be re-ordered. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5037) slapd-bdb filterindex.c: out of order if statement in filter
by quanah＠zimbra.com 03 Jul '07

03 Jul '07

Full_Name: Quanah Gibson-Mount Version: 2.3.36/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) back-bdb's filterindex.c has code like the following throughout: if( rc != LDAP_SUCCESS ) { Debug( LDAP_DEBUG_TRACE, "<= bdb_presence_candidates: (%s) index_param " "returned=%d\n", desc->ad_cname.bv_val, rc, 0 ); return 0; } if( db == NULL ) { /* not indexed */ Debug( LDAP_DEBUG_TRACE, "<= bdb_presence_candidates: (%s) not indexed\n", desc->ad_cname.bv_val, 0, 0 ); return 0; } and if( rc != LDAP_SUCCESS ) { Debug( LDAP_DEBUG_ANY, "<= bdb_equality_candidates: (%s) " "index_param failed (%d)\n", ava->aa_desc->ad_cname.bv_val, rc, 0 ); return 0; } if ( db == NULL ) { Debug( LDAP_DEBUG_ANY, "<= bdb_equality_candidates: (%s) not indexed\n", ava->aa_desc->ad_cname.bv_val, 0, 0 ); return 0; } However, if "db" is NULL, bdb_index_param will return LDAP_INAPPROPRIATE_MATCH, which does not equal LDAP_SUCCESS, meaning that the "db == NULL" if statement is never reached. It appears the db==NULL check should be done first. Possibly, the db==NULL check should be moved before the bdb_index_param call, I can't imagine there's much point in calling the function if it isn't indexed, and the only result is to log an error and return? --Quanah

1 0

Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com 03 Jul '07

03 Jul '07

Philip Guenther wrote: > On Mon, 30 Apr 2007, Howard Chu wrote: >> guenther+ldapdev(a)sendmail.com wrote: > ... >>> - 'allow' checks the identity of the server vs its cert (per RFC 4513, >>> section 3.1.3) and will terminate the connection if they don't match >>> - 'try' is the same as 'demand' and 'hard' >> Not quite. With both "allow" and "try" it's OK if the server provides no >> certificate. > > That's true of 'demand' and 'hard' as well. The only difference between > 'try' and 'demand' in the code is that the latter passes > SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that > flag has NO EFFECT on SSL clients. This is documented on the > SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source > for it. > > If you don't believe me, I suggest you try configuring your server to > accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) > and give ldapsearch a whirl with > LDAPTLS_REQCERT=hard > LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA > > in your environment. That's what I did. When this text was written, there was no support for anonymous cipher suites. So the meaning of the text is: assuming a cipher suite that actually uses certificates, the client would proceed even if the server didn't provide a cert. It's entirely possible that this circumstance has been overcome by other developments. Most likely this hasn't been a valid use case for quite a long time. But it has nothing to do with Diffie-Hellman key exchanges... -- -- Howard Chu Chief Architect, 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#5036) test034-translucent fails on HEAD
by hyc＠symas.com 03 Jul '07

03 Jul '07

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 >> Submission from: (NULL) (129.240.202.105) >> Submitted by: hallvard >> >> >> test034-translucent fails. Output: > >> Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd >> --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers >> --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null >> --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED >> -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' > > Strange. I got the same result with those options. But with this configuration, > the test works fine: > > --enable-modules --enable-backends=mod --enable-overlays=mod --enable-slapi > --disable-sql > > The test also fails with your options, but without any of the CPPFLAGS set. > Duh... In your test back-monitor is missing. Usually the monitor would be olcDatabase={1} in the config, so the bdb instance would be olcDatabase={2}, and that's the name that's coded into the script. -- -- Howard Chu Chief Architect, 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#5036) test034-translucent fails on HEAD
by hyc＠symas.com 03 Jul '07

03 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth.070703.tgz.1 > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test034-translucent fails. Output: > Configuration: --disable-dynamic --enable-crypt --enable-lmpasswd > --enable-spasswd --enable-rlookups --enable-slapi --enable-wrappers > --disable-backends --enable-bdb --enable-ldap --enable-relay --enable-null > --enable-meta --enable-overlays CC=gcc-4.2.0 'CPPFLAGS=-DLDAP_DEPRECATED > -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' Strange. I got the same result with those options. But with this configuration, the test works fine: --enable-modules --enable-backends=mod --enable-overlays=mod --enable-slapi --disable-sql The test also fails with your options, but without any of the CPPFLAGS set. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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