openldap-bugs

openldap-bugs@openldap.org

1 participants
21517 discussions

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

27 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 27 Feb '09

27 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 27 Feb '09

27 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 27 Feb '09

27 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 27 Feb '09

27 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 26 Feb '09

26 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 26 Feb '09

26 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs