Re: New Auth configuration options

Hi,

Here is my new helper for negotiate.

Usage:

auth_param negotiate program /usr/sbin/negotiate_wrapper [-d] --ntlm
<ntlm-helper with args> --kerberos <kerberos-helper with args>

example:

auth_param negotiate program /usr/sbin/negotiate_wrapper -d --ntlm
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --kerberos
/usr/sbin/squid_kerb_auth -d -s GSS_C_NO_NAME

Regards
Markus

"Markus Moeller" <huaraz_at_moeller.plus.com> wrote in message
news:il15u9$8p1$1_at_dough.gmane.org...
>
> "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
>
>