[PATCH] Ask local netlogon pipe on an AD DC

Andrew Bartlett abartlet at samba.org
Wed Mar 1 23:13:58 UTC 2017


On Wed, 2017-03-01 at 21:55 +0100, Volker Lendecke wrote:
> On Thu, Mar 02, 2017 at 06:57:13AM +1300, Andrew Bartlett wrote:
> > On Wed, 2017-03-01 at 14:03 +0100, Volker Lendecke wrote:
> > > Hi!
> > > 
> > > Review appreciated!
> > > 
> > > Thanks, Volker
> > 
> > Thanks Volker.  I really appreciate your interest in getting the
> > auth
> > code correct here. 
> > 
> > I need to think carefully about the implications of going back to
> > the
> > SamLogon pipe here.  One challenge is that we will not be able to
> > log
> > as much of the audit information that I am working with Gary on,
> > and
> > the other is that we will start the same authentication stack from
> > scratch again but in the netlogon server, where it won't have the
> > 'sam
> > only' flag you mentioned. 
> 
> I have a set of patches that make the "sam only" flag obsolete. The
> confusion of everything forced through a single API call is what
> prevented
> us from solving the unknown domain properly for more than a decade.

I think you are right, but without the full patch set I'm having
trouble telling that properly.  Can you show me that patch set?

I agree that forcing everything through the same API is causing us big
problems, but I think we may be talking about different APIs!

I'm sure you have also realised that we have two very different use
cases for the same 'winbindd_dual_pam_auth_crap()' codepath!

The issue is that we use the same call for the 'implement auth_winbind'
and the 'back ntlm_auth' cases.  As you know, the needs for these two
are very different - we don't want winbindd re-checking passwords
already checked against the sam in smbd, but we do want ntlm_auth to
work for local accounts (and?) on a DC.

I think we need to start, for the AD DC case, by making the the IRPC
SamLogon (used by source4's auth_winbind) be a 'straight paper path' to
the REMOTE domain.  In particular, it would be great if the IRPC
handler would:
 - not re-invoke the auth stack
 - not invoke the local netlogon server

We could simply indicate that this is a 'auth_winbind' caller in the
_SamLogon call, because we know that is not called by ntlm_auth.  

Later we can work out a similar flag for the source3 auth_winbind,
either porting to IRPC or by some other trusted mechanism, and then
finally we can sort out if ntlm_auth should visit the auth stack and/or
talk to a local Netlogon server.

This would be similar to what I'm imagining of your patch, but I hope
clearer.  I think it would also make things better for the RODC and
trusted domains, but I can't really be sure until I've seen the whole
patch set.

> My arguments are:
> 
> Lower footprint -- winbind does not need to load all of auth_samba4
> for this task, when netlogond is available with a patch of less than
> 50 lines. Winbind already does connect to local samr and lsa,
> connecting to netlogond is just the next step.
> 
> Separation of concerns -- we have to make the netlogond pipe secure
> anyway, and I want this to get better separated for security reasons.
> Weak at this moment, but we need to get better here.
> 
> Code re-use -- we need to get the winbind netlogond client code right
> for the member case anyway. If there is *any* different behaviour,
> it's better we find this also in the DC case.
> 
> > I do want to get to the bottom of the right behaviour here.  It
> > seems
> > you, Gary and myself all started working on patches in the same
> > area
> > around the same time, which is sadly often the way in
> > Samba.  Please
> > don't push until I've also worked out how this will all work best. 
> 
> I will work in private until I have it right. Lets see who gets there
> first. Sorry for posting premature and incomplete patches.

I honestly find that really unhelpful.  If you would like to work with
me, please be a little more open, so we can usefully collaborate.  

As I said before, I also really want to get this right, and I think it
is critical we can both agree on and understand the solution here.  

Please help me help you and so help Samba.

Thanks,

Andrew Bartlett




More information about the samba-technical mailing list