openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#8024) Password Policy Logging Enhancement
by mwarren＠symas.com 14 Jan '15

14 Jan '15

Full_Name: Mark Warren Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.35.133.119) Greetings, We would like make a new feature request for enhanced logging within the Password Policy Module. A customer has a need for logging of automated password lockouts which occur after a certain number of failed binds within a given time window. Pertinent info would include the DN of the locked out user as well as the source IP of the failed attempt(s). Best Regards, Mark

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by leo＠yuriev.ru 14 Jan '15

14 Jan '15

2015-01-14 8:49 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 13/01/15 19:23, Hallvard Breien Furuseth wrote: >> >> Yes, that didn't come out right. I don't mind inserting the >> volatile, but I don't know that it helps either. As far as I >> understand if it was broken without volatile, then it's still >> broken with it - just hopefully less likely to break. And LMDB >> couldn't be releaseed with your original unportable sync code >> along with the volatile. > > > Sorry, nevermind. Of course when the writer does sync well enough, > volatile + the txn_renew loop will have to do for a sync primitive in > the reader. > I suppose this requires that sync in the writer thread > will shake other threads as well, it won't be private to the writer. In general this is wrong, more precisely depend on 'volatile' on shared variables and usage of barriers/fences by the readers. Sync-ops due lock/release a mutex by writer issue a memory-barrier for its own thread. With this compiler must update all modified variables, which shaded in the CPU registers. Next a hardware write-barrier (aka release) in the mutex-release code enforce all changes to be visible for other threads (e.g. flush the cache). But 'be visible' here mean 'publish' and other threads can access these changes, but if want this. In general, to see changes made by the writer, all other threads should issue a read-barrier (aka acquire). On most arches such barrier just inform compiler that memory was changed and variables which cached in the registers must be reloaded. But in some cases (like Itanium) this barrier will be taken in account for instruction scheduling. For 'volatile' compiler should generate barriers each time on read or write such variables. More general, memory-barriers are very important to HPC, distributed computing and for super-computers. For example read-barriers may pull changes from internode-bus or other nodes, and write-barriers - publish the local changes. So, the one way to avoid a race bugs - thinking in terms of publish/pull changes.

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 14 Jan '15

14 Jan '15

--On Wednesday, January 14, 2015 11:00 AM +0000 freebsd(a)jonathanprice.org wrote: > Hi, > > I tried 2.4.39 under FreeBSD and still had the same issue. > > I have also tried the packages for both CentOS 7 and Debian Wheezy, but > unfortunately neither of them include the SHA2 overlay by default. > > Finally, I tried installing zimbra-core and zimbra-ldap under CentOS. > When I used this installation, it worked successfully. > > I ran slapd -V on the zimbra installation, and it's 2.4.39. However, > based on it still not working on 2.4.39 on FreeBSD it appears to have > narrowed it down to two reasons: - An issue with the packaging under > FreeBSD > - The functionality is specific to Zimbra > > The next step in the process to narrow this down is to do a manual > compilation on CentOS, including the SHA2 overlay. If this works, then it > would confirm it to be a FreeBSD issue, and if it doesn't work that would > strongly suggest that Zimbra has modified something. You could simply grab the LTB project builds. I'm pretty sure they build out the contrib modules. In any case, I already noted that Zimbra doesn't patch anything in OpenLDAP that would affect this area. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 14 Jan '15

14 Jan '15

