- openldap-bugs - openldap.org

ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC openldap 2.4.11
by Marius Paulauskas 02 Mar '09

02 Mar '09

Hello, I am trying to change a password for ldap entry using ldappasswd -vx -D "cn=root,dc=test,dc=com" -w foobarr "uid=mariusp,ou=people,dc=test,dc=com" and reply I get is: Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It works fine if it is CLEARTEXT, SHA and MD5. I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in testing meaning there is nothing special about its configuration all defaults. Database has two entries just to play with. Same error occurs if I use downloaded pre-compiled version from sunfreeware.com or compile it myself using gcc. Wondering if anyone experienced similar issue. Regards, /Marius

3 2

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 02 Mar '09

02 Mar '09

Rodrigo Costa wrote: > Howard, > > One more comment. If you take a longer time between the ldapsearches the issue doesn't appear sometimes. > > So you need to start the first ldapsearh and like 15 seconds later start > the second one. With this scenario the problem will for sure appear. I was finally able to reproduce this issue, by running two identical searches simultaneously on a server with more than 2 CPU cores. Given any delay between the two search invocation, the problem did not appear. This is now fixed in HEAD. Thanks for your help in providing data for reproducing the issue. > In this way we will see large chunks of memory being allocated and after > it stabilizes the query get stuck returning as the issue before 16 records per minute, or very slow and getting stuck all the time. I should point out - the memory use is stabilized now (as it should be) but the search performance of a configuration such as yours will be extremely poor due to the unavoidable thrashing that such a query pattern exerts on the cache. Setting a larger minfree can help reduce some of the contention but it will still be much slower than normal. > Regards, > > Rodrigo. -- -- 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

(ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 02 Mar '09

02 Mar '09

Full_Name: Marius Paulauskas Version: 2.4.11 OS: Solaris 10 (SPARC) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.201.141.149) I am trying to change a password for ldap entry using ldappasswd -vx -D "cn=root,dc=test,dc=com" -w foobarr "uid=mariusp,ou=people,dc=test,dc=com" and reply I get is: Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It works fine if it is CLEARTEXT, SHA and MD5. I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in testing meaning there is nothing special about its configuration all defaults. Database has two entries just to play with. Same error occurs if I use downloaded pre-compiled version from sunfreeware.com or compile it myself using gcc.

1 0

