Authentication on a DC

[Andrew Bartlett]

On Tue, 2017-02-28 at 17:09 +1300, Andrew Bartlett wrote:
> On Mon, 2017-02-27 at 12:05 +0100, Volker Lendecke wrote:
> > Hi!
> > 
> > Right now I'm trying to correctly return NT_STATUS_NO_SUCH_USER
> > with
> > authoritative=0 from our DC implementation(s) in the case when our
> > netlogon server does not know the domain name. I'm hitting wall
> > after
> > wall with autobuild, so I would like to lay out what I think is a
> > flaw
> > in our authentication approach.
> > 
> > On a DC, we have two cases which I believe are to be handled
> > differently:
> > 
> > * Acting as a DC
> > 
> > * Giving access to a local resource
> > 
> > When giving access to a local resource, we need to fall back to
> > essentially sam_ignoredomain when the user comes in with a
> > completely
> > unknown domain name. We should not do this as a netlogon server, we
> > should return the NO_SUCH_USER/authoritative=0. This case is
> > essentially handled through NT_STATUS_NOT_IMPLEMENTED internally.
> > 
> > The design flaw is I believe that we force all authentication
> > through
> > a single set of auth methods, not looking at the use case.
> > 
> > Forcing everything through this single interface makes things like
> > "USER_INFO_LOCAL_SAM_ONLY" necessary in the first place. If
> > winbindd_pam had the liberty to just create an auth context with
> > just
> > "sam", this flag would not be required.
> > 
> > Comments?
> 
> I think you are right.  We could use the same stack, but only if we
> have the 'local resource' part re-submit with the local domain if we
> get back the magic NO_SUCH_USER/authoritative=0.

Thinking about this with the context of the auth logging I've been
working on with Gary, I would prefer not to re-submit it to the stack
twice.  That will just trigger (or make us have to code to ignore,
which would be fragile) pointless audit events for the first attempt.

> That would match a little of what a member server should be doing,
> except of course it doesn't re-submit to the DC, but to itself.
> 
> Otherwise, we certainly could change the stack, and even via the
> auth_samba4 glue module we accept a forced method via
> 'auth_samba4:module' syntax, so this should all be quite practical.

Either we specify different stacks, or we pass in another flag. 
Essentially they end up being the same thing really, it it just a
matter of which is more elegant in the end.

> Thanks for looking into this, and thinking about how to solve these
> real-world issues.
> 
> The final wrinkle in this area around the NOT_IMPLEMETNED fallback is
> the handling of password forwarding to the RODC.  This is on my team
> at
> Catalyst's agenda for work.  We hope to get it working again, and add
> tests to ensure it stays working.  Currnetly the approach is to pass
> it
> on to winbind and then have winbindd talk to the full-service DC
> (despite it being a 'local' account).
> 
> 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