trying to correctly handle account passwords via ldap
abartlet at samba.org
Tue Mar 28 03:18:11 GMT 2006
On Mon, 2006-03-27 at 18:56 -0500, Simo Sorce wrote:
> 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
We also have the krb5Key attribute, which is identical in format to that
in the classic Heimdal LDAP schema.
This made the code in the hdb-ldb module easier, as all the work is done
at password set time.
> 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
And as Luke points out, supplimentalCredentials
> 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:
Do we really need to change these again?
> 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).
I think it is vital that we be able to read and set these attributes,
from a suitably privileged client. These are useful things that
distinguish us from just being 'low cost AD'. (I would far prefer to be
seen as 'flexible, free AD, able to be different'.
There is also the matter of Samba's internal operation. Samba uses the
ldb client API to read and write these attributes, and the very close
mapping between this and the exposed LDAP API has been a great
simplification and advantage (allowing Samba to be backed by Samba4's
own LDAP server).
> The history should be kept compatible, I do not think the added value
> of a salted history prevail on being compatible.
I think that this should be an administrator option. Administrators may
not intend to inter-operate with other AD DCs on the same domain, and
may wish to have a more secure history.
> 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.
Which cases are these? Do you mean arbitrary LDAP edits, or things our
current code does?
> 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.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060328/7af11b37/attachment.bin
More information about the samba-technical