Re: (ITS#5981) TLSVerifyClient try setting fails with GnuTLS
by hyc＠symas.com 02 Mar '09

02 Mar '09

peter(a)adpm.de wrote: > Full_Name: Peter Marschall > Version: 2.4.15 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch > Submission from: (NULL) (92.75.56.86) > > > Hi, > > when OpenLDAP 2.4.15 is compiled with GnuTLS, then setting > TLSVerifyClient Try > in slapd.conf makes TLS connections without certificates impossible. > > This is caused by incomplete decoding in tls_g.c > > The patch in ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch > fixes this issue together with a few other little cleanups: > - remove unused variables (less compiler warnings) > - use correct types (less compiler warnings) > - detect failed calls for activation/exiration functions to > avoid giving wrong information > > Please consider adding this patch to OpenLDAP Thanks for the patch, committed to HEAD. > > Regards > Peter > -- -- 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

(ITS#5982) man page for ldapexop
by peter＠adpm.de 01 Mar '09

01 Mar '09

Full_Name: Peter Marschall Version: 2.4.15 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301-ldapexop.1 Submission from: (NULL) (94.217.131.234) Hi, doing a little bug triaging for Debian, I noticed there is not man page for ldapexop. At ftp://ftp.openldap.org/incoming/Peter-Marschall-090301-ldapexop.1 you can find my first draft for it. Please adapt as you please and add it to the next release. Regards Peter

1 0

(ITS#5981) TLSVerifyClient try setting fails with GnuTLS
by peter＠adpm.de 01 Mar '09

01 Mar '09

Full_Name: Peter Marschall Version: 2.4.15 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch Submission from: (NULL) (92.75.56.86) Hi, when OpenLDAP 2.4.15 is compiled with GnuTLS, then setting TLSVerifyClient Try in slapd.conf makes TLS connections without certificates impossible. This is caused by incomplete decoding in tls_g.c The patch in ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch fixes this issue together with a few other little cleanups: - remove unused variables (less compiler warnings) - use correct types (less compiler warnings) - detect failed calls for activation/exiration functions to avoid giving wrong information Please consider adding this patch to OpenLDAP Regards Peter

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 28 Feb '09

28 Feb '09

ando(a)sys-net.it wrote: > Probably a side-effect of fixing ITS#5853: This seems to be unrelated from ITS#5853, actually. Another note: if a search reference is received, it is returned by libldap and additionally it is chased, so one gets both the search reference and the chased search reference results. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 28 Feb '09

28 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, libldap automatically chases any referrals, but at the end returns a response with ld_errno set to 10 and ld_matched set to the portion of DN that was matched in the initial request. This is because the corresponding fields in the parent request are not cleared when the referral is successfully chased. I'm trying to fix this, but it's not clear to me when success should be detected: at successful referral chasing request submission, I guess? p.

1 0

Re: (ITS#5979) ppolicy & access log crashes server
by hyc＠symas.com 28 Feb '09

28 Feb '09

Peter Giesin wrote: > Since the database was corrupted (we were getting a Segmentation Fault > when restarting the server) we simply removed the database. I guess if > we recovered the database instead we would have gotten the same results. Recovery is preformed automatically on startup. Wiping the DB and starting over isn't necessary; if the disks holding the transaction logs don't burn up/fail then corruption simply isn't an issue. > Thanks for the quick fix. You're welcome... > > Pete > > On Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > pgiesin(a)gmail.com <mailto:pgiesin@gmail.com> wrote: > > Full_Name: Peter Giesin > Version: 2.4.13 > OS: Red Hat 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.187.213.234) > > > Enabled both accesslog and ppolicy overlays (configurations > included below). All > attempts to bind with an invalid password causes the server to > crash and > database to be corrupted. If you disable either of the overlays > or just the > "logold" setting of the accesslog the behavior is no longer noticed. > > > Interesting, for me only the first attempt crashed; after restarting > the same attempt just failed normally. Anyway, thanks for the > report, this is now fixed in HEAD. -- -- 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#5979) ppolicy & access log crashes server
by pgiesin＠gmail.com 28 Feb '09

28 Feb '09

--000e0cd4d91a91c2d40463f28568 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Since the database was corrupted (we were getting a Segmentation Fault when restarting the server) we simply removed the database. I guess if we recovered the database instead we would have gotten the same results. Thanks for the quick fix. Pete On Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <hyc(a)symas.com> wrote: > pgiesin(a)gmail.com wrote: > >> Full_Name: Peter Giesin >> Version: 2.4.13 >> OS: Red Hat 5.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.187.213.234) >> >> >> Enabled both accesslog and ppolicy overlays (configurations included >> below). All >> attempts to bind with an invalid password causes the server to crash and >> database to be corrupted. If you disable either of the overlays or just >> the >> "logold" setting of the accesslog the behavior is no longer noticed. >> > > Interesting, for me only the first attempt crashed; after restarting the > same attempt just failed normally. Anyway, thanks for the report, this is > now fixed in HEAD. > > overlay ppolicy >> ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com >> ppolicy_use_lockout TRUE >> ppolicy_hash_cleartext TRUE >> >> overlay accesslog >> logdb cn=log >> logops all >> logold (objectclass=*) >> logpurge 5+00:00 1+00:00 >> logsuccess TRUE >> >> dn: cn=Standard,ou=Policies,dc=amwater,dc=com >> cn: Standard >> description: Standard password policy. >> pwdAttribute: 2.5.4.35 >> pwdMinAge: 60 >> # 30 days: 60 sec * 60 min * 24 hr * 30 days >> pwdMaxAge: 2592000 >> pwdCheckQuality: 1 >> pwdMinLength: 7 >> # Warn three days in advance >> pwdExpireWarning: 259200 >> pwdGraceAuthNLimit: 3 >> pwdLockout: TRUE >> pwdLockoutDuration: 1200 >> pwdMaxFailure: 3 >> pwdFailureCountInterval: 1200 >> pwdMustChange: TRUE >> pwdAllowUserChange: TRUE >> pwdSafeModify: TRUE >> objectclass: device >> objectclass: pwdPolicy >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000e0cd4d91a91c2d40463f28568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since the database was corrupted (we were getting a Segmentation Fault when= restarting the server) we simply removed the database. I guess if we recov= ered the database instead we would have gotten the same results. Thanks for the quick fix. Pete <div class=3D"gmail_quote">On = Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <<a href=3D"= mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote: <blockquote cl= ass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); mar= gin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <a href=3D"mailto:pgiesin@gmail.com" target=3D"_blank">pgiesin(a)gmail.com</a= > wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Peter Giesin Version: 2.4.13 OS: Red Hat 5.2 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (24.187.213.234) Enabled both accesslog and ppolicy overlays (configurations included below)= . All attempts to bind with an invalid password causes the server to crash and<br= > database to be corrupted. If you disable either of the overlays or just the= "logold" setting of the accesslog the behavior is no longer notic= ed. </blockquote> Interesting, for me only the first attempt crashed; after restarting the sa= me attempt just failed normally. Anyway, thanks for the report, this is now= fixed in HEAD. <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> overlay ppolicy ppolicy_default cn=3DStandard,ou=3DPolicies,dc=3Damwater,dc=3Dcom ppolicy_use_lockout TRUE ppolicy_hash_cleartext TRUE overlay accesslog logdb cn=3Dlog logops all logold (objectclass=3D*) logpurge 5+00:00 1+00:00 logsuccess TRUE dn: cn=3DStandard,ou=3DPolicies,dc=3Damwater,dc=3Dcom cn: Standard description: Standard password policy. pwdAttribute: 2.5.4.35 pwdMinAge: 60 # 30 days: 60 sec * 60 min * 24 hr * 30 days pwdMaxAge: 2592000 pwdCheckQuality: 1 pwdMinLength: 7 # Warn three days in advance pwdExpireWarning: 259200 pwdGraceAuthNLimit: 3 pwdLockout: TRUE pwdLockoutDuration: 1200 pwdMaxFailure: 3 pwdFailureCountInterval: 1200 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE objectclass: device objectclass: pwdPolicy </blockquote> -- =C2=A0-- Howard Chu =C2=A0CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --000e0cd4d91a91c2d40463f28568--

1 0

Re: (ITS#5979) ppolicy & access log crashes server
by hyc＠symas.com 28 Feb '09

28 Feb '09

pgiesin(a)gmail.com wrote: > Full_Name: Peter Giesin > Version: 2.4.13 > OS: Red Hat 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.187.213.234) > > > Enabled both accesslog and ppolicy overlays (configurations included below). All > attempts to bind with an invalid password causes the server to crash and > database to be corrupted. If you disable either of the overlays or just the > "logold" setting of the accesslog the behavior is no longer noticed. Interesting, for me only the first attempt crashed; after restarting the same attempt just failed normally. Anyway, thanks for the report, this is now fixed in HEAD. > overlay ppolicy > ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com > ppolicy_use_lockout TRUE > ppolicy_hash_cleartext TRUE > > overlay accesslog > logdb cn=log > logops all > logold (objectclass=*) > logpurge 5+00:00 1+00:00 > logsuccess TRUE > > dn: cn=Standard,ou=Policies,dc=amwater,dc=com > cn: Standard > description: Standard password policy. > pwdAttribute: 2.5.4.35 > pwdMinAge: 60 > # 30 days: 60 sec * 60 min * 24 hr * 30 days > pwdMaxAge: 2592000 > pwdCheckQuality: 1 > pwdMinLength: 7 > # Warn three days in advance > pwdExpireWarning: 259200 > pwdGraceAuthNLimit: 3 > pwdLockout: TRUE > pwdLockoutDuration: 1200 > pwdMaxFailure: 3 > pwdFailureCountInterval: 1200 > pwdMustChange: TRUE > pwdAllowUserChange: TRUE > pwdSafeModify: TRUE > objectclass: device > objectclass: pwdPolicy > > -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 28 Feb '09

28 Feb '09

Name of the tarball posted on ftp.openldap.org : philippe_eychart_openldap_x-dnssrv_20090227.tgz. Content: - file1 : openldap-2.4.13-i486-1.x-dnssrv.open.c.20090227.patch (8918 bytes) - file2 : openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.20090227.patch (5437 bytes) (necessary to patch1 because of the possible empty domain argument option - and, of course, to implement the priority notion ...) Regards

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 28 Feb '09

28 Feb '09

I must be tired !... ;) The good result is ... : "ldap://ldap.gov.pf.:389/o=gov%2cc=pf \ ldap://ldap2.backup.gov.pf.:390/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf.:389/o=gov%2cc=pf" yes!!! -----Message d'origine----- De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf] Envoyé : vendredi 27 février 2009 13:39 À : openldap-its(a)openldap.org Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) Sorry : error in the last warning example !... "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't the dn of a domaine) ... -> give (of course): "ldap://ldap.gov.pf:389/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf:390/o=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf:389/o=gov%2cdc=pf" -- PE

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 28 Feb '09

