PATCHES: Password sync as active directory domain controller

[Stefan Metzmacher]

Am 28.06.2016 um 02:10 schrieb Andrew Bartlett:
> On Mon, 2016-06-27 at 08:29 +0200, Stefan Metzmacher wrote:
>> Am 27.06.2016 um 06:59 schrieb Andrew Bartlett:
>>>
>>> On Tue, 2016-06-21 at 01:03 +0300, Alexander Bokovoy wrote:
>>>>
>>>> On Mon, 20 Jun 2016, Stefan Metzmacher wrote:
>>>>>
>>>>>
>>>>> Am 10.06.2016 um 11:49 schrieb Alexander Bokovoy:
>>>>>>
>>>>>>
>>>>>> On Fri, 10 Jun 2016, Andrew Bartlett wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 2016-05-06 at 13:36 +0200, Stefan Metzmacher wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If I have my slides done:-)
>>>>>>>>
>>>>>>>> In the meantime I've rebased and squashed on top of
>>>>>>>> current
>>>>>>>> master:
>>>>>>>> https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h
>>>>>>>> =ref
>>>>>>>> s/heads/
>>>>>>>> master4-gpgme
>>>>> I've rebased that branch on current master.
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would like to look into this next week.  
>>>>>> I did run through a half of the review but I have trouble in
>>>>>> actually
>>>>>> successfully running the tests, they seem to fail to me. The
>>>>>> code
>>>>>> changes seem to be logical to me so not sure what happens.
>>>>> Do you have gpgme-devel and python-gpgme installed?
>>>> I do, the code builds fine, make test fails if I run the gpgme
>>>> tests
>>>> alone. I'll do another round today after setting up IOLab's
>>>> environment.
>>> As a start, can we please have the configure script print out
>>> suggested
>>> package names to install for gpgme, and put the info in the
>>> WHATSNEW?
>> Done.
>>
>>>
>>> I'm out of time at work today, and this is the point I got stuck on
>>> :-)
>>>
>>> More broadly, how do we know that putting in extra info into
>>> supplementalCredentials is safe?  It isn't that I'm opposed - I
>>> think
>>> it is high time we started innovating ahead of Microsoft, because
>>> that
>>> is where Samba is at its best - but I figure you have thought of
>>> that
>>> also. 
>> I tested replicating to Windows and logged in there and changed the
>> password
>> and replicated the result back to Samba in order to have a look.
>>
>> Windows doesn't remove the SambaGPG field but rotate it to the first
>> place,
>> while we put the current value to the end. So we only use it if it's
>> the
>> last field.
> 
> Thanks.  I realise this is highly inconvenient to ask now as you
> probably have this already deployed somewhere, but I think the
> encrypted plaintext blob needs a checksum against the other password. 

Yes, customers are already using it.

But we may be able to make a compatible change and create a
checksum (sha512 ?) over the Primary:Kerberos-Newer-Keys
and use a Primary:SambaGPG_HEXSTRINGOFCHECKSUM as key to
store the GPG value.

But still fallback if only Primary:SambaGPG is available.

> That is, we need to encode the current password from one of the
> Windows-supported schemes into the blob, so we don't output the old
> password, because I think it is too fragile to base this on the
> position re-order (and this may break other extensions we add).
> 
> Also, I really like the ability to get at the plaintext password if
> required, but I don't quite understand why the work to create
> the virtualCryptSHA512 attribute is done at extraction time.  Why not
> move this part outside the GPG blob, remove the complexity and
> dependency of invoking GPG, and ensure that we don't have the plaintext
> password for those use cases?

If you want you can also implement that and store a Primary:CryptSHA512
blob and get the virtualCryptSHA512 out of that if available.

My main goal was to avoid forcing to know what format we later be able to
get.

> As you know, this much has been a popular request and thankfully now
> matches what Google needs for their google app sync, as well as
> OpenLDAP.
> 
> http://googleappsupdates.blogspot.co.nz/2016/02/updated-version-v15-of-
> google-apps.html
> http://www.openldap.org/lists/openldap-technical/201305/msg00002.html
> 
> I'm continuing to review the code.  This is a really neat feature!

Thanks!
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/20160628/044a5e19/signature.sig>