samba - Oct 2016 - samba-tool user syncpasswords / getpassword usage and clarifications

Hi everyone, hi Metze,

looking through the mailing list, it seems that there hasn't been much 
talk about the interesting features offered by syncpassword / 
getpassword that came out with 4.5.0. I was hoping to use this feature 
to pipe a ssha1 and HA1 hashes into an external ldap.

Looking at the command line doc and then at the source code, it gets a 
bit more clear to me and I wanted to have some confirmation on that process.

It seems that the only added value in the supplementalCredential 
attribute is the GPG encrypted password value (Primary:SambaGPG).

And then the PDC running the syncpasswords daemon, which would have the 
gpg private key, monitors the ldap change.

When a supplementalCredentials attribute change event occurs, one can 
use getPassword command and the private key to get the clear text 
password or one of the proposed hash out of the GPG encrypted 
Primary:SambaGPG entry, and then pipe those hashes in external openldap 
or other authentication servers.

If this is the way it works, I was wondering if is there a reason why 
not directly storing the required hashes (ssha1, ssha256, etc.) into the 
supplementalCredentials attribute on the DC doing the password change?

Cheers,

Denis

-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr

On Tue, 18 Oct 2016 22:32:20 +0200
Denis Cardon via samba <samba at lists.samba.org> wrote:
> Hi everyone, hi Metze,
> 
> looking through the mailing list, it seems that there hasn't been
> much talk about the interesting features offered by syncpassword / 
> getpassword that came out with 4.5.0. I was hoping to use this
> feature to pipe a ssha1 and HA1 hashes into an external ldap.
> 
> Looking at the command line doc and then at the source code, it gets
> a bit more clear to me and I wanted to have some confirmation on that
> process.
> 
> It seems that the only added value in the supplementalCredential 
> attribute is the GPG encrypted password value (Primary:SambaGPG).
> 
> And then the PDC running the syncpasswords daemon, which would have
> the gpg private key, monitors the ldap change.
> 
> When a supplementalCredentials attribute change event occurs, one can 
> use getPassword command and the private key to get the clear text 
> password or one of the proposed hash out of the GPG encrypted 
> Primary:SambaGPG entry, and then pipe those hashes in external
> openldap or other authentication servers.
> 
> If this is the way it works, I was wondering if is there a reason why 
> not directly storing the required hashes (ssha1, ssha256, etc.) into
> the supplementalCredentials attribute on the DC doing the password
> change?
> 
> Cheers,
> 
> Denis
> 
I suppose a big reason is that (according to here:
https://msdn.microsoft.com/en-us/library/ms679920%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
) supplementalCredentials is a system only attribute and is neither
readable or writeable.

Rowland

Hi Dennis,
> looking through the mailing list, it seems that there hasn't been much
> talk about the interesting features offered by syncpassword /
> getpassword that came out with 4.5.0. I was hoping to use this feature
> to pipe a ssha1 and HA1 hashes into an external ldap.
> 
> Looking at the command line doc and then at the source code, it gets a
> bit more clear to me and I wanted to have some confirmation on that
> process.
> 
> It seems that the only added value in the supplementalCredential
> attribute is the GPG encrypted password value (Primary:SambaGPG).
Yes.
> And then the PDC running the syncpasswords daemon, which would have the
> gpg private key, monitors the ldap change.
> 
> When a supplementalCredentials attribute change event occurs, one can
> use getPassword command and the private key to get the clear text
> password or one of the proposed hash out of the GPG encrypted
> Primary:SambaGPG entry, and then pipe those hashes in external openldap
> or other authentication servers.
Yes.
> If this is the way it works, I was wondering if is there a reason why
> not directly storing the required hashes (ssha1, ssha256, etc.) into the
> supplementalCredentials attribute on the DC doing the password change?
Because it's much more flexible that way and you can construct any new
hashing scheme that will be invented in future.

If someone wants to implement storing a set of pre-calculated hashes,
maybe in a Primary:SambaHashes field, that would also be fine in order
to make it even more flexible and avoid storing the cleartext at all.

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/attachments/20161019/2403a23a/signature.sig>

On Wed, 2016-10-19 at 10:10 +0200, Stefan Metzmacher via samba
wrote:
> Hi Dennis,
> 
> > 
> > 
> > If this is the way it works, I was wondering if is there a reason
> > why
> > not directly storing the required hashes (ssha1, ssha256, etc.)
> > into the
> > supplementalCredentials attribute on the DC doing the password
> > change?
> 
> Because it's much more flexible that way and you can construct any
> new
> hashing scheme that will be invented in future.
> 
> If someone wants to implement storing a set of pre-calculated hashes,
> maybe in a Primary:SambaHashes field, that would also be fine in
> order
> to make it even more flexible and avoid storing the cleartext at all.
I hope we can get this at some point.  (I think we both agree it is
primarily a matter of finding the dev hours, not any problem with the
idea). 

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