28 Feb '09

Sorry : error in the last warning example !... "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't the dn of a domaine) ... -> give (of course): "ldap://ldap.gov.pf.:389/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf.:390/o=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/o=gov%2cdc=pf" -- PE

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 27 Feb '09

27 Feb '09

Hi, Here is the description of use of the current version of the "x-dnssrv" extension through some examples: CONTEXT OF EXAMPLE : /etc/resolv.conf: search gov.pf nameserver localhost /var/named/pz/gov.pf: $ORIGIN gov.pf. ... _ldap._tcp IN SRV 0 1 389 ldap IN SRV 1 1 389 ldap1.backup.gov.pf. IN SRV 1 1 390 ldap2.backup.gov.pf. ... and /var/named/pz/backup.gov.pf: $ORIGIN backup.gov.pf. ... _ldap._tcp IN SRV 0 1 389 ldap0 IN SRV 0 1 389 ldap1 ... LDAP URI EXAMPLES FOR THE "x-dnssrv" EXTENSION: For: "ldap:///ou=person,dc=gov,dc=pf??sub??x-dnssrv=dc=gov%2cdc=pf" -> the result URI will be: "ldap://ldap.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \ ldap://ldap1.backup.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \ ldap://ldap2.backup.gov.pf.:390/ou=person,dc=gov,dc=pf??sub" For: "ldap:///????x-dnsSRV=gov.pf." -> the result URI will be: "ldap://ldap.gov.pf.:389 ldap://ldap2.backup.gov.pf.:390 / ldap://ldap1.backup.gov.pf.:389" For: "ldap:///dc=gov%2cdc=pf????x-dnssrv" -> the result URI will be: "ldap://ldap.gov.pf.:389/dc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:389/dc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:390/dc=gov%2cdc=pf" For: "ldap://gov.pf.:389/????x-dnssrv" -> the result URI will be: "ldap://ldap.gov.pf.:389 ldap://ldap1.backup.gov.pf.:389" For: "ldap:///????x-dnssrv[,extension]*" -> because of resolv.conf, the result URI will be: "ldap://ldap.gov.pf.:389/????[extension[,extension]*]* \ ldap://ldap1.backup.gov.pf.:389/????[extension[,extension]*]* \ ldap://ldap2.backup.gov.pf.:390/????[extension[,extension]*]*" WARNING: "ldap://goov.pf./????x-dnssrv" -> give: "" "ldap://gov.pf./????x-dnssrv,x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" -> give: "ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" "ldap:///dc=gov%2cdc=pf???sub?x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" -> give: "ldap://ldap0.backup.gov.pf.:389/dc=gov,dc=pf???sub \ ldap://ldap1.backup.gov.pf.:389/dc=gov,dc=pf???sub" "ldap://ldap.gov.pf/dc=backup%2cdc=gov%2cdc=pf????x-dnssrv" -> give: "ldap://ldap.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/dc=backup%2cdc=gov%2cdc=pf" "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of default the domain research ... -> give: "ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" SYNTAX ERROR (the resultant URI will remain unchanged): "ldap://ldap.gov.pf/dc=gov%2cdc=pf????x-dnssrv=dc=gov%2cdc=pf" "ldap://ldap.gov.pf/????x-dnssrv=dc=gov%2cdc=pf" "ldap://ldap.gov.pf/????x-dnssrv=gov.pf." "ldap://dc=gov%2cdc=pf/????x-dnssrv" "ldap://gov.pf[/[?[?[?[?]]]]]" etc ... I proceed in the last check of sources and I post patchs (open.c & dnssrv.c) ... -- PE

1 0

(ITS#5979) ppolicy & access log crashes server
by pgiesin＠gmail.com 27 Feb '09

27 Feb '09

Full_Name: Peter Giesin Version: 2.4.13 OS: Red Hat 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.187.213.234) Enabled both accesslog and ppolicy overlays (configurations included below). All attempts to bind with an invalid password causes the server to crash and database to be corrupted. If you disable either of the overlays or just the "logold" setting of the accesslog the behavior is no longer noticed. overlay ppolicy ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com ppolicy_use_lockout TRUE ppolicy_hash_cleartext TRUE overlay accesslog logdb cn=log logops all logold (objectclass=*) logpurge 5+00:00 1+00:00 logsuccess TRUE dn: cn=Standard,ou=Policies,dc=amwater,dc=com cn: Standard description: Standard password policy. pwdAttribute: 2.5.4.35 pwdMinAge: 60 # 30 days: 60 sec * 60 min * 24 hr * 30 days pwdMaxAge: 2592000 pwdCheckQuality: 1 pwdMinLength: 7 # Warn three days in advance pwdExpireWarning: 259200 pwdGraceAuthNLimit: 3 pwdLockout: TRUE pwdLockoutDuration: 1200 pwdMaxFailure: 3 pwdFailureCountInterval: 1200 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE objectclass: device objectclass: pwdPolicy

1 0

Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 27 Feb '09

27 Feb '09