Hi,=0A=0AI tried 2.4.39 under FreeBSD and still had the same issue.=0A=0A= I have also tried the packages for both CentOS 7 and Debian Wheezy, but u= nfortunately neither of them include the SHA2 overlay by default.=0A=0AFi= nally, I tried installing zimbra-core and zimbra-ldap under CentOS. When = I used this installation, it worked successfully.=0A=0AI ran slapd -V on = the zimbra installation, and it's 2.4.39. However, based on it still not = working on 2.4.39 on FreeBSD it appears to have narrowed it down to two r= easons:=0A- An issue with the packaging under FreeBSD=0A- The functionali= ty is specific to Zimbra=0A=0AThe next step in the process to narrow this= down is to do a manual compilation on CentOS, including the SHA2 overlay= . If this works, then it would confirm it to be a FreeBSD issue, and if i= t doesn't work that would strongly suggest that Zimbra has modified somet= hing.=0A=0AThanks for the assistance so far,=0A=0A-Jonathan=0A=0AJanuary = 13 2015 8:00 PM, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: =0A> --= On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price=0A> <freebsd@jo= nathanprice.org> wrote:=0A> =0A>> I do apologise for the confusion, I'll = try to clarify below:=0A>> =0A>> Here is the command you ran successfully= :=0A>> /opt/zimbra/openldap/sbin/slappasswd -h=0A>> '{SSHA512}' -o module= -path=3D/opt/zimbra/openldap/sbin/openldap -o=0A>> module-load=3Dpw-sha2 = -s test=0A>> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5= We5HNkXxFfy5=0A>> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9=0A>> =0A>> Here is an= example of me running just a plain SHA512=0A>> slappasswd -h '{SHA512}' = -o module-path=3D/usr/local/libexec/openldap -o=0A>> module-load=3Dpw-sha= 2=0A>> {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvI= h/1nsUN=0A>> zLDBMxfqa2Ob1f1ACio/w=3D=3D=0A>> =0A>> And here is an exampl= e of me running a salted SHA512 (SSHA512)=0A>> slappasswd -h '{SSHA512}' = -o module-path=3D/usr/local/libexec/openldap -o=0A>> module-load=3Dpw-sha= 2 -s test=0A>> Password verification failed.=0A>> =0A>> I hope this helps= to clarify.=0A> =0A> Yes, thank you. So I'm using 2.4.39. There were som= e minor changes to=0A> slapd-sha2 in 2.4.40. I will see if I can reproduc= e the issue with current=0A> RE24.=0A> =0A> --Quanah=0A> =0A> --=0A> =0A>= Quanah Gibson-Mount=0A> Platform Architect=0A> Zimbra, Inc. =0A> _______= ________________________=0A> =0A> Zimbra :: the leader in open source mes= saging and collaboration

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠usit.uio.no 14 Jan '15

14 Jan '15

On 13/01/15 19:23, Hallvard Breien Furuseth wrote: > Yes, that didn't come out right. I don't mind inserting the > volatile, but I don't know that it helps either. As far as I > understand if it was broken without volatile, then it's still > broken with it - just hopefully less likely to break. And LMDB > couldn't be releaseed with your original unportable sync code > along with the volatile. Sorry, nevermind. Of course when the writer does sync well enough, volatile + the txn_renew loop will have to do for a sync primitive in the reader. I suppose this requires that sync in the writer thread will shake other threads as well, it won't be private to the writer. -- Hallvard

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

