trying to correctly handle account passwords via ldap

[Andrew Bartlett]

On Mon, 2006-03-27 at 22:54 -0500, simo wrote:

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

Understood.  I can accept the new names, and this is why I suggested
that Samba4 'may eat your cat, but is far more likely to choose to munch
on your password database.' ;-)

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

Yes, this is how I would like to see this handled.  

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

Depends what you are trying to build :-)

> > > 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 think we should allow write to:
unicodePwd -> transforms into a write on sambaPassword
userPassword -> transforms onto a write on sambaPassword
ntPwdHash/lmPwdHash -> only without modification of sambaPassword,
implies delete of  sambaPassword

I'm not tied to the current modal of 'must delete sambaPassword', as
writing to any password attribute clearly invalidates all other
passwords.

The only other special case I would like to allow is an administrative
delete of lmPwdHash (when an administrator doesn't want LM passwords
kept any more).

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

As (I assume) AD doesn't allow these attributes to be set, we don't have
a modal here...

Andrew Bartlett

-- 
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
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060328/05589bb9/attachment.bin