RFC Reroute samlogon for trusted child domain user if samlogon fails

[Noel Power]

On 16/11/15 18:47, Andrew Bartlett wrote:
> On Mon, 2015-11-16 at 15:27 +0000, Noel Power wrote:
>> On 13/11/15 21:35, Andrew Bartlett wrote:
>>> On Fri, 2015-11-13 at 15:20 +0000, Noel Power wrote:
>> [...]
>>>> t want to waste time on an unacceptable solution, any ideas?
>>>> well I didn't have any extra inspiration (and a customer bug
>>>> associated
>>>> with 3.6.x to do with this issue) so I ran with the possibly
>>>> unacceptable solution. Please find the attached patch, it seems
>>>> to
>>>> work
>>>> fine but..., anyway would be really great to get some
>>>> feedback/advice
>>>> etc.
>>> Very interesting.  When I read this before I saw the idea of using
>>> extra_data, but I assumed it was just on the reply, not modifying
>>> to
>>> request.  Now I understand why you were so worried.
>>>
>>> The main issue is that this is client-controlled data, the client
>>> could
>>> put the same thing in there.  Assuming no better place to put this,
>>> please ensure that the extra_data and WBFLAG_PREVIOUS_KRB5_ERROR is
>>> unconditionally wiped at the entry-point. 
>> Thanks alot for the comments and advice Andrew, so ok... updated the
>> patch with above in mind. 
> This is looking better.  Can you please just tweak:
>
> +	/* Clear previous error flag and associated data*/> 
> +	request->flags &= ~WBFLAG_PREVIOUS_KRB5_ERROR;> 
> +	request->extra_len = 0;> 
> +	request->extra_data.data = NULL;
>
> This hunk to explain why it is so important to do that.  Otherwise, in
> a few years time we will forget this little detail.  It needs to say
> that this in an internal flag (and rename the flag to be _INTERNAL_).
>
ok no problem, I can rework that, will send a new version tomorrow
>> But the patch currently only deals with
>> samlogon when falling back from kerberos, the old logic used to deal
>> with samlogon more generically and would reroute even if kerberos was
>> not involved, with that in mind I attach a second patch to handle
>> non-primary domain samlogon requests in general (and return more
>> processing required to the parent for those too, I would like to
>> squash
>> the 2 patches but of course I would like to see if anyone would
>> object
>> to that
> How would we get in this situation if we are not doing krb5?  The only
> other cases I can think of is NTLM in a AD DC trust situation, with non
> -mesh trusts or on an RODC, but it would be better if we routed those
> correctly upfront.
I don't have a concrete example except looking at the parent winbindd
code where 'winbindd_pam_auth_send' seems like it easily be called
without WBFLAG_PAM_KRB5 being set in the flags, if called for a trusted
domain user then the it will fall into the samlogon leg in the domain
winbindd child and afaics fail. It's the parent winbindd that will do
the routing and it looks like in that case it will call the non-primary
domain winbindd child. I see in the public ? wbclient.h api  that a
number of functions mentioned there seem to call WINBINDD_PAM_AUTH with
no mention of any KRB5 flags. It seemed to me to make sense to fallback
in this scenario too, however I am not really familiar with this stuff
and can easily have missed something (or made a wrong assumption)

thanks,
Noel