On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote: > Andrew: > > One suggestion following a very quick scan of the code: I think it > > would be worth bringing the warning about turning off TLS checks > > into the manual page. > > Agreed. Done. > > > In particular, there is no reason for this > > to be AD-specific and it should be easy to adapt it to authenticate > > against any [collection of] remote LDAP servers. > > Actually, it may not be AD specific as is. Are we any further forward to getting this rolled into contrib? Is there more we need to do to make it fit better? The tarball has been sitting there a while, it would seem. Cheers, Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#5978) Addition to syncrepl Documentation in Administrater's Guide
by hyc＠symas.com 27 Feb '09

27 Feb '09

imjustmatthew(a)gmail.com wrote: > Full_Name: Matthew Roy > Version: 2.4.9 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.94.128.99) > > > In the Administrater's Guide, Section 18.3.1.3 > (http://www.openldap.org/doc/admin24/replication.html) there is no mention of > needing to explicitly load the "syncprov" module with a loadmodule directive. It > is mentioned when talking about Delta-syncrepl in 18.3.2, but is not previously > in 18.3.1 when setting up "plain" syncrepl between servers. Modules are an optional part of the configuration. You're expected to know that you need to use loadmodule if you configured module support. > > Simply adding it to the example server configuration so new users realize that > this module may need to be loaded would be sufficient. Otherwise, we try the > sample code and the testing server won't start and needs to be debugged. Sure > it's not a big deal, but first experiences should be as positive as possible. > -- -- 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

"error in SSLv3 flush data" when connecting from network again!
by Lifeng Wang 27 Feb '09

27 Feb '09

Hi All, After many googling, I find one thread in openldap mailing list year 2007, Feb to March about this issue, but no solution, and now it happened to me again. So I'm write to this mailing list to report this bug. I'm running openldap 2.3.27 on CentOS 5.2 x86_64. I configured TLS on the server, and localhost successfully connected to 389 port with start_tls. However when I try to connect to this ldap server with start_tls from a Fedora 10 x86_64 client, it hangs. As previous reported, if I launch slapd with -d2, remote client can connect to the server with TLS. by using -d1 on both server and client, server hangs at some where: TLS trace: SSL_accept:error in SSLv3 write certificate request B and client hangs at TLS trace: SSL_accept:SSLv3 read certificate A So, I rung -d2 on client, and find: tls_read: want=179, got=179 ... tls_read: want=5, got=5 ... tls_read: want=14771, got=9952 ... So, the last seconds shows client expecting 14771 bytes of data, but server only send 9952 bytes, so client thinking server will send more, but server get error? if I run same ldapsearch command from server (localhost), that line read as: tls_read: want=14771, got=14771 Does this ring the bell? Thanks Noodle

1 0

(ITS#5978) Addition to syncrepl Documentation in Administrater's Guide
by imjustmatthew＠gmail.com 27 Feb '09

27 Feb '09

Full_Name: Matthew Roy Version: 2.4.9 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.94.128.99) In the Administrater's Guide, Section 18.3.1.3 (http://www.openldap.org/doc/admin24/replication.html) there is no mention of needing to explicitly load the "syncprov" module with a loadmodule directive. It is mentioned when talking about Delta-syncrepl in 18.3.2, but is not previously in 18.3.1 when setting up "plain" syncrepl between servers. Simply adding it to the example server configuration so new users realize that this module may need to be loaded would be sufficient. Otherwise, we try the sample code and the testing server won't start and needs to be debugged. Sure it's not a big deal, but first experiences should be as positive as possible.

1 0

Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by ando＠sys-net.it 27 Feb '09

27 Feb '09

hyc(a)symas.com wrote: > Fixed now in HEAD for -ldap and -meta; it only checks for duplicates on > attributes that were configured for sorting. I suppose a config option to > check all attrs may be useful, but for now it seems unnecessary. OK, I was working on a fix that always eliminated duplicates, but yours is saving the effort when not strictly needed. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by hyc＠symas.com 27 Feb '09

27 Feb '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> mhardin(a)symas.com wrote: >>> Full_Name: Matthew Hardin >>> Version: 2.4.14 >>> OS: RHEL4 x86 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.44.226.116) >>> >>> >>> Given an Active Directory group object containing the following two members: >>> >>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >>> >>> and >>> >>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >>> >>> (note the extra space between "Frank" and "Y" in the second member) >>> >>> Active Directory sees these as different entries and allows them to both be >>> members of the same group. Back-LDAP and back-meta happily return both of these >>> values. >> I'd expect slapd-ldap to return two identical values, since value >> prettification also eliminates multiple spaces in directoryString values. > > Right. It's strange that the value with two spaces was preserved. Never mind, cn is DirectoryString and has no pretty function. > >>> When 'sortvals member' is turned on, the pcache overlay will cache this value >>> but will not return it on subsequent searches because it sees these two values >>> as duplicates. According to Howard Chu, this is because the equality matching >>> rule for the 'member' attribute collapses multiple spaces into one before doing >>> the comparison and so reports these two values as duplicates. >>> >>> Howard asked me to file this ITS as a means to solicit guidance from others as >>> to the best way/place to fix this. >> After value normalization, slapd-ldap I think should also check for >> duplicates (possibly leaving this as an option), and discard them. In >> fact, it is the proxy backend that injects broken data into the loop. Fixed now in HEAD for -ldap and -meta; it only checks for duplicates on attributes that were configured for sorting. I suppose a config option to check all attrs may be useful, but for now it seems unnecessary. >> Of course, the best solution in your case would probably be to fix your >> data... :) > > Agreed on all points... -- -- 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#5977) pcache and broken Active Directory equality matching rules
by hyc＠symas.com 27 Feb '09

27 Feb '09

ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.14 >> OS: RHEL4 x86 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.44.226.116) >> >> >> Given an Active Directory group object containing the following two members: >> >> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >> >> and >> >> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >> >> (note the extra space between "Frank" and "Y" in the second member) >> >> Active Directory sees these as different entries and allows them to both be >> members of the same group. Back-LDAP and back-meta happily return both of these >> values. > > I'd expect slapd-ldap to return two identical values, since value > prettification also eliminates multiple spaces in directoryString values. Right. It's strange that the value with two spaces was preserved. >> When 'sortvals member' is turned on, the pcache overlay will cache this value >> but will not return it on subsequent searches because it sees these two values >> as duplicates. According to Howard Chu, this is because the equality matching >> rule for the 'member' attribute collapses multiple spaces into one before doing >> the comparison and so reports these two values as duplicates. >> >> Howard asked me to file this ITS as a means to solicit guidance from others as >> to the best way/place to fix this. > > After value normalization, slapd-ldap I think should also check for > duplicates (possibly leaving this as an option), and discard them. In > fact, it is the proxy backend that injects broken data into the loop. > > Of course, the best solution in your case would probably be to fix your > data... :) Agreed on all points... -- -- 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#5977) pcache and broken Active Directory equality matching rules
by ando＠sys-net.it 27 Feb '09

