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

Re: NT/LM hash support for OpenLDAP

Luke Howard wrote:

Does anyone have a problem with adding the following to schema_prep.c
(courtesy jerry@samba.org, according to the enterprise number)?
attributetype ( 1.3.6.1.4.1.7165.2.1.1 NAME 'lmPassword'
      DESC 'LanManager Passwd'
      EQUALITY caseIgnoreIA5Match
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.2 NAME 'ntPassword'
      DESC 'NT Passwd'
      EQUALITY caseIgnoreIA5Match
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )


I think the "preferred" way to add a hash would be another
{auth,user}Password scheme, particularly given that there is
already LANMAN support. Although this wouldn't be compatible
with the incumbent SAMBA schema, it would avoid having to change
any of the backends.


I agree, and that's exactly what I've done. This means OpenLDAP can authenticate against, and generate both hash types. Are LANMAN and NTLM suitable scheme names?

My concern would be entrenching a SAMBA schema which is likely
to change as SAMBA evolves towards complete Active Directory
support. Of course, I have no authority on this matter, and
I'm not trying to discourage you :-) I would just think that
anything in schema_prep.c should be at least promulgated in
an IETF standard.


I tend to agree re: the IETF standards. However these hashes are somewhat more security sensitive than others and I doubt it will be possible to set ACLs by scheme any time soon. As such, only the samba user should have access to them and the only way I know of to do that is to use separate attributes (lmPassword and ntPassword). Also, the samba schema adds plenty of other cruft (although admittedly the rest doesn't need to end up in schema_prep.c). To do as you suggest would also involve modifying samba[-tng] to check for authPassword first, and hunt through the list for the LANMAN and NTLM schemes (not impossible, but another thing that needs to be done).

Has there been any work done on implementing authPassword functionality? Is this something I should be looking at doing too?

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.


Well, if you go with the above suggestion, you need only
modify libraries/liblutil/passwd.c.


I've made these mods already, which solves one part of my problem. The other (more important) part was to convince the exop routines to not only populate the userPassword field with a password-hash formatted password hash, but also to generate LANMAN and NTLM hashes, and populate the lmPassword and ntPassword fields. This is similar to the password notify functionality in Windows NT and allows all hash generation, complexity checking, etc. to be done in one place. It is conceivable that PAM should be integrated here too for said complexity checking, but that's fairly optional (think centralised corporate password policy). It would certainly be possible to generate multiple authPassword attributes (say, SSHA1, LANMAN, NTLM) in the exop but this doesn't solve the problems outlined above. This is functionality that should be implemented as well so as to fully support the authPassword RFC (where password-hash would become multi valued so you could specify in slapd.conf what hashes should be generated by a call to the exop).

Anyway the point is that the exop routines are in the backend, and are thus long and complicated (dealing directly with the database rather than calling a higher level function for database updates). I belive this should be implemented in servers/slapd/passwd.c, although from here I'm not sure how to act on the database (do_[modify|add] perhaps?). I'm not sure why they ended up in the backend to start with, but I'll bet there was a good reason. Anyone?

- samj



regards,

-- Luke

--
Luke Howard | lukehoward.com
PADL Software | www.padl.com