[PROPOSAL] Add tests for supplementalCredentials, store other hash types

[Andrew Bartlett]

On Wed, 2017-04-05 at 15:43 +0200, Stefan Metzmacher wrote:
> 
> > > Additionally, if we make the scheme name {CRYPT}, it makes
> > > storing
> > > multiple values more difficult (that name was what we were using
> > > for
> > > the uniqueness).  
> > > 
> > > On the flip side, if libc is moving faster than Samba, it allows
> > > an
> > > option like OpenLDAP's
> > > 
> > > password-crypt-salt-format "$1$%.8s"
> > > 
> > > to access a new hash via crypt().  However this feels overly
> > > complex.
> > > 
> > > As we already have SHA512 and SHA256 specified in your password
> > > sync
> > > tools, I would like to keep those unambiguously handled using
> > > those
> > > names. 
> > > 
> > > > > Maybe a configuration like this:
> > > > > 
> > > > > password hash openldap schemes =
> > > > > or
> > > > > password hash userpassword schemes =
> > > > > 
> > > > >    {CRYPT}:alg=5:round=1500 {SSHA} {CRYPT}:alg=6
> > > 
> > > At this stage we are trying to get a base implementation in.  I
> > > don't
> > > mind it being extended to be a multi-valued parameter, but we are
> > > trying to start with just one. 
> > 
> > I shouldn't have been so negative on this.  Gary has extended it in
> > his
> > branch to be multi-valued.
> 
> Thanks!
> 
> > No tests yet, and for now I think the
> > 'rounds' parameter can apply equally to all the SHA* methods.
> 
> Are we sure it's supported everywhere?
> An admin might need to export the hashes into different external
> directories.

Indeed.  So when the value is 0, we don't print anything into the crypt
input, and so the defaults still apply.  That should ensure it is
compatible enough. 

> > On the other side, I'm still not a fan of generic {CRYPT}.  While
> > shoehorned into the same interface, each new method takes a
> > different
> > set of arguments and needs a different length of salt.  OpenLDAP
> > permits the user to supply a printf string to allow that.  I've put
> > a
> > user-controlled printf into Samba once before, but I still feel bad
> > about it and don't want to repeat it. 
> 
> Yes, we can't allow printf style things.

Thanks.

> > > In terms of how other software performs the configuration, I'll
> > > note:
> > > 
> > > https://linux.die.net/man/8/pam_unix
> > > 
> > > Here the algorithms are hard coded.  This is nice and easy for
> > > the
> > > administrator to understand, rather than alg=5.  
> > > 
> > > > Or "CryptSHA256:round=1500 SSHA CryptSHA512
> > > > CryptSHA512:round=5000",
> > > > in which cases if matches more what we have in 'samba-tool user
> > > > getpassword',
> > > > but then remove the the reference to RFC2307 from the docs.
> > > 
> > > I don't see a need to remove the reference, as long as we use
> > > {SHA512}
> > > etc, as we also reference OpenLDAP's interpretation of that. 
> > > 
> > > > If you add the magic with specifying 'round', please try to
> > > > find a
> > > > way
> > > > to also add it to
> > > > samba-tool user getpassword
> > > 
> > > Passwords are complex, my strong preference is to keep this
> > > simple,
> > > whatever we do.
> > 
> > Thanks for your feedback, and I'm sorry for being so negative this
> > morning.  We will get something pretty great here, I'm sure!
> 
> Yes, but it will take some time, as we should have a solid format
> for the database records as well a solid way to configure it.
> Once we added it we can't change it anymore without major pain.

I do agree.  I want the main parameter to be simple, so perhaps we end
up with more formal parameters to control the extra features of each
method.  I'll certainly document that "password hash additional rounds"
applies to SHA256/SHA512 only.  

I'll also look to OpenLDAP for ideas to evaluate (positively or
negatively). 

> I'll try to comment more detailed in the next days,
> but today I already spent quite some time with the tdb locking
> problem.

Thanks for that. 

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170406/a6eaface/signature.sig>