Re: NT/LM hash support for OpenLDAP

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:28 AM 2002-03-04, Sam Johnston wrote:
>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?

{LANMAN} is already implemented.  If broke, submit an ITS.
I have no problem with {NTLM} as a scheme name.  Feel free
to submit this as well.

What I'd really like to see is an externalization or plugin
mechanisms for schemes.  Adding these in line is problematic
at best.  By externalization, I mean using something like
Cyrus SASL's pwcheckd/saslauthd (which is just for SASL).

>>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.

The standard approach is to use clear text passwords in userPassword
(see RFC 2256).

>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.

All values of userPassword and authPassword should be treated as
if they held clear text passwords.  See the Security Considerations
section of RFC 3112.

>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).

Given the above, not as such.  I think it's not a good idea to
tie userPassword/authPassword which support LDAP authentication
with attributes designed to support user application authentication.

If any coupling is desired, it should be administered by the
user applications.

>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).

Or modifying samba[-tng] to optionally use LDAP authentication.

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

I have a half-baked implementation... you are welcomed to
it.  Though I suggest starting (mostly) from scratch if
you wanted to implement authPassword.

However, whether or not authPassword is in use should make
no difference to applications using LDAP authentication.
They just use LDAP bind.

>>>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).

In thinking about centralized corporate password policy, one should
think of using LDAP authentication as much as possible.  If you
have to expose the actual passwords to legacy applications, use clear
text userPassword values (under tight controls).

>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?

Because the abstraction of the backend API is at the operation
level, not the database level.

Kurt