[PATCH] winbind: Fall back to msrpc for trusted_domains call

[Christof Schmitt]

On Mon, Oct 10, 2016 at 03:47:05PM -0700, Jeremy Allison wrote:
> On Mon, Oct 10, 2016 at 03:00:41PM -0700, Christof Schmitt wrote:
> > On Mon, Oct 10, 2016 at 02:12:23PM -0700, Jeremy Allison wrote:
> > > 
> > > I'm trying to figure out under what circumstances
> > > we'd call this for our non-primary domain ?
> > > 
> > > The only way I can see this is from
> > > 
> > > rescan_forest_root_trusts() ->
> > > 	add_trusted_domains() ->
> > > 		wb_domain_request_send(WINBINDD_LIST_TRUSTDOM)
> > > 
> > > which causes the child to ask for a trusted domain
> > > list.
> > > 
> > > Here be dragons, so I'm trying to understand why
> > > we'd be doing this.. :-).
> > 
> > Correct. I have a test setup with a child and parent domain where this can be
> > easily recreated. log.winbindd shows that this goes through
> > rescan_forest_root_trusts:
> > 
> > [2016/10/10 14:51:56.893252, 10, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:370(trustdom_list_done)
> >   trustdom_list_done: parsing response line 'EXAMPLE\example.com\S-1-5-21-2745666129-1984454212-2075974874\39\2\32
> >   SUBDOM\subdom.example.com\S-1-5-21-3412315737-4225092418-116001797\25\2\0'
> > [2016/10/10 14:51:56.893313, 10, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4730(wcache_tdc_add_domain)
> >   wcache_tdc_add_domain: Adding domain EXAMPLE (example.com), SID S-1-5-21-2745666129-1984454212-2075974874, flags = 0x27, attributes = 0x20, type = 0x2
> > [2016/10/10 14:51:56.893350, 10, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:4440(add_wbdomain_to_tdc_array)
> >   add_wbdomain_to_tdc_array: Found existing record for EXAMPLE
> > 
> > ... pack_tdb_domains ...
> > 
> > [2016/10/10 14:51:56.893513,  2, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:288(add_trusted_domain_from_tdc)
> >   Added domain EXAMPLE example.com S-1-5-21-2745666129-1984454212-2075974874
> > [2016/10/10 14:51:56.893536, 10, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:370(trustdom_list_done)
> >   trustdom_list_done: parsing response line 'SUBDOM\subdom.example.com\S-1-5-21-3412315737-4225092418-116001797\25\2\0'
> > [2016/10/10 14:51:56.893565, 10, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:519(rescan_forest_root_trusts)
> >   rescan_forest_root_trusts: Following trust path for domain tree root EXAMPLE (example.com)
> > [2016/10/10 14:51:56.893596, 10, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_dual.c:1419(fork_domain_child)
> >   fork_domain_child called for domain 'EXAMPLE'
> >   
> > ... (messaging) ...
> > 
> > [2016/10/10 14:51:56.971924, 10, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cm.c:385(winbind_msg_domain_online)
> >   Domain EXAMPLE is marked as online now.
> > [2016/10/10 14:51:57.011420,  1, pid=23191, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_util.c:352(trustdom_list_done)
> >   trustdom_list_done: Could not receive trusts for domain EXAMPLE
> > 
> > 
> > I think the intent here is to create a list of all domains in an arbitrarily
> > complex forest environment. The error indicates that a normal domain member
> > does not have the necessary trust permissions to do this, so i am wondering if
> > this is intended for DCs.
> > 
> > I also recall from past discussions with Volker and Metze that winbindd should
> > not rely on this information and always communicate with the DCs in the primary
> > domain. That would be larger change. Here i am trying to find a way to avoid
> > the warnings in the winbindd log and the error events in the DC. Maybe Volker
> > or metze might want to weigh in what is the best approach. Instead of falling
> > back to the RPC methods, we could also just return without doing anything in
> > this case, since we know that the authentication call won't succeed.
> 
> Yeah, I think winbindd should only be talking to
> its primary domain DC's. Does the current code
> cause any other problems than the log message ?

It also causes an event in the DC event log on every attempt to query
trusted domains (evey 5 minutes). I have had AD administrators and
support teams ask why this happens, and this triggered the patch to
avoid this.

> My gut feeling is the correct fix for this should
> probably be in the calling function, but I may
> be wrong (this stuff is complicated :-).

If we decide to only ask the primary domain, then this should be in the
parent. My approach was to keep the logic in case a DC relies on it, but
only avoid the failing case for a domain member, but i am also looking
for feedback to better understand what is required here.

Christof