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

[Stefan Metzmacher]

Am 05.04.2017 um 12:49 schrieb 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. 

Ok, I didn't noticed that OpenLDAP really supports {SHA512},
{SSHA512} and similar once.

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

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

>> 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'll try to comment more detailed in the next days,
but today I already spent quite some time with the tdb locking problem.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170405/fa609f32/signature.sig>