PATCHES: Password sync as active directory domain controller

Stefan Metzmacher metze at
Tue Jun 28 19:16:23 UTC 2016

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:
>>>>>>>> =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
>> 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

> 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.
> google-apps.html
> I'm continuing to review the code.  This is a really neat feature!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the samba-technical mailing list