openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by hyc＠symas.com 06 Mar '16

06 Mar '16

Daniel Pocock wrote: > > > On 06/03/16 20:00, Howard Chu wrote: >> daniel(a)pocock.pro wrote: >>> Full_Name: Daniel Pocock >>> Version: >>> OS: Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (2001:1620:b22::2042) >>> >>> >>> There are a few protocols that use a HA1[1] password hash, such as HTTP >>> DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) >>> >>> Is there a standard LDAP attribute name for storing a HA1 value or >>> should it be stored in a regular userPassword attribute as described in >>> the manual[4]? >> >> The ITS is not for usage questions. You already asked this and were >> answered on the discussion mailing list. >> >> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html >> >> There is nothing here that requires any OpenLDAP development activity. >> It's all already handled by the SASL Digest mechanism, as I already >> noted in the above email. >> >> Closing this ITS. > > > I didn't open this feature request to ask for somebody to implement it, > I'm simply trying to track a number of items that I'm working on myself. > Normally I open a bug/feature request in anything I work on in case > somebody else wants to work on the same thing, it helps avoid duplication. > > The email thread doesn't fully resolve the issue, it does appear to > require some plugin to be created for the server side, especially if the > LDAP server doesn't keep plain text passwords. Given the fairly generic > nature of the DIGEST algorithm, I also felt that when implemented, this > code should be contributed to the OpenLDAP repository and not hosted > elsewhere. Take the hint: RTF SASL Digest code. All the code you're asking for has already been implemented in Cyrus SASL and is of zero concern to OpenLDAP. The most important skill of a programmer is being able to *read* - not being able to write. Any fool can spew code. Your mention of smbk5pwd is totally off base as well. The reason the smbk5pwd module was needed was because Samba 3 and the Kerberos5 KDC both stored their secrets in separate and incompatible formats but everyone wanted central coordinated administration for these separate attributes. If you're writing something from scratch there is no reason to use your own separate and incompatible attribute, and thus there is no reason to require any special synchronization or coordination. -- -- 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#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro 06 Mar '16

06 Mar '16

On 06/03/16 20:00, Howard Chu wrote: > daniel(a)pocock.pro wrote: >> Full_Name: Daniel Pocock >> Version: >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:1620:b22::2042) >> >> >> There are a few protocols that use a HA1[1] password hash, such as HTTP >> DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) >> >> Is there a standard LDAP attribute name for storing a HA1 value or >> should it be stored in a regular userPassword attribute as described in >> the manual[4]? > > The ITS is not for usage questions. You already asked this and were > answered on the discussion mailing list. > > http://www.openldap.org/lists/openldap-technical/201507/msg00073.html > > There is nothing here that requires any OpenLDAP development activity. > It's all already handled by the SASL Digest mechanism, as I already > noted in the above email. > > Closing this ITS. I didn't open this feature request to ask for somebody to implement it, I'm simply trying to track a number of items that I'm working on myself. Normally I open a bug/feature request in anything I work on in case somebody else wants to work on the same thing, it helps avoid duplication. The email thread doesn't fully resolve the issue, it does appear to require some plugin to be created for the server side, especially if the LDAP server doesn't keep plain text passwords. Given the fairly generic nature of the DIGEST algorithm, I also felt that when implemented, this code should be contributed to the OpenLDAP repository and not hosted elsewhere. Regards, Daniel

1 0

Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by hyc＠symas.com 06 Mar '16

06 Mar '16

daniel(a)pocock.pro wrote: > Full_Name: Daniel Pocock > Version: > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:1620:b22::2042) > > > There are a few protocols that use a HA1[1] password hash, such as HTTP > DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) > > Is there a standard LDAP attribute name for storing a HA1 value or > should it be stored in a regular userPassword attribute as described in > the manual[4]? The ITS is not for usage questions. You already asked this and were answered on the discussion mailing list. http://www.openldap.org/lists/openldap-technical/201507/msg00073.html There is nothing here that requires any OpenLDAP development activity. It's all already handled by the SASL Digest mechanism, as I already noted in the above email. Closing this ITS. > I came across smbk5pwd for keeping SMB password attributes in sync. Is > there a similar facility for keeping HA1 passwords in sync when a user > changes the password or how could a developer go about adding that, > would the smbk5pwd source be a useful model? > > Discussed on the mailing list already[5] > > 1. http://tools.ietf.org/html/rfc2617#section-3 > 2. https://tools.ietf.org/html/rfc3261#cection-22.4 > 3. https://tools.ietf.org/html/rfc5389#section-15.4 > 4. http://www.openldap.org/doc/admin24/security.html#Password%20Storage > 5. http://www.openldap.org/lists/openldap-technical/201507/msg00039.html > > -- -- 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#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro 06 Mar '16

06 Mar '16

Full_Name: Daniel Pocock Version: OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:1620:b22::2042) There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]? I came across smbk5pwd for keeping SMB password attributes in sync. Is there a similar facility for keeping HA1 passwords in sync when a user changes the password or how could a developer go about adding that, would the smbk5pwd source be a useful model? Discussed on the mailing list already[5] 1. http://tools.ietf.org/html/rfc2617#section-3 2. https://tools.ietf.org/html/rfc3261#cection-22.4 3. https://tools.ietf.org/html/rfc5389#section-15.4 4. http://www.openldap.org/doc/admin24/security.html#Password%20Storage 5. http://www.openldap.org/lists/openldap-technical/201507/msg00039.html

1 0

(ITS#8379) URL changes for funded and managed
by mhardin＠symas.com 01 Mar '16

01 Mar '16

Full_Name: Matthew Hardin Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.109.202.222) Thank you for the attribution for the management and hosting of the openldap.org website. We respectfully request the following changes to the URLs for the logos: 1. Please change the link URL for the "Site funded and managed by" logo to: https://symas.com/about-openldap/?utm_source=OpenLDAP&utm_medium=ctr&utm_ca… 2. Please change the link URL for the "Hosting provided by" logo to: http://symas.com/?utm_source=openldap&utm_medium=ctr&utm_campaign=OpenLdapH… Thanks

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 01 Mar '16

01 Mar '16

Oh, and one more observation, the result is intermittent. The starttls connection actually fails as it is supposed to, something like 1/100 attempts. Martin....

1 0

Re: (ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
by jonathan＠phillipoux.net 29 Feb '16

29 Feb '16

The patch I originally sent works only for MODRDN operations, but causes a segfault on plain old ADD operations in some cases. This is caused by the hdb_dn2id_children function trying to update dkids inside a non-initialised structure. I figure that if we don't have the structure we don't need to update it, since this function is mostly a "search" function. Hope that makes sense. A new patch is here: ftp://www.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete-2… Jonathan

1 0

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 29 Feb '16

29 Feb '16

This patch fixes a problem in the closing of timed-out connections to targets in back-asyncmeta. If a a_metaconn is still in use for another target, the connections to other targets might not be reset while the mc is still active, even if these targets are no longer in use. This patch introduces counters for pending operations per a_metasingleconn, and resets a metasingleconn if it has timed out and has no pending operations. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160229.patch

1 0

Re: RE : Re: Fwd: (ITS#8331) Download mirror list needs updating
by hyc＠symas.com 26 Feb '16

26 Feb '16

For tracking: David Coutadeur wrote: > > Hi Howard, > > Job done. The repository is available at: > http://repository.linagora.com/OpenLDAP/ > > > Regards, > > David > > Le 17/02/2016 14:59, Howard Chu a écrit : >> David Coutadeur wrote: >>> >>> Hi Howard, >>> >>> I didn't came back on you with that, but the proposition is still opened >>> if it is ok for you. >> >> Sure, sounds great. >> >> It turns out to be very simple, just use rsync. The set of available >> targets can be seen using >> rsync --list-only rsync://openldap.org >> >> The releases are in OpenLDAP-ftp. The CVS repo is also available but >> that's only of historical interest since we're now on git. >> >>> >>> David >>> >>> >>> Le 10/12/2015 09:08, dcoutadeur a écrit : >>>> Ok, thank you for the reply. >>>> Let me know when you have the information. >>>> >>>> David >>>> >>>> >>>> >>>> -------- Message d'origine -------- De : Howard Chu >>>> <hyc(a)symas.com> Date : 08/12/2015 17:49 (GMT+01:00) À >>>> : David Coutadeur <dcoutadeur(a)linagora.com> Objet : Re: >>>> Fwd: (ITS#8331) Download mirror list needs updating >>>> >>>> >>>> >>>> David Coutadeur wrote: >>>> > >>>> > Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>> > >>>> > Linagora (France) would be very interested to host a new mirror >>>> for OpenLDAP. >>>> > Do you have an idea of how many connections we should support ? >>>> And what >>>> > bandwidth ? I have made some statistics on an active mirror to >>>> find out the >>>> > data volume. For now it is about 1GB, so I assume 10 GB will be >>>> sufficient for >>>> > many years ? >>>> > >>>> > If you have one, can you also give me a procedure / indications >>>> for building >>>> > the platform ? >>>> > >>>> > Regards, >>>> > >>>> > >>>> > Le 04/12/2015 16:04, Howard Chu a écrit : >>>> >> A number of the mirror sites have gone offline over the years. >>>> Anyone >>>> >> interested in running a new mirror for us? >>>> >> >>>> >> -------- Forwarded Message -------- >>>> >> Subject: (ITS#8331) Download mirror list needs updating >>>> >> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>> >> From: andrew.findlay(a)skills-1st.co.uk >>>> >> To: openldap-its(a)OpenLDAP.org >>>> >> >>>> >> Full_Name: Andrew Findlay >>>> >> Version: >>>> >> OS: >>>> >> URL: ftp://ftp.openldap.org/incoming/ >>>> >> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>> >> >>>> >> >>>> >> The Netherlands mirror has vanished: ftp.nl.uu.net does not >>>> resolve in DNS. >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>>> -- >>>> -- Howard Chu >>>> CTO, Symas Corp. http://www.symas.com >>>> Director, Highland Sun http://highlandsun.com/hyc/ >>>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>>> >>>> >>>> >>>> David Coutadeur wrote: >>>>> >>>>> Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>>> >>>>> Linagora (France) would be very interested to host a new mirror for >>>>> OpenLDAP. >>>>> Do you have an idea of how many connections we should support ? And >>>>> what >>>>> bandwidth ? I have made some statistics on an active mirror to find >>>>> out the >>>>> data volume. For now it is about 1GB, so I assume 10 GB will be >>>>> sufficient for >>>>> many years ? >>>>> >>>>> If you have one, can you also give me a procedure / indications for >>>>> building >>>>> the platform ? >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Le 04/12/2015 16:04, Howard Chu a écrit : >>>>>> A number of the mirror sites have gone offline over the years. Anyone >>>>>> interested in running a new mirror for us? >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: (ITS#8331) Download mirror list needs updating >>>>>> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>>>> From: andrew.findlay(a)skills-1st.co.uk >>>>>> To: openldap-its(a)OpenLDAP.org >>>>>> >>>>>> Full_Name: Andrew Findlay >>>>>> Version: >>>>>> OS: >>>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>>> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>>>> >>>>>> >>>>>> The Netherlands mirror has vanished: ftp.nl.uu.net does not resolve >>>>>> in DNS. -- -- 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#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
by jonathan＠phillipoux.net 22 Feb '16

22 Feb '16

Full_Name: Jonathan Clarke Version: 2.4.44 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.182.31.158) Hi there, I found a bug in the handling of idl_cache when doing a MODRDN operation on an entry with children. The existing code to add an entry in hdb_dn2id_add (dn2id.c) cleverly updates any existing IDL caches on the new parent and any grand-parents, both for "one" and "sub" level searches by adding the new entry in those cache lists. However, if you MODRDN an entry that also has children, this same hdb_dn2id_add function is called, and will erroneously update the "sub" level search caches on the new parent and any grand-parents, adding only the new entry, and not it's children. The result is that a search that hits that IDL cache will return partial results, including the entry that was moved, but missing it's children. You can observe this behaviour by compiling a standard OpenLDAP server, configuring a simple hdb backend, including a non-zero idlcachesize and running the following commands: 1) ldapadd < tesldldif 2) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit 3) ldapmodrdn -s "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" "ou=1234,ou=Pending Inventories,ou=Inventorie2C2Ccn=rudder-configuration" "ou=1234" 4) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit It is important to run the initial search in step 2, before the MODRDN operation itself, to ensure an IDL cache entry is created for that search. The final search in step 4 will not show the sub-entry ou=1234-sub,ou=1234. The test.ldif file is here: ftp://ftp.openldap.org/incoming/test.ldif I've created a quick'n'dirty patch to hide this issue, which detects the situation (if adding an entry that already has children, this is when the bug occurs) and simply removes the IDL cache to avoid future searches using it. It's available here: ftp://ftp.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete.p…. A better solution would probably be to write the code to add each child of the new entry to existing caches, but I couldn't immediately see how to do this. Hopefully my patch above will easily show where this needs doing. Regards, Jonathan

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