Re: New Auth configuration options

"Amos Jeffries" <squid3_at_treenet.co.nz> wrote in message
news:6a344dc47f7a230a7cf24e0a5bed7b8b_at_treenet.co.nz...
> On Sun, 6 Mar 2011 12:39:28 -0000, Markus Moeller wrote:
>> "Amos Jeffries" <squid3_at_treenet.co.nz> wrote in message
>> news:4D73721E.4000601_at_treenet.co.nz...
>>> On 06/03/11 00:46, Markus Moeller wrote:
>>>>
>>>> "Amos Jeffries" <squid3_at_treenet.co.nz> wrote in message
>>>> news:4D718401.6050404_at_treenet.co.nz...
>>>>> On 05/03/11 05:41, Markus Moeller wrote:
>>>>>> Do you have an idea how such a wrapper would work ?
>>>>>>
>>>>>> The issue I see is that the wrapper helper must do the same process
>>>>>> management as squid. Which I think is quite some duplication.
>>>>>>
>>>>>> Markus
>>>>>>
>>>>>
>>>>> Squid already does the tri-state response handling similarly for
>>>>> Negoatite and NTLM auth schemes. The blob decoding and response state
>>>>> is entirely up to the helper.
>>>>>
>>>>> I think the wrapper just needs to decode the blob and do either NTLM
>>>>> challenge+validate or Kerberos validate on the result depending on
>>>>> what detail it gets.
>>>>>
>>>>
>>>> So squid keeps state to which helper instance the NTLM challenge was
>>>> send too ?
>>>
>>> Yes, and whether there is a challenge pending blocking it from other
>>> uses.
>>>
>>
>> Good
>>
>>>>
>>>>> A flag internally to determine that an NTLM validate is the next state
>>>>> after challenge will be needed to avoid sending NTLM challenge then
>>>>> validating the follow-up with Kerberos.
>>>>>
>>>>
>>>> I really don't want to program all of that. I just would like to hand
>>>> it
>>>> over to the existing squid_kerb_auth or ntlm_auth helper after
>>>> identification of the blob beeing NTLM or not. But if I hand the token
>>>> over squid_kerb_auth or ntlm_auth will get into an endless loop and
>>>> won't return to my wrapper.
>>>>
>>>> Does that make sense ?
>>>
>>> Nope. Sorry. Is the wrapper calling itself recursively when the first
>>> sub-lookup results in failure?
>>>
>>>
>>> The only loop I can see is when Negotiate/NTLM challenge-response
>>> arrives. If the wrapper pases it to Kerberos it may have bad
>>> consequences, though I'm not certain. If Kerberos can validate the NTLM
>>> challenge responses safely that simplifies things a lot.
>>>
>>> As for programming, we have a libntlmauth library bundled with Squid
>>> which has NTLM decoder functions and "struct ntlmhdr" definitions in it.
>>>
>>> Code would be something like:
>>>
>>> flag = unset
>>> while(fgets(input)) {
>>> base64decode(input, output);
>>> validation_reply = ntlm_validate_packet((struct ntlmhdr*)output,
>>> <type 3 packet>);
>>> if (validation_reply && flag != doing_ntlm) {
>>> ... get result form kerberos ...
>>
>> Here I see a problem. I asume I can re-use the existing helpers.
>> How do I start it and get data to and from it ?
>
> That would be via fork() or vfork() earlier during startup setting up a
> pair of pipes to the other helper.
>

OK. That is what I thought might work.

>>
>>> } else {
>>> flag = unset
>>> ... get result or challenge from NTLM ...
>>
>> Same here.
>>
>>> if result is challenge
>>> flag = doing_ntlm
>>> }
>>> ... pass result to squid
>>> }
>>>
>
> Amos
>

Markus
Received on Sun Mar 06 2011 - 23:39:06 MST