trying to correctly handle account passwords via ldap

[simo]

On Tue, 2006-03-28 at 13:18 +1000, Andrew Bartlett wrote:
> 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.  

> And as Luke points out, supplimentalCredentials

I didn't mentioned the kerberos stuff on purpose, but the idea is to
treat that the same way as the other samba specific attributes.

> > 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
> 
> Do we really need to change these again?

well we do not have any user base out there, this is the time to make
changes and think out things carefully, I do not want to need to break
compatibility after samba4 is out like we have done some times in the
samba3 development.
I do not want to make as many schema changes as we made in samba3, the
AD model does not cope with big schema changes and I want to make a rule
to carefully think about the schema well before any beta stage and try
to avoid changes, Changes should happen only rarely and for cases where
any other solution won't help.

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

"suitably privileged client" is the key here.

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

in fact I thought of linking access to these attributes to the system
account or by deliberate exclusion/option set by the administrator.

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

Sure we will have space for improvements, but please let first build the
basement and then think of the roof ... starting from the roof will not
make a good building.

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

Arbitrary LDAP edits of course.

actually we can just change ntPwdHash and lmPwdHash to arbitrary values
without password_hash taking any measure against that.

I would like a clear strategy of what operation should be permitted,
actually we do not have one, mimicking what AD does is a good,
compatible, way, enhancing that, once that works, will be easy.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org