s3-netlogon: implement _netr_ServerPasswordSet2.
Andrew Bartlett
abartlet at samba.org
Wed Sep 2 15:25:48 MDT 2009
On Wed, 2009-09-02 at 14:31 +0200, Guenther Deschner wrote:
> Hi Andrew,
>
> On Wed, Sep 02, 2009 at 09:24:48PM +1000, Andrew Bartlett wrote:
> > On Wed, 2009-09-02 at 03:48 -0500, Günther Deschner wrote:
> > > commit 2b8afd2257d8c9886f785929ca8dfcd04eb45755
> > > Author: Günther Deschner <gd at samba.org>
> > > Date: Thu Aug 27 23:30:50 2009 +0200
> > >
> > > s3-netlogon: implement _netr_ServerPasswordSet2.
> > >
> > > Guenther
> >
> > How do you propose to handle the random data windows feeds to this
> > function? You cannot convert the password given here into UTF8 - you
> > must MD4 the original buffer.
>
> If you look at one of the preceding patches you'd see that we do exactly
> that: MD4 the original buffer. We ever only handle the cleartext if we can
> decode the buffer (just as Samba4 does). Also, Samba3 does not store clear
> text passwords at all so it's just fine to store generated hashes.
Ahh, great. I didn't see that, and as this function left some pretty
deep wounds, I assumed the worst :-)
For safety's sake, as there are no password polices on machine accounts,
and no other reason to store the plaintext, I would always MD4 it. That
is what Samba4 does (the conversion is only to create the kerberos
keys).
> > (Also, why try to implement this in Samba3? It's needed for AD support,
> > but given the pain it induces I don't see where it fits into a NT4 DC).
>
> As you probably know we have clients out there (net & winbind) that have a
> broken netr_ServerPasswordSet() client code path (see recent cred_hash3
> removal during the netlogon auth client and server merge that finally
> fixed it). So, instead of locking out those machines (after a server
> successfully sets a password the client has incorrectly encrypted) it is
> much better to allow those clients to set their machine password using
> netr_ServerPasswordSet2 (client support for netr_ServerPasswordSet2 has
> been added to Samba3 a long time ago already).
>
> Are there any bad side-effects with that?
That sounds like a very good reason to add the function. I don't know
of anything that it would break, once you handle the random password
issue.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090903/673c42e3/attachment.pgp>
More information about the samba-technical
mailing list