[PATCH] Correctly handle !authoritative in the rpc-based auth backends

Andrew Bartlett abartlet at samba.org
Mon Mar 13 23:51:31 UTC 2017


On Mon, 2017-03-13 at 10:03 +0100, Volker Lendecke wrote:
> On Mon, Mar 13, 2017 at 02:05:02PM +1300, Andrew Bartlett wrote:
> > My thoughts are that this is an internal auth subsystem detail that
> > shouldn't leak out like that.  Indeed, perhaps we should just make
> > authoritative it an additional return parameter.
> 
> That would change a LOT of code. This is so deeply embedded
> everywhere
> that this would be a much larger change code-wise.
> 
> > In the meantime, I think it is better to keep a flag like
> > USER_INFO_LOCAL_SAM_ONLY and specify it in netlogon and (at this
> > point
> > in the series at least) winbindd_pam.
> 
> To me it is much more understandable to not pass flags down that
> subtly change behaviour. But that is just my limited intellectual
> capacity that makes this necessary.
> 
> > Finally, I think we need to carefully consider the right way to
> > signal
> > 'user found but no password (need to forward)' compared with 'I
> > don't
> > know the domain'.  At the moment they have been using the same
> > return
> > value, and that is why the RODC tests failed until your latest
> > patch.  
> > (However it isn't at all clear to my how your latest patch -
> > pushing to
> > the local netlogon server - fixes that). 
> 
> What return values do you propose?

NT_STATUS_WRONG_PASSWORD with *authoriative=0 would do it nicely I
think.

If we do the same with NO_SUCH_USER then the confusing mappings outside
the auth subsytem go away, and we can probably dispense with the flag
you so dislike (as then I think the different auth module lists would
work).

That is, break out of the auth module loop based on *authoriative, not
NT_STATUS_NOT_IMPLEMENTED.  

That way we have no need for flag based changes to return values, and
callers like ntlm and ntlmssp can just ignore it, while netlogon can
honour it.  

I hope this helps,

Andrew Bartlett




More information about the samba-technical mailing list