[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 jerry@samba.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,
liblutil/passwd.c.


And this is where I have added the new code.

I guess
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 [1]. 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

Sam