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

[Andrew Bartlett]

On Wed, 2017-04-05 at 07:58 +1200, Andrew Bartlett via samba-technical
wrote:
> On Tue, 2017-04-04 at 10:24 +0200, Stefan Metzmacher via samba-
> technical wrote:
> > Am 04.04.2017 um 10:17 schrieb Stefan Metzmacher via samba-
> > technical:
> > > 
> RFC2307 says:
> userPassword values MUST be represented by following syntax:
> 
>         passwordvalue          = schemeprefix encryptedpassword
>         schemeprefix           = "{" scheme "}"
>         scheme                 = "crypt" / "md5" / "sha" / altscheme
>         altscheme              = "x-" keystring
>         encryptedpassword      = encrypted password
> 
> The names {SHA256}, {SHA512} are 'altscheme' in this pattern, and
> match
> what is used in OpenLDAP for the password-hash parameter.  BTW, I'm
> particularly interested in extending this to {ARGON2}, which OpenLDAP
> is looking to move to. 
> 
> 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.  No tests yet, and for now I think the
'rounds' parameter can apply equally to all the SHA* methods.

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. 

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

Thanks,

Andrew Bartlett

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