PATCHES: Password sync as active directory domain controller

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

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?

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,

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: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160628/dd0155aa/signature.sig>