openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by clem.oudot＠gmail.com 18 Dec '13

18 Dec '13

--089e0160b79ae9bb0c04edcfeff1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/18 <ck(a)cksoft.de> > This message is in MIME format. The first part should be readable text= , > while the remaining parts are likely unreadable without MIME-aware tool= s. > > --4178219828-444410844-1387368134=3D:27797 > Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed > Content-Transfer-Encoding: 8BIT > > Hi, > > On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote: > <snipp/> > > Well, I checked that the pwdLockoutDuration was correctly set (The valu= e > > in my case is 1200, so 20 minutes, much more than my tests). Other > > proof, the values of pwdFailureTime are not erased, but replaced by > > those of the master. > > > > > >> It is of course also quite possible that you have hit a special corner > >> case that nobody else has yet found. > > > > > > I think so. I have to say that I use standard syncrepl, not > delta-syncrepl. > > > > > >> > >> The best thing you could do would be to setup a small self contained > >> test case to illustrate the problem. > >> > > > > I will try to, but seems really easy to reproduce : configure master an= d > > slave with ppolicy, lock an account in slave, update same account on > > master (change description) a first time and a second time. > > are you sure the account lock actually arrives on the master ? > > Are you using olcPPolicyForwardUpdates to actually get the account > locked on the master and not only on the slaves ? > > If you do not have all the lock attributes on the master and you modify > the entry it will get replaced on the slaves. > > Can you post your master and slave configs somewhere ? > > I sent it by mail but I think it is too big and queued. So here is all configuration and test result: http://pastebin.com/earKiHnH Cl=E9ment. --089e0160b79ae9bb0c04edcfeff1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/18 <span dir=3D"ltr"><<a href=3D"mailto:ck@cksoft.de" t= arget=3D"_blank">ck(a)cksoft.de</a>></span><br><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> =A0 This message is in MIME format. =A0The first part should be readable te= xt,<br> =A0 while the remaining parts are likely unreadable without MIME-aware tool= s.<br> <br> --4178219828-444410844-1387368134=3D:27797<br> Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed<br> Content-Transfer-Encoding: 8BIT<br> <br> Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> <div class=3D"im">> Well, I checked that the pwdLockoutDuration was corr= ectly set (The value<br> > in my case is 1200, so 20 minutes, much more than my tests). Other<br> > proof, the values of pwdFailureTime are not erased, but replaced by<br= > > those of the master.<br> ><br> ><br> >> It is of course also quite possible that you have hit a special co= rner<br> >> case that nobody else has yet found.<br> ><br> ><br> > I think so. I have to say that I use standard syncrepl, not delta-sync= repl.<br> ><br> ><br> >><br> >> The best thing you could do would be to setup a small self contain= ed<br> >> test case to illustrate the problem.<br> >><br> ><br> > I will try to, but seems really easy to reproduce : configure master a= nd<br> > slave with ppolicy, lock an account in slave, update same account on<b= r> > master (change description) a first time and a second time.<br> <br> </div>are you sure the account lock actually arrives on the master ?<br> <br> Are you using olcPPolicyForwardUpdates to actually get the account<br> locked on the master and not only on the slaves ?<br> <br> If you do not have all the lock attributes on the master and you modify<br> the entry it will get replaced on the slaves.<br> <br> Can you post your master and slave configs somewhere ?<br> <div class=3D"im"><br></div></blockquote><div><br><br></div><div>I sent it = by mail but I think it is too big and queued. So here is all configuration = and test result:<br><br><a href=3D"http://pastebin.com/earKiHnH">http://pas= tebin.com/earKiHnH</a><br> <br></div><div>Cl=E9ment.<br></div></div></div></div> --089e0160b79ae9bb0c04edcfeff1--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 18 Dec '13

18 Dec '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-444410844-1387368134=:27797 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Wed, 18 Dec 2013, Clément OUDOT wrote: <snipp/> > Well, I checked that the pwdLockoutDuration was correctly set (The value > in my case is 1200, so 20 minutes, much more than my tests). Other > proof, the values of pwdFailureTime are not erased, but replaced by > those of the master. > > >> It is of course also quite possible that you have hit a special corner >> case that nobody else has yet found. > > > I think so. I have to say that I use standard syncrepl, not delta-syncrepl. > > >> >> The best thing you could do would be to setup a small self contained >> test case to illustrate the problem. >> > > I will try to, but seems really easy to reproduce : configure master and > slave with ppolicy, lock an account in slave, update same account on > master (change description) a first time and a second time. are you sure the account lock actually arrives on the master ? Are you using olcPPolicyForwardUpdates to actually get the account locked on the master and not only on the slaves ? If you do not have all the lock attributes on the master and you modify the entry it will get replaced on the slaves. Can you post your master and slave configs somewhere ? Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-444410844-1387368134=:27797--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by coudot＠linagora.com 18 Dec '13

18 Dec '13

