RFC Reroute samlogon for trusted child domain user if samlogon fails
nopower at suse.com
Tue Nov 17 14:13:01 UTC 2015
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
>>>>> with 3.6.x to do with this issue) so I ran with the possibly
>>>>> unacceptable solution. Please find the attached patch, it seems
>>>>> fine but..., anyway would be really great to get some
>>>> 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
>>>> request. Now I understand why you were so worried.
>>>> The main issue is that this is client-controlled data, the client
>>>> 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
>>> the 2 patches but of course I would like to see if anyone would
>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6607 bytes
Desc: not available
More information about the samba-technical