--On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price <freebsd(a)jonathanprice.org> wrote: > I do apologise for the confusion, I'll try to clarify below: > > Here is the command you ran successfully: > /opt/zimbra/openldap/sbin/slappasswd -h > '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o > module-load=pw-sha2 -s test > {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 > Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 > > Here is an example of me running just a plain SHA512 > slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 > {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUN > zLDBMxfqa2Ob1f1ACio/w== > > And here is an example of me running a salted SHA512 (SSHA512) > slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 -s test > Password verification failed. > > I hope this helps to clarify. Yes, thank you. So I'm using 2.4.39. There were some minor changes to slapd-sha2 in 2.4.40. I will see if I can reproduce the issue with current RE24. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 13 Jan '15

13 Jan '15

I do apologise for the confusion, I'll try to clarify below: Here is the command you ran successfully: /opt/zimbra/openldap/sbin/slappasswd -h '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o module-load=pw-sha2 -s test {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 Here is an example of me running just a plain SHA512 slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBMxfqa2Ob1f1ACio/w== And here is an example of me running a salted SHA512 (SSHA512) slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s test Password verification failed. I hope this helps to clarify. On 2015-01-13 19:14, Quanah Gibson-Mount wrote: > --On Tuesday, January 13, 2015 7:11 PM +0000 Jonathan Price > <freebsd(a)jonathanprice.org> wrote: > >> Hi, >> >> From the original email: >> However, if I replace {SHA512} with {SSHA512} it produces the following >> output: >> Password verification failed. > > You also were not clear *where* you did this replacement. It is > certainly not valid to do this replacement on the generated hash, as the > generated has was non-salted, and just adding another S in there will > not magically make it salted. It is valid to do this replacement in the > slappasswd line when generating a hash, as per my example, so that a > salted hash is generated. > > --Quanah > > >> It's interesting to see that it does work under certain conditions then. >> It appears that your OpenLDAP installation is part of a Zimbra >> installation. Does Zimbra make any modifications to OpenLDAP, or is it >> just built on top of it? >> >> Either way, I think I'm going to try it on Debian, just to rule out it >> being a FreeBSD issue, which it quite well could be at this point. >> >> On 2015-01-13 19:01, Quanah Gibson-Mount wrote: >>> --On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org >>> wrote: >>> >>>> Full_Name: Jonathan Price >>>> Version: 2.4.40 >>>> OS: FreeBSD 10.1 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (80.47.105.54) >>>> >>>> >>>> I have compiled version 2.4.40 with the SHA2 module enabled. >>>> >>>> I then run the slappasswd with the following arguments: >>>> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >>>> module-load=pw-sha2 >>> >>> You requested a non salted hash -> SHA512 >>> >>> Did you try requesting a salted hash? -> SSHA512 >>> >>> Works fine for me, and I've been using it in production for quite some >>> time. >>> >>> [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h >>> '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o >>> module-load=pw-sha2 -s test >>> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 >>> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 >>> >>> >>> >>> --Quanah >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Platform Architect >>> Zimbra, Inc. >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

--On Tuesday, January 13, 2015 7:11 PM +0000 Jonathan Price <freebsd(a)jonathanprice.org> wrote: > Hi, > > From the original email: > However, if I replace {SHA512} with {SSHA512} it produces the following > output: > Password verification failed. You also were not clear *where* you did this replacement. It is certainly not valid to do this replacement on the generated hash, as the generated has was non-salted, and just adding another S in there will not magically make it salted. It is valid to do this replacement in the slappasswd line when generating a hash, as per my example, so that a salted hash is generated. --Quanah > It's interesting to see that it does work under certain conditions then. > It appears that your OpenLDAP installation is part of a Zimbra > installation. Does Zimbra make any modifications to OpenLDAP, or is it > just built on top of it? > > Either way, I think I'm going to try it on Debian, just to rule out it > being a FreeBSD issue, which it quite well could be at this point. > > On 2015-01-13 19:01, Quanah Gibson-Mount wrote: >> --On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org >> wrote: >> >>> Full_Name: Jonathan Price >>> Version: 2.4.40 >>> OS: FreeBSD 10.1 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (80.47.105.54) >>> >>> >>> I have compiled version 2.4.40 with the SHA2 module enabled. >>> >>> I then run the slappasswd with the following arguments: >>> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >>> module-load=pw-sha2 >> >> You requested a non salted hash -> SHA512 >> >> Did you try requesting a salted hash? -> SSHA512 >> >> Works fine for me, and I've been using it in production for quite some >> time. >> >> [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h >> '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o >> module-load=pw-sha2 -s test >> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 >> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 >> >> >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Platform Architect >> Zimbra, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 13 Jan '15

13 Jan '15

Hi, From the original email: However, if I replace {SHA512} with {SSHA512} it produces the following output: Password verification failed. It's interesting to see that it does work under certain conditions then. It appears that your OpenLDAP installation is part of a Zimbra installation. Does Zimbra make any modifications to OpenLDAP, or is it just built on top of it? Either way, I think I'm going to try it on Debian, just to rule out it being a FreeBSD issue, which it quite well could be at this point. On 2015-01-13 19:01, Quanah Gibson-Mount wrote: > --On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org > wrote: > >> Full_Name: Jonathan Price >> Version: 2.4.40 >> OS: FreeBSD 10.1 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.47.105.54) >> >> >> I have compiled version 2.4.40 with the SHA2 module enabled. >> >> I then run the slappasswd with the following arguments: >> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >> module-load=pw-sha2 > > You requested a non salted hash -> SHA512 > > Did you try requesting a salted hash? -> SSHA512 > > Works fine for me, and I've been using it in production for quite some > time. > > [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h > '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o > module-load=pw-sha2 -s test > {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 > > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

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