27 Feb '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.14 > OS: RHEL4 x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.44.226.116) > > > Given an Active Directory group object containing the following two members: > > member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User > Accounts,ou=Common,dc=ad,dc=foobar,dc=com > > and > > member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User > Accounts,ou=Common,dc=ad,dc=foobar,dc=com > > (note the extra space between "Frank" and "Y" in the second member) > > Active Directory sees these as different entries and allows them to both be > members of the same group. Back-LDAP and back-meta happily return both of these > values. I'd expect slapd-ldap to return two identical values, since value prettification also eliminates multiple spaces in directoryString values. > When 'sortvals member' is turned on, the pcache overlay will cache this value > but will not return it on subsequent searches because it sees these two values > as duplicates. According to Howard Chu, this is because the equality matching > rule for the 'member' attribute collapses multiple spaces into one before doing > the comparison and so reports these two values as duplicates. > > Howard asked me to file this ITS as a means to solicit guidance from others as > to the best way/place to fix this. After value normalization, slapd-ldap I think should also check for duplicates (possibly leaving this as an option), and discard them. In fact, it is the proxy backend that injects broken data into the loop. Of course, the best solution in your case would probably be to fix your data... :) 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5977) pcache and broken Active Directory equality matching rules
by mhardin＠symas.com 26 Feb '09

26 Feb '09

Full_Name: Matthew Hardin Version: 2.4.14 OS: RHEL4 x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.44.226.116) Given an Active Directory group object containing the following two members: member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User Accounts,ou=Common,dc=ad,dc=foobar,dc=com and member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User Accounts,ou=Common,dc=ad,dc=foobar,dc=com (note the extra space between "Frank" and "Y" in the second member) Active Directory sees these as different entries and allows them to both be members of the same group. Back-LDAP and back-meta happily return both of these values. When 'sortvals member' is turned on, the pcache overlay will cache this value but will not return it on subsequent searches because it sees these two values as duplicates. According to Howard Chu, this is because the equality matching rule for the 'member' attribute collapses multiple spaces into one before doing the comparison and so reports these two values as duplicates. Howard asked me to file this ITS as a means to solicit guidance from others as to the best way/place to fix this. Comments? -Matt

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no 26 Feb '09

26 Feb '09

ando(a)sys-net.it writes: > Correct. However I'm not sure whether the man page or the code needs to > be fixed. I'm open to suggestions. I'm inclined towards following the > man page, as the use of -d implies one may not need the pid, and knows > the args. It _may_ mean that. But the existence of the pidfile also means one need not save the pid after running slapd &. So I think it's best to keep the existing behavior, in case someone depends on the pidfile. -- Hallvard

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by aej＠WPI.EDU 25 Feb '09

25 Feb '09

>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: hyc> aej(a)wpi.edu wrote: >> Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: >> Submission from: (NULL) (130.215.36.68) >> >> >> I somehow missed installing 2.1.14, and was still running 2.1.13. I found >> that 2.1.15 did not run on one of my servers (but worked on the other 2). >> Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked >> again on that same client still worked ok, so it doesn't appear that >> libraries went sour. The failure is on a gssapi syncrepl client on an >> opteron. The gssapi syncrepl client on Intel works ok. The master appears >> to work ok, too. The ldap server was running on appliance4 and was >> accessing the master on appliance1. >> >> When starting it under debugging -d-1, I got to this: hyc> I presume you meant 2.4.15, not 2.1.15. Thanks for the report, fixed now hyc> in HEAD. Yes, 2.4, once I typed one wrong, I copied my mistake again and again.

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by aej＠WPI.EDU 25 Feb '09

25 Feb '09

>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes: quanah> --On Wednesday, February 25, 2009 8:24 PM +0000 aej(a)wpi.edu wrote: >> Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: >> Submission from: (NULL) (130.215.36.68) >> >> >> I somehow missed installing 2.1.14, and was still running 2.1.13. I found >> that 2.1.15 did not run on one of my servers (but worked on the other 2). >> Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked >> again on that same client still worked ok, so it doesn't appear that >> libraries went sour. The failure is on a gssapi syncrepl client on an >> opteron. The gssapi syncrepl client on Intel works ok. The master appears >> to work ok, too. The ldap server was running on appliance4 and was >> accessing the master on appliance1. quanah> OpenLDAP 2.1? That's years ancient, and no longer supported. Use a quanah> modern supported release. Well, there are a bunch of typos. It's 2.4 in all cases. I meant the 2.4.15 that was announced recently. I'd not installed 2.4.14, but that exhibits the same problem.

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by hyc＠symas.com 25 Feb '09

25 Feb '09

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.1.15 > OS: Red Hat Linux E5 > URL: > Submission from: (NULL) (130.215.36.68) > > > I somehow missed installing 2.1.14, and was still running 2.1.13. I found that > 2.1.15 did not run on one of my servers (but worked on the other 2). Looking > back, 2.1.14 had the same problem. 2.1.13, compiled and linked again on that > same client still worked ok, so it doesn't appear that libraries went sour. The > failure is on a gssapi syncrepl client on an opteron. The gssapi syncrepl > client on Intel works ok. The master appears to work ok, too. The ldap server > was running on appliance4 and was accessing the master on appliance1. > > When starting it under debugging -d-1, I got to this: I presume you meant 2.4.15, not 2.1.15. Thanks for the report, fixed now in HEAD. -- -- 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#5976) seg fault problem starting with version 2.1.14
by quanah＠zimbra.com 25 Feb '09

25 Feb '09

