RFC Reroute samlogon for trusted child domain user if samlogon fails

[Noel Power]

On 16/11/15 19:34, Noel Power wrote:
> 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
please see updated patch
>>> 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.

[...]

>  however I am not really familiar with this stuff
> and can easily have missed something (or made a wrong assumption)
ok, I missed entirely the role that WBFLAG_PAM_CONTACT_TRUSTDOM plays
(despite using it in the patch) sorry for the noise


Noel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-If-samlogon-for-trusted-child-domain-user-fails-atte.patch
Type: text/x-diff
Size: 6607 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20151117/69521e58/0001-If-samlogon-for-trusted-child-domain-user-fails-atte.diff>