openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Solaris Client
by daniel perez del campo 10 Jul '07

10 Jul '07

Hi, I have configurated openLdap in Debian, and it works well with Linux clients. But I want to authenticate a Solaris client against the Ldap server. I don't know how to do this. Could someone tell me what have I have to do?? Or some guide? I have looked for information in Google and I don't find anything clear. Thanks a lot, and sorry for my english. Dani _________________________________________________________________ Grandes éxitos, superhéroes, imitaciones, cine y TV... http://es.msn.kiwee.com/ Lo mejor para tu móvil.

3 2

Re: imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 07 Jul '07

07 Jul '07

Gavin Henry <ghenry(a)suretecsystems.com> wrote: > It would be best to move this dicussion to openldap-devel(a)openldap.org now. Let's go... Summarry: I've added a new feature to slapo-constraint for constraining a value attribute the the existing values of another attribute. The idea is that you can have a catalog of allowed values (eg: for titles: Mr, Mrs, Miss) and constraint an attribute to these values Before working further on this patch (style, dod), I'd like some feeback on: 1) the way it's implemented: is there rought bugs, or is the logic fine? 2) configuration syntax: do we keep this one or do we swtich to something else? Could someone comment on the patch? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by ghenry＠suretecsystems.com 07 Jul '07

07 Jul '07

<quote who="manu(a)netbsd.org"> >> Did you see http://www.openldap.org/devel/contributing.html > > Right, but before moving foward with appropriate style, documentation, > and so on, I'd like to have some input about the config syntax and the > way it's implemented. I had no feedback at all yet on that. It would be best to move this dicussion to openldap-devel(a)openldap.org now. Try raising a question again there. Gavin. > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > manu(a)netbsd.org > > >

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 07 Jul '07

07 Jul '07

> Did you see http://www.openldap.org/devel/contributing.html Right, but before moving foward with appropriate style, documentation, and so on, I'd like to have some input about the config syntax and the way it's implemented. I had no feedback at all yet on that. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

start_tls while chasing referrals
by Bin Lu 06 Jul '07

06 Jul '07

Hi, I noticed the following bug fix in referral chasing http://bugzilla.padl.com/show_bug.cgi?id=210 This seems only to take care of the usage with pam ldap lib. What if the ldap connection is not from the pam lib? In that case, when an ldap operation reaches a referral point, would the new connection be consistent if the original connection is using TLS(and the referral url is not using ldaps)? Our test shows it is not. Please advice, if that is also a security hole? Regards, Wenwu

2 1

Re: (ITS#5041) ldapwhoami takes unused "user" arg
by ando＠sys-net.it 06 Jul '07

06 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > ldapwhoami and "ldapexop whoami" take an unused command line > argument "user". The code has been there since rev 1.1. could be a leftover or something like that? In any case, just trimmed. 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

(ITS#5041) ldapwhoami takes unused "user" arg
by h.b.furuseth＠usit.uio.no 05 Jul '07

05 Jul '07

Full_Name: Hallvard B Furuseth Version: 1.1->current OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldapwhoami and "ldapexop whoami" take an unused command line argument "user". The code has been there since rev 1.1.

1 0

(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 05 Jul '07

05 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 05 Jul '07

05 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

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