openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

ITS#6826 Apache htpasswd MD5 support
by hyc＠symas.com 04 Feb '11

04 Feb '11

New password hash mechanisms should simply be implemented as standalone modules for inclusion under contrib/slapd-modules. See contrib/slapd-modules/passwd for existing examples. -- -- 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 04 Feb '11

04 Feb '11

michael(a)stroeder.com wrote: > Could we have this overlay in contrib/ shipped with 2.4.24? > That would be really nice. > > I've tested it with 2.4.23 and it still seems to work. Committed with changes 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

(ITS#6826) Apache htpasswd MD5 support [patch]
by djpohly＠gmail.com 04 Feb '11

04 Feb '11

Full_Name: Devin J. Pohly Version: 2.4.23 OS: Linux URL: http://openldap.pastebin.com/t4jWaUfe Submission from: (NULL) (75.102.64.250) == Proposed enhancement == When migrating an Apache .htpasswd-based system to LDAP authentication, it would be nice if the password hashes would migrate cleanly. .htpasswd uses three hash formats: {SHA}, {CRYPT}, and "apr1", an MD5-based variant not supported by OpenLDAP. If OpenLDAP had a hash which was equivalent to (i.e. could be freely converted to and from) Apache's apr1, conversion would be easy. == Solution == If you're willing to have OpenLDAP depend on APR-Util, it would be trivial to use the apr_md5_encode and apr_password_validate functions to support this hash. If not, I created a patch [1] which implements the apr1 hash. The algorithm is the same as PHK MD5 with a different magic number. I derived the code from the PHK source which is freely usable under the Beer-ware license (see patch). This patch adds an {APR1} hash type to OpenLDAP when configured with --enable-apr1. [1] http://openldap.pastebin.com/t4jWaUfe (Note: patch is against release, but passwd.c has not changed significantly in HEAD.) == Discussion == The patch has held up to my (limited) testing, but it could probably be written better. It might be useful to put the algorithm into its own function or file, since it's fairly complex and used in both the chk_apr1 and hash_apr1 functions. It might also be useful to specify the magic number to the functions; then we would get PHK $1$ hashes for free. Apache selects salts with 48 bits of randomness but treats them as 64-bit salts. The lines referring to apr64[] replicate this behavior for backward compatibility (so {APR1} hashes generated by slappasswd can be converted to .htpasswd). If you're not concerned about being able to convert in the opposite direction, that code can be removed, and OpenLDAP can then use any size salt. == Tools == The hashes are stored in OpenLDAP's base64(hash + salt) format for consistency. I put together a couple pipe-able scripts for converting between Apache's $apr1$ and OpenLDAP {APR1} formats: Apache to OpenLDAP: http://openldap.pastebin.com/0SSbzjhH OpenLDAP to Apache: http://openldap.pastebin.com/rfLBRASr

1 0

Re: (ITS#6810) slapd crashes writing to bdb backend
by bruno.haleblian＠gmail.com 04 Feb '11

04 Feb '11

--0016e644d08a200ed6049b76654a Content-Type: text/plain; charset=ISO-8859-1 Hi Quanah, Anyway, exactly same core is dumped with BDB 4.8,.30 downloaded from Oracle... I'm likely to misconfig my replication but can't figure out for now .... Regards, Bruno -- --0016e644d08a200ed6049b76654a Content-Type: text/html; charset=ISO-8859-1 Hi Quanah, Anyway, exactly same core is dumped with BDB 4.8,.30 downloaded from Oracle... I'm likely to misconfig my replication but can't figure out for now .... Regards, Bruno -- --0016e644d08a200ed6049b76654a--

1 0

Re: (ITS#6825) unique_uri filter reaching beyond its intended target
by subbarao＠computer.org 03 Feb '11

03 Feb '11

On 02/03/2011 06:24 PM, Howard Chu wrote: > Looks like a bug, the filter check is only implemented for Add > operations, not for Modify or ModDN. > > In the meantime, as a workaround you should simply use a more fully > qualified URI. Restrict the URI to the ou containing your posixGroup > entries. Since user names and group names are separate name spaces in > POSIX, you cannot store them both in the same branches of a DIT anyway. The workaround works, thanks for the quick response! There will be other uniqueness scenarios where it will be good to have the full functionality, but for this situation we should be fine. Regards, -Kartik

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 03 Feb '11

03 Feb '11

On 02/03/2011 06:27 PM, Howard Chu wrote: > Kartik Subbarao wrote: >> I'd like to add one clarification to this message. I named the attached >> test script that illustrates the two RESULT messages problem >> test099-ppolicy-update, per Howard's previous advice not to duplicate >> existing names. But I just realized that this script relies on the same >> data files that I previously submitted (slapd-ppolicy.conf, >> ppolicy.ldif) so when running this script please ensure that those files >> are in place. > > That's fine. I've stopped working on this issue until I get some > feedback from Ando on my previous comments. Ok understood. One request, can the status be changed from "Closed" to whatever is appropriate? Thanks, -Kartik

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 03 Feb '11

03 Feb '11

Kartik Subbarao wrote: > I'd like to add one clarification to this message. I named the attached > test script that illustrates the two RESULT messages problem > test099-ppolicy-update, per Howard's previous advice not to duplicate > existing names. But I just realized that this script relies on the same > data files that I previously submitted (slapd-ppolicy.conf, > ppolicy.ldif) so when running this script please ensure that those files > are in place. That's fine. I've stopped working on this issue until I get some feedback from Ando on my previous comments. -- -- 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#6825) unique_uri filter reaching beyond its intended target
by hyc＠symas.com 03 Feb '11

03 Feb '11

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.23 > OS: Debian Linux 5.0.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.99.175.5) > > > I have the uniqueness overlay configured as follows in slapd.conf: > > overlay unique > unique_uri ldap:///?gidNumber?sub?(objectClass=posixGroup) > > The policy I want to enforce is that all posixGroup entries must have a unique > gidNumber attribute. At the same time, I want to *allow* non-posixGroup entries > (such as inetOrgPerson) to have the same gidNumber attribute that a posixGroup > entry has. This is so that a user can have a login group id set to that of an > existing group. > > With the above configuration in place, if I create a posixGroup entry with > gidNumber 389, and then try to add a gidNumber attribute of 389 to an > inetOrgPerson entry, the operation fails with a constraint error "some > attributes not unique". > > As I read the manpage for slapo-unique, the unique_uri filter seems to support > the functionality that I want: > > ===== > The filter component causes the domain to apply uniqueness constraints only to > matching objects. e.g. ldap:///?cn?sub?(sn=e*) would require unique cn > attributes for > all objects in the subtree of the back-end database whose sn starts with an e. > ===== > > I'm inferring from this that uniqueness constraints on the cn attribute would > *not* be applied to objects that don't match the filter. But that doesn't seem > to be happening here. Is this a bug in the uniqueness overlay or am I not > understanding the implementation? Looks like a bug, the filter check is only implemented for Add operations, not for Modify or ModDN. In the meantime, as a workaround you should simply use a more fully qualified URI. Restrict the URI to the ou containing your posixGroup entries. Since user names and group names are separate name spaces in POSIX, you cannot store them both in the same branches of a DIT anyway. -- -- 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#6825) unique_uri filter reaching beyond its intended target
by subbarao＠computer.org 03 Feb '11

03 Feb '11

One clarification -- in my original message, I meant to say "posixAccount" in place of "inetOrgPerson". These are inetOrgPerson objects, but they also have the posixAccount objectClass which allows them to have the gidNumber attribute. -Kartik

1 0

(ITS#6825) unique_uri filter reaching beyond its intended target
by subbarao＠computer.org 03 Feb '11

03 Feb '11

Full_Name: Kartik Subbarao Version: 2.4.23 OS: Debian Linux 5.0.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.99.175.5) I have the uniqueness overlay configured as follows in slapd.conf: overlay unique unique_uri ldap:///?gidNumber?sub?(objectClass=posixGroup) The policy I want to enforce is that all posixGroup entries must have a unique gidNumber attribute. At the same time, I want to *allow* non-posixGroup entries (such as inetOrgPerson) to have the same gidNumber attribute that a posixGroup entry has. This is so that a user can have a login group id set to that of an existing group. With the above configuration in place, if I create a posixGroup entry with gidNumber 389, and then try to add a gidNumber attribute of 389 to an inetOrgPerson entry, the operation fails with a constraint error "some attributes not unique". As I read the manpage for slapo-unique, the unique_uri filter seems to support the functionality that I want: ===== The filter component causes the domain to apply uniqueness constraints only to matching objects. e.g. ldap:///?cn?sub?(sn=e*) would require unique cn attributes for all objects in the subtree of the back-end database whose sn starts with an e. ===== I'm inferring from this that uniqueness constraints on the cn attribute would *not* be applied to objects that don't match the filter. But that doesn't seem to be happening here. Is this a bug in the uniqueness overlay or am I not understanding the implementation?

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