trying to correctly handle account passwords via ldap

[Simo Sorce]

As it seem IRC sometimes fail as a communication medium, and as the
matter is important, I'm trying to summarize the current status and
how I think we should go on and eventually change this area.

Actually we avoid using the unicodePwd attribute and we introduced 5
attributes not present in a classic AD schema.

These attributes are:
sambaPassword		clear text
ntPwdHash		NT hash
lmPwdHash		LM hash
sambaNTPwdHistory	NT hash history
sambaLMPwdHistory	LM hash history

On a classic AD instead we have the following attributes:

unicodePwd		write only attribute the password is specified
			as an ucs2 string enclosed in quotes
ntPwdHistory		NT hash history
lmPwdHistory		LM hash history


I think we can easily remove all the 5 added attributes and use an AD
compatible schema. We can keep a module that accept password being set
via "virtual" attributes if we want to be able to set a password by
setting an hash and not providing the clear text password.
But, if we want to be able to generate the userPassword attribute for
unix users the preferred way will remain that of performing password
changes using a clear text password (either using the unicodePwd format
or allowing a secondary sambaPassword format).

I propose to save the three formats: clear, NT and LM in internal
reserved attributes that are always filtered on output we may even chose
to keep the current names (sambaPassword, ntPwdHash and lmPwdHash) or
change them to something more indicative of the function.
I propose:
sambaPwdClearText
sambaPwdNTHash
sambaPwdLMHash

As already stated these attributes should be considered internal and
never exposed in our schema which should contain only the AD compatibile
attributes. If our backend will (in some future) be a second ldap
server, then THAT server will have a schema extension that will allow
these 3 attributes.

Directly setting these attributes should not be permitted unless we do
some form of replication or provisioning that requires that (for example
provisioning accounts that do not have a clear text password but have
the NT and/or LM hashes available).

The history should be kept compatible, I do  not think the added value
of a salted history prevail on being compatible.


Why do I raise this question now ?

Mostly because I had to change the password_hash module for the async
interface and while changing it I found out that the current schema does
not really add much to our tree and that a number of cases are not
currently handled properly. So while rewriting it I thought it would
also have been healthy to "fix" it.
As this seem to be an open question I am not going to actually change
the behavior of password_hash, I will adjust it so that it just works as
before modulo logic fixes/bugs, but I would like to change it ASAP, so
pro/con comments are welcome.

Simo.