On 16/12/2013 22:10, Christian Kratzer wrote: > Hi, > > On Mon, 16 Dec 2013, coudot(a)linagora.com wrote: >> Full_Name: Cl?ment OUDOT >> Version: 2.4.38 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.173.78.196) >> >> >> I have a simple setup with a master (overlay syncprov + overlay >> ppolicy) and a >> slave (syncrepl client, overlay ppolicy). >> >> 1. I lock my account in the slave >> 2. I change the description attribute of my account a first time in >> the master >> 3. My account is still locked in the slave >> 4. I change the description attribute of my account a second time in >> the master >> 5. My account is no more locked in the slave: the password policy >> operational >> attributes pwdFailureTime and pwdAccountUnlockTime were erased by the >> one of the >> master >> >> Seems like a control is done the first time that syncrepl update the >> entry (the >> first time, pwdAccountLockTime and pwdFailureTime are not erased), >> but the >> second time the control is not done. > > I have had a very similar setup for some time now and have never > observed this kind of behaviour from the ppolicy overlay. I am quite > confident it should work correctly in the situation you describe. > > There might be a valid reason for pwdAccountLockedtime and > pwdFailureTime attributes disappearing like perhaps expiry of > pwdLockoutDuration. Please see the account_locked() function in > servers/slapd/overlay/ppolicy.c for this. > Well, I checked that the pwdLockoutDuration was correctly set (The value in my case is 1200, so 20 minutes, much more than my tests). Other proof, the values of pwdFailureTime are not erased, but replaced by those of the master. > It is of course also quite possible that you have hit a special corner > case that nobody else has yet found. I think so. I have to say that I use standard syncrepl, not delta-syncrepl. > > The best thing you could do would be to setup a small self contained > test case to illustrate the problem. > I will try to, but seems really easy to reproduce : configure master and slave with ppolicy, lock an account in slave, update same account on master (change description) a first time and a second time. This behavior was detected by one of my customer, and I was able to reproduce it on my own computer. Clément.

1 0

