[Date Prev][Date Next]
Re: NT/LM hash support for OpenLDAP
Kurt D. Zeilenga wrote:
At 03:43 AM 2002-03-04, Sam Johnston wrote:
Does anyone have a problem with adding the following to schema_prep.c
(courtesy firstname.lastname@example.org, according to the enterprise number)?
Yes, these attributes should be administrated by user applications,
not slapd. They should be loaded via a .schema file.
Don't I need them in schema_prep.c if I intend to act on them in exops?
Is there a better way to implement the exops in the backends - I've only
had a quick look but it seems they're fairly manual (start transaction, get
entry, etc.) where I'd probably rather be putting the code for each hash in
one place and calling backend specific update functions.
The hash generation code for userPassword is in one place,
And this is where I have added the new code.
the password-hash setting in slapd.conf would have to accept multiple
schemes, and a hash would be generated for each scheme listed. Checking
code would need to be updated too.
Not necessarily. authPassword can be used with one scheme, just
like userPassword. One should only use multiple schemes when
replicas don't support the same scheme as the master.
I'm not sure I agree here... I see >1 hashes being useful in many
(most?) sites. Often entities wanting to authenticate do not have the
password itself, in which case the bind authentication mechanism breaks
. Here the application needs access to the hash itself rather than
just binding to authenticate (examples include LDAP-NIS gateways like
ypldapd and Samba). Some protocols (esp APOP and CHAP) need the
cleartext and other(s) are somewhere in the middle, like CRAM-MD5
(RFC2195) which works with security sensitive contexts. authPassword
seems like an intelligent place to put the various hashes, and exops
seem like an intelligent way to keep them up to date/in sync. I see
little value in forcing applications to extend the schema (although
given I need this functionality yesterday this is probably what I'll end
up doing for the time being). It'd be nice if the password
generation/checking routines were somewhat more modular too so users can
easily add their own authentication types.
1. unless you make it more intelligent by storing the cleartext and
having it generate the hashes it needs to authenticate automatically,
possibly via the exop mechanism, which sounds ugly and would involve
more rfc writing