Re: (ITS#8025) OpenLDAP authorisation on a client causes policykit GUI features to fail
by hyc＠symas.com
mez(a)debian.org wrote:
> Full_Name: Martin Meredith
> Version: 2.4.31
> OS: Xubuntu 14.04
> URL:
> Submission from: (NULL) (81.174.171.8)
>
>
> when combining libmap-ldap and policykit within ubuntu 14.04, this causes the
> GUI portions of PolicyKit to fail. As a side effect, this causes the lockscreen
> within Xubuntu 14.04 to be bypassable by a VT switch.
>
> I'm unsure as to what information you need to help diagnose this issue, but I
> can provide any info as required.
>
> PolicyKit bug:- https://bugs.freedesktop.org/show_bug.cgi?id=88492
Sounds like your issue is with pam_ldap, which is not OpenLDAP software.
As such, there is no code we own here that we can investigate for you.
I note that PADL, the original authors of pam_ldap, stopped supporting
it many many years ago. For several years they were referring support
customers to Symas, but we at Symas also deprecated pam_ldap many years
ago in favor of nssov.
> Ubuntu Bug: https://bugs.launchpad.net/policykit-1/+bug/1410195
There's nothing here that indicates any connection to OpenLDAP either.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 8 months
Re: (ITS#8024) Password Policy Logging Enhancement
by michael＠stroeder.com
mwarren(a)symas.com wrote:
> 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).
When running a consumer with slapo-accesslog (yes, not for delta-syncrepl)
slapo-ppolicy's modifications are written to the accesslog-DB. I use it in a
highly secure environment for seeing logins (slapo-lastbind) and login
failures (but no failure lockout).
Having just a syslog entry in this case would probably better regarding
performance though. Maybe even a info message along with the BIND RESULT
message would do.
Ciao, Michael.
8 years, 8 months
(ITS#8024) Password Policy Logging Enhancement
by mwarren＠symas.com
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
8 years, 8 months
Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by leo＠yuriev.ru
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.
8 years, 8 months
Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com
--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
8 years, 8 months
Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org
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
8 years, 8 months
Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠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.
--
Hallvard
8 years, 8 months
Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com
--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
8 years, 8 months
Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org
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
8 years, 8 months