(ITS#7769) [PATCH] Fix typo in slapd-meta manpage.
by jsynacek＠redhat.com 17 Dec '13

17 Dec '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 19 URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20131217-0001-Fix-typo-i… Submission from: (NULL) (209.132.186.34) Fix for a typo in slapd-meta.5

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 16 Dec '13

16 Dec '13

Hi, On Mon, 16 Dec 2013, coudot(a)linagora.com wrote: > Full_Name: Cl?ment OUDOT > Version: 2.4.38 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > I have a simple setup with a master (overlay syncprov + overlay ppolicy) and a > slave (syncrepl client, overlay ppolicy). > > 1. I lock my account in the slave > 2. I change the description attribute of my account a first time in the master > 3. My account is still locked in the slave > 4. I change the description attribute of my account a second time in the master > 5. My account is no more locked in the slave: the password policy operational > attributes pwdFailureTime and pwdAccountUnlockTime were erased by the one of the > master > > Seems like a control is done the first time that syncrepl update the entry (the > first time, pwdAccountLockTime and pwdFailureTime are not erased), but the > second time the control is not done. I have had a very similar setup for some time now and have never observed this kind of behaviour from the ppolicy overlay. I am quite confident it should work correctly in the situation you describe. There might be a valid reason for pwdAccountLockedtime and pwdFailureTime attributes disappearing like perhaps expiry of pwdLockoutDuration. Please see the account_locked() function in servers/slapd/overlay/ppolicy.c for this. It is of course also quite possible that you have hit a special corner case that nobody else has yet found. The best thing you could do would be to setup a small self contained test case to illustrate the problem. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by nhosoi＠gmail.com 16 Dec '13

16 Dec '13

--001a11c1a2f087afb804edaadb8d Content-Type: text/plain; charset=ISO-8859-1 Thank you, Howard! You are right. We are not getting LBER_OVERFLOW, but having the return code LBER_DEFAULT and "errno == ERANGE". Also, indeed there is no particular size limits in openldap lber library unless setting the max incoming ber size with this API: ber_sockbuf_ctrl(sockbuf, LBER_SB_OPT_SET_MAX_INCOMING, &maxsize); We'd like to avoid receiving, e.g., 100MB ber's, but we'd like to also have a method to log the rejected incoming ber size just in case the administrator may want to allow to receive it. Best regards, --Noriko Hosoi On Sun, Dec 15, 2013 at 3:58 AM, Howard Chu <hyc(a)symas.com> wrote: > nhosoi(a)gmail.com wrote: > >> Full_Name: Noriko Hosoi >> Version: 2.4.35-4 >> OS: Fedora 18 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.132.181.86) >> >> >> We use the OpenLdap library in our software. LDAP clients could send too >> large >> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd >> like to >> learn how large the ber size we should prepare from the error. When we >> look >> into the BerElement ber using gdb, ber->ber_len stores the value. But the >> value >> is not returned to the caller when the API fails, e.g., by the overflow. >> Could >> it be possible to have a way to retrieve the ber size under any condition? >> > > That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor > do we have any particular size limits on a BerElement, other than fitting > into a long. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11c1a2f087afb804edaadb8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>Thank you, Howard!=A0 <br><br>You are right= .=A0 We are not getting LBER_OVERFLOW, but having the return code LBER_DEFA= ULT and "errno =3D=3D ERANGE".=A0 Also, indeed there is no partic= ular size limits in openldap lber library unless setting the max incoming b= er size with this API:<br> =A0=A0=A0 ber_sockbuf_ctrl(sockbuf, LBER_SB_OPT_SET_MAX_INCOMING, &maxs= ize);<br><br></div>We'd like to avoid receiving, e.g., 100MB ber's,= but we'd like to also have a method to log the rejected incoming ber s= ize just in case the administrator may want to allow to receive it.<br> <br></div>Best regards,<br></div>--Noriko Hosoi<br></div><div class=3D"gmai= l_extra"><br><br><div class=3D"gmail_quote">On Sun, Dec 15, 2013 at 3:58 AM= , Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:nhosoi@gmail.com" target= =3D"_blank">nhosoi(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Noriko Hosoi<br> Version: 2.4.35-4<br> OS: Fedora 18<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (209.132.181.86)<br> <br> <br> We use the OpenLdap library in our software. =A0LDAP clients could send too= large<br> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. =A0We'd= like to<br> learn how large the ber size we should prepare from the error. =A0When we l= ook<br> into the BerElement ber using gdb, ber->ber_len stores the value. But th= e value<br> is not returned to the caller when the API fails, e.g., by the overflow. = =A0Could<br> it be possible to have a way to retrieve the ber size under any condition?<= br> </blockquote> <br> That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. = Nor do we have any particular size limits on a BerElement, other than fitti= ng into a long.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =A0 -- Howard Chu<br> =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br></div> --001a11c1a2f087afb804edaadb8d--

1 0

(ITS#7768) Use of olcDbUri in LDAP/Chain configuration for ppolicy_forward_updates
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I set up a slave configuration with ppolicy_forward_updates feature. In my data backend config, I have: olcUpdateRef: ldap://localhost:389 And I created the chain overlay and a sub ldap backend like this: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: top objectClass: olcConfig objectClass: olcChainConfig objectClass: olcOverlayConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="none" This configuration do not work: the BIND on the master server is done anonymously, despite the olcDbIDAssertBind value. To work, I need to add: olcDbUri: ldap://localhost:389 Seems the problem exist in OpenLDAP unit test 32, see tests/data/slapd-chain1.conf : # uses the chain overlay as global; # no chain-URI is configured, so the URI is parsed out of the referral overlay chain chain-uri @URI2@ chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret mode=self flags=non-prescriptive The comment say "no chain-URI is configured', but the chain-uri is configured. Where is the truth?

1 0

(ITS#7767) Connection not reset when olcDbUri value changed in cn=config (ldap backend)
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I configure the LDAP backend under a chain overlay to manage ppolicy-forward-updates configuration, the configuration is: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: top objectClass: olcConfig objectClass: olcChainConfig objectClass: olcOverlayConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" crede ntials="secret" mode="none" olcDbUri: ldap://localhost:389 When changing the value of olcDbUri trough an LDAP client, the connection to the server is not reset, so the configuration is not taken dynamically. All is ok if I restart OpenLDAP.

1 0

(ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I have a simple setup with a master (overlay syncprov + overlay ppolicy) and a slave (syncrepl client, overlay ppolicy). 1. I lock my account in the slave 2. I change the description attribute of my account a first time in the master 3. My account is still locked in the slave 4. I change the description attribute of my account a second time in the master 5. My account is no more locked in the slave: the password policy operational attributes pwdFailureTime and pwdAccountUnlockTime were erased by the one of the master Seems like a control is done the first time that syncrepl update the entry (the first time, pwdAccountLockTime and pwdFailureTime are not erased), but the second time the control is not done.

1 0

(ITS#7765) Crash when adding syncrepl configuration in cn=config without search base
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) When adding an olcSyncrepl attribute in my cn=config, OpenLDAP crashed. The syslog output is: Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" method=128 Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 RESULT tag=97 err=0 text= Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD dn="olcDatabase={2}mdb,cn=config" Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD attr=olcaccess olcdbindex olcsyncrepl Dec 16 11:56:42 ader slapd[8707]: olcSyncrepl: value #0: Error: Malformed "syncrepl" line in slapd config file, missing searchbase. Dec 16 11:56:42 ader slapd[8707]: failed to add syncinfo Dec 16 11:56:42 ader slapd[8707]: ch_calloc of 1 elems of 0 bytes failed I have no gdb trace to give for now, if you think it is required, I will try to find time to do it. But it should be easy to reproduce the issue on your side.

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