--On Wednesday, February 25, 2009 8:24 PM +0000 aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.1.15 > OS: Red Hat Linux E5 > URL: > Submission from: (NULL) (130.215.36.68) > > > I somehow missed installing 2.1.14, and was still running 2.1.13. I > found that 2.1.15 did not run on one of my servers (but worked on the > other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled > and linked again on that same client still worked ok, so it doesn't > appear that libraries went sour. The failure is on a gssapi syncrepl > client on an opteron. The gssapi syncrepl client on Intel works ok. The > master appears to work ok, too. The ldap server was running on > appliance4 and was accessing the master on appliance1. OpenLDAP 2.1? That's years ancient, and no longer supported. Use a modern supported release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5976) seg fault problem starting with version 2.1.14
by aej＠wpi.edu 25 Feb '09

25 Feb '09

Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: Submission from: (NULL) (130.215.36.68) I somehow missed installing 2.1.14, and was still running 2.1.13. I found that 2.1.15 did not run on one of my servers (but worked on the other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked again on that same client still worked ok, so it doesn't appear that libraries went sour. The failure is on a gssapi syncrepl client on an opteron. The gssapi syncrepl client on Intel works ok. The master appears to work ok, too. The ldap server was running on appliance4 and was accessing the master on appliance1. When starting it under debugging -d-1, I got to this: ldap_sasl_interactive_bind_s: user selected: gssapi ldap_int_sasl_bind: gssapi ldap_int_sasl_open: host=appliance1.wpi.edu Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x43377940 (LWP 21161)] ber_get_tag (ber=0x433762c0) at decode.c:110 110 tag = *(unsigned char *)ber->ber_ptr; (gdb) where #0 ber_get_tag (ber=0x433762c0) at decode.c:110 #1 0x0000000000506bdb in ber_skip_tag (ber=0x433762c0, len=0x433763f8) at decode.c:169 #2 0x0000000000507653 in ber_peek_tag (ber=0x433762c0, len=0x433763f8) at decode.c:228 #3 0x0000000000502794 in ldap_X509dn2bv (x509_name=<value optimized out>, bv=0x43376520, func=0, flags=0) at tls2.c:1016 #4 0x0000000000502e6b in ldap_pvt_tls_get_my_dn (s=<value optimized out>, dn=0x43376520, func=0, flags=0) at tls2.c:876 #5 0x00000000004ebd8f in ldap_int_sasl_bind (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", sctrls=0x0, cctrls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at cyrus.c:479 #6 0x00000000004ed41c in ldap_sasl_interactive_bind_s (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", serverControls=0x0, clientControls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at sasl.c:464 #7 0x000000000041584b in slap_client_connect (ldp=0x1699d120, sb=0x1699cf20) at config.c:1764 #8 0x0000000000479dfa in do_syncrepl (ctx=0x43376d70, arg=<value optimized out>) at syncrepl.c:560 #9 0x00000000004e588a in ldap_int_thread_pool_wrapper (xpool=0x1693a410) at tpool.c:663 #10 0x0000003dedc06367 in start_thread () from /lib64/libpthread.so.0 #11 0x0000003ded0d30ad in clone () from /lib64/libc.so.6

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by ando＠sys-net.it 25 Feb '09

25 Feb '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to make > any difference whether or not you use the -d option with slapd. > > This phrasing could be replaced with something that indicates if it is not > specified, the file will not be created. Correct. However I'm not sure whether the man page or the code needs to be fixed. I'm open to suggestions. I'm inclined towards following the man page, as the use of -d implies one may not need the pid, and knows the args. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 25 Feb '09

25 Feb '09

On Feb 25, 2009, at 1:42 AM, hyc(a)symas.com wrote: > The -compat code is LGPL. I'm considering copying the ciphersuite > handling and > a few other pieces out of there, directly into our tree. There's a > lot of > other baggage in the compat library we don't need, and there's some > OpenSSL > emulation that would interfere with the NSS code we already have. > Any problem > with excerpting the bits we need? I would need to take a very careful look at this. In general, the answer is "NO", don't bring in LGPL code into our primary code base (standalone LGPL in contrib is another matter). -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 25 Feb '09

25 Feb '09

hyc(a)symas.com wrote: > Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code > in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency > as well. That's a key requirement to me personally, because otherwise it will > not interoperate with Mozilla/Seamonkey, and right now that's my primary goal > for this work. The -compat code is LGPL. I'm considering copying the ciphersuite handling and a few other pieces out of there, directly into our tree. There's a lot of other baggage in the compat library we don't need, and there's some OpenSSL emulation that would interfere with the NSS code we already have. Any problem with excerpting the bits we need? > It's been a few months since I last looked at this and it took me a while to > remember all the issues surrounding it... > > There are two major problems with the current MozNSS support in HEAD: > 1) It does no initialization of its own. This works with Seamonkey/Thunderbird > because the main app has already initialized the NSS library; libldap just > uses the state that's already there. Code to initialize properly when NSS > hasn't already been initialized still needs to be written. > 2) It cannot shutdown safely. This is a weakness in the NSS API that was > discussed at length in the Mozilla newsgroups. Unfortunately that discussion > went nowhere. (The NSS_Shutdown() function tears down the library > unconditionally; if there were multiple callers of the library and one of them > shuts down because it's going away, all of the other callers lose the library > too.) It appears that not much progress has been made on the latter problem. Here's a relevant wiki http://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Unfortunately this aspect of NSS is still too broken for it to be used safely in libldap, when other apps also use NSS directly. There's still no technical advantage to using this over OpenSSL, and there's still a significant usability/app-safety disadvantage to adopting it. (GnuTLS at least offers TLS1.2 support, which neither OpenSSL or MozNSS do yet. Both OpenSSL and MozNSS have FIPS-140 validations, but FIPS mode is incompatible with the way most existing software uses these libraries, so it's kind of a moot point.) -- -- 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

(ITS#5975) minor issue with slapd.conf manpage
by eric＠huss.org 25 Feb '09

25 Feb '09

Full_Name: Eric Huss Version: 2.4.15 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.81.244.185) There appears to be a couple slightly incorrect statements in the slapd.conf manpage. It says that the argsfile and pidfile values are used "if started without the debugging command line option". However, it doesn't appear to make any difference whether or not you use the -d option with slapd. This phrasing could be replaced with something that indicates if it is not specified, the file will not be created.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: >> Perhaps a better question is - how would you like it to work? > I prefer that we leave the builder with as freedom as possible. Right, that makes the most sense. >> I'm assuming there must be some way specify which crypto you want to >> build >> openldap with - is that a configure option? > > Presently there is: > --with-tls=[auto,openssl,gnutls] > > I assume we'd just add an 'nss' option to the above. However, Howard > might have other things in mind. Yes (but the option will be "moznss"). >>>> Note >>>> that both NSPR and NSS support pkg-config >>> Here would be to ensure that the proper pkg-config is in the PATH. >>> >>> Of course, pkg-config stuff gets stuff into the environment in some >>> fixed order, which does take away some freedom from the builder. I >>> guess the builder can always manually adjust the order (by providing >>> CPPFLAGS, etc., directly) and then provide a pkg_config which does >>> little. So the freedom is there, just harder to take advantage of. >> The original patch - >> ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - >> assumes the use of pkg-config - I suppose that is not sufficient. > > My only concern would be whether or not pkg-config use here is > specific to a particular 3rd party packaging of NSS versus something > available with all installs of NSS. I currently build against a copy of NSS in my Mozilla build tree. There's nothing installed with pkg-config. I would like to avoid a dependency on pkg-config. Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency as well. That's a key requirement to me personally, because otherwise it will not interoperate with Mozilla/Seamonkey, and right now that's my primary goal for this work. It's been a few months since I last looked at this and it took me a while to remember all the issues surrounding it... There are two major problems with the current MozNSS support in HEAD: 1) It does no initialization of its own. This works with Seamonkey/Thunderbird because the main app has already initialized the NSS library; libldap just uses the state that's already there. Code to initialize properly when NSS hasn't already been initialized still needs to be written. 2) It cannot shutdown safely. This is a weakness in the NSS API that was discussed at length in the Mozilla newsgroups. Unfortunately that discussion went nowhere. (The NSS_Shutdown() function tears down the library unconditionally; if there were multiple callers of the library and one of them shuts down because it's going away, all of the other callers lose the library too.) Another problem I've had in integrating is that the documentation is out of date with the code - the docs recommend certain APIs and practices that are actually deprecated in the actual code. This has led down a lot of blind alleys/dead ends that could otherwise have been avoided... > I'll be leaving the actual technical review of your patch to Howard or > other active committers. -- -- 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#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: > Kurt Zeilenga wrote: >> >> On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: >> >>> Kurt(a)OpenLDAP.org wrote: >>>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>>> >>>> >>>>> I'm still uncertain about how configure should detect the NSS >>>>> header >>>>> files >>>>> though; they are not in any standardized location yet AFAICS. >>>>> >>>> >>>> Like with other things, I would assume the environment to be >>>> adjusted >>>> to find the right NSS prior to running configure. >>>> >>> I'm not sure I understand what you mean by "environment to be >>> adjusted" >> >> CPPFLAGS, CFLAGS, ... and PATH environmental variables. >> >>> >>> - How does openldap detect the header files for other components? >> >> autoconf is used, which uses the compiler to check if necessary >> headers are there, with the (additional to those built into the >> compiler) header path specified via CPPFLAGS. >> >> The idea here is to give the builder the freedom over which header >> directories are searched, and the order in which they are searched. > What's the usual way that openldap does this for packages installed in > non-standard locations e.g. if I want to have my own private build of > cyrus-sasl? Is it up to the user to specify > CPPFLAGS=-I/path/to/nonstd/sasl/include and > LDFLAGS=-L/path/to/nonstd/lib ? Yes. > Does openldap configure have a > --with-sasl=/path/to/nonstd/sasl option? No. Because CPPFLAGS and LDFLAGS mechanism exists and provides more control to the builder. > > > Perhaps a better question is - how would you like it to work? I prefer that we leave the builder with as freedom as possible. > I'm assuming there must be some way specify which crypto you want to > build > openldap with - is that a configure option? Presently there is: --with-tls=[auto,openssl,gnutls] I assume we'd just add an 'nss' option to the above. However, Howard might have other things in mind. > >> >>> Note >>> that both NSPR and NSS support pkg-config >> >> Here would be to ensure that the proper pkg-config is in the PATH. >> >> Of course, pkg-config stuff gets stuff into the environment in some >> fixed order, which does take away some freedom from the builder. I >> guess the builder can always manually adjust the order (by providing >> CPPFLAGS, etc., directly) and then provide a pkg_config which does >> little. So the freedom is there, just harder to take advantage of. > The original patch - > ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - > assumes the use of pkg-config - I suppose that is not sufficient. My only concern would be whether or not pkg-config use here is specific to a particular 3rd party packaging of NSS versus something available with all installs of NSS. I'll be leaving the actual technical review of your patch to Howard or other active committers. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt Zeilenga wrote: > > On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>> >>> >>>> I'm still uncertain about how configure should detect the NSS header >>>> files >>>> though; they are not in any standardized location yet AFAICS. >>>> >>> >>> Like with other things, I would assume the environment to be adjusted >>> to find the right NSS prior to running configure. >>> >> I'm not sure I understand what you mean by "environment to be adjusted" > > CPPFLAGS, CFLAGS, ... and PATH environmental variables. > >> >> - How does openldap detect the header files for other components? > > autoconf is used, which uses the compiler to check if necessary > headers are there, with the (additional to those built into the > compiler) header path specified via CPPFLAGS. > > The idea here is to give the builder the freedom over which header > directories are searched, and the order in which they are searched. What's the usual way that openldap does this for packages installed in non-standard locations e.g. if I want to have my own private build of cyrus-sasl? Is it up to the user to specify CPPFLAGS=-I/path/to/nonstd/sasl/include and LDFLAGS=-L/path/to/nonstd/lib ? Does openldap configure have a --with-sasl=/path/to/nonstd/sasl option? Perhaps a better question is - how would you like it to work? I'm assuming there must be some way specify which crypto you want to build openldap with - is that a configure option? > >> Note >> that both NSPR and NSS support pkg-config > > Here would be to ensure that the proper pkg-config is in the PATH. > > Of course, pkg-config stuff gets stuff into the environment in some > fixed order, which does take away some freedom from the builder. I > guess the builder can always manually adjust the order (by providing > CPPFLAGS, etc., directly) and then provide a pkg_config which does > little. So the freedom is there, just harder to take advantage of. The original patch - ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - assumes the use of pkg-config - I suppose that is not sufficient. > > -- Kurt > >

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > Kurt(a)OpenLDAP.org wrote: >> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >> >> >>> I'm still uncertain about how configure should detect the NSS header >>> files >>> though; they are not in any standardized location yet AFAICS. >>> >> >> Like with other things, I would assume the environment to be adjusted >> to find the right NSS prior to running configure. >> > I'm not sure I understand what you mean by "environment to be > adjusted" CPPFLAGS, CFLAGS, ... and PATH environmental variables. > > - How does openldap detect the header files for other components? autoconf is used, which uses the compiler to check if necessary headers are there, with the (additional to those built into the compiler) header path specified via CPPFLAGS. The idea here is to give the builder the freedom over which header directories are searched, and the order in which they are searched. > Note > that both NSPR and NSS support pkg-config Here would be to ensure that the proper pkg-config is in the PATH. Of course, pkg-config stuff gets stuff into the environment in some fixed order, which does take away some freedom from the builder. I guess the builder can always manually adjust the order (by providing CPPFLAGS, etc., directly) and then provide a pkg_config which does little. So the freedom is there, just harder to take advantage of. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: > > >> I'm still uncertain about how configure should detect the NSS header >> files >> though; they are not in any standardized location yet AFAICS. >> > > Like with other things, I would assume the environment to be adjusted > to find the right NSS prior to running configure. > I'm not sure I understand what you mean by "environment to be adjusted" - How does openldap detect the header files for other components? Note that both NSPR and NSS support pkg-config > -- Kurt > > > > >

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by hyc＠symas.com 24 Feb '09

24 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > Wait for 2.5 to break binary compatibility. If a function is there and > is useful, people will dig it out and use it. Agreed. But we can probably fix slapd's use of ldap_int APIs. > Just like back-bdb used > (uses?) some internal Berkeley DB locking function. (Not any more...) -- -- 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#5974) libldap not consistently using namespaces
by ando＠sys-net.it 24 Feb '09

24 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > > Wait for 2.5 to break binary compatibility. Sure, no hurry. I'm just getting a bit confused when digging into very nested libldap stuff... > If a function is there and > is useful, people will dig it out and use it. That's probably my last concern, though :) 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by h.b.furuseth＠usit.uio.no 24 Feb '09

24 Feb '09

ando(a)sys-net.it writes: > Since all those functions are not meant to be exposed, I guess fixing > the (mis)use of the ldap namespace should not create issues. Wait for 2.5 to break binary compatibility. If a function is there and is useful, people will dig it out and use it. Just like back-bdb used (uses?) some internal Berkeley DB locking function. -- Hallvard

1 0

(ITS#5974) libldap not consistently using namespaces
by ando＠sys-net.it 24 Feb '09

24 Feb '09

Full_Name: Pierangelo Masarati Version: any OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There are quite a few local functions with no namespace (e.g. re_encode_request()), but what seems to be mostly incorrect is ldap namespace pollution (e.g. ldap_chase_v3referrals()). Finally, there are quite a few occurrences of ldap_int_tls_config() used outside libldap (in slapd). Since all those functions are not meant to be exposed, I guess fixing the (mis)use of the ldap namespace should not create issues. p.

1 0

(ITS#5973) Syncrepl can update more than one csn value
by rein＠OpenLDAP.org 24 Feb '09

24 Feb '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl can update more than one csn value in one operation, but only one can be passed to syncprov in the csn queue. Syncprov should instead pick the updated values from the modify operation. A patch that fixes this is coming. This patch depends on the ITS#5972 patch, and is required for the new test058 to succeed. Rein Tollevik Basefarm AS

1 0

(ITS#5972) Send newCookie sync info messages
by rein＠OpenLDAP.org 24 Feb '09

24 Feb '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein When syncprov updates its local contextCSN value after some modification took place this update will not be propagated to consumers that doesn't receive the updated entry (it could fail to match the filter, or access control could prevent it). In this case, the consumer will have an old contextCSN value although its content is up to date. The provider should in this case send a newcookie sync info message to the consumer with its updated contextCSN value. A patch that implements this is coming. This patch is required for the new test058 to succeed. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by quanah＠zimbra.com 24 Feb '09

24 Feb '09

--On Tuesday, February 24, 2009 11:11 AM +0100 Adrien Futschik <adrien.futschik(a)atosorigin.com> wrote: > I confirme that it was a problem with OpenLDAP 2.4.14, it now works fine > with OpenLDAP 2.4.15. > > I guess this ITS is a "duplicate" of ITS#5955 That would seem to indicate that your various settings you pass on to configure are incorrect in some manner then, since the changes made only affect builds of OpenLDAP that would be compiled against GnuTLS, not OpenSSL. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by adrien.futschik＠atosorigin.com 24 Feb '09

24 Feb '09

Le lundi 23 février 2009 09:25:39, Adrien Futschik a écrit : > The same build instructions and the same product versions are working just > fine on RHEL 5 64bits ! > > I still believe this is a bug with OpenLDAP 2.4.14. > > Adrien I confirme that it was a problem with OpenLDAP 2.4.14, it now works fine with OpenLDAP 2.4.15. I guess this ITS is a "duplicate" of ITS#5955 Best regards, Adrien

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: > I'm still uncertain about how configure should detect the NSS header > files > though; they are not in any standardized location yet AFAICS. Like with other things, I would assume the environment to be adjusted to find the right NSS prior to running configure. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 24 Feb '09

24 Feb '09

rmeggins(a)redhat.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms090802080307060909050508 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Any update on this? It looks as though there is some rearchitecture > work ongoing to make it easier to support openssl, gnutls, and moznss - > what's the status of this work? Would some additional resources be of > any assistance? Thanks for the offer. It was just a matter of timing, I wanted to make sure the new organization was stable before completing the moznss integration. Now that it looks like we've shaken out the loose ends, it won't take long to pull in the rest of the moznss support. I'm still uncertain about how configure should detect the NSS header files though; they are not in any standardized location yet AFAICS. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs