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

[Jeremy Allison]

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 ?

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 :-).