On 06/03/16 20:00, Howard Chu wrote:
> daniel(a)pocock.pro wrote:
>> Full_Name: Daniel Pocock
>> OS: Debian
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2001:1620:b22::2042)
>> There are a few protocols that use a HA1 password hash, such as HTTP
>> DIGEST, SIP DIGEST and TURN (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?
> The ITS is not for usage questions. You already asked this and were
> answered on the discussion mailing list.
> 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
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.