Question on ntlm_auth tool

[Yimin Chen]

Hi Andrew,


Thank you very much for your reply! I have some more questions inline :)


Andrew Bartlett wrote:
> On Fri, 2004-09-10 at 10:02, Yimin Chen wrote:
> 
>>Hi Andrew,
>>
>>Thank you very much for the suggestion. I wasn't aware at all that 
>>winbind_request APIs are not for external use.
>>
>>
>>Now Looking at the ntlm_auth tool again, I have a few more questions:
>>
>>1) What is the option to retrieve the challenge from the server? In the 
>>NTLM authentication case, we need to pass the challenge back to client, 
>>and then retrieve the NT LM responses from client response, and pass the 
>>callenge as well as the NT LM responses to the ntlm_auth tool, right?
>>
>>I must have missed something, but can't figure out.
> 
> 
> Are you doing NTLM or NTLMSSP?  What is the target protocol?  (MSCHAP?
> MSCHAPv2?  NTLMSSP/HTTP?)

[YM] It is HTTP ntlm authentication that we are trying to do. So I guess 
it is NTLMSSP/HTTP? What is the difference between NTLM/NTLMSSP? I had 
thought they are same.


> 
> Fundamentally, ntlm_auth operates as a privileged client in the domain,
> and the challenge is either generated inside the helper, or supplied to
> it, depending on mode of operation.

[YM] I see. Could you please clarify for me whether my following 
understanding is correct?

So the client machine our proxy process running should first join the 
domain as a privileged client, and then the proxy process can generate 
the challenge ourselves every time we want to authenticate an HTTP 
client, and then pass the challenge/NT LM responses to the ntlm_auth 
binary to authenticate the user. Is this correct? Or ntlm_auth will 
itself join the domain automatically?


> 
> 
>>2) Is there a dynamic library API instead of binary calls of ntlm_auth 
>>that we can use to achieve the ntlm authentication? Invoking API calls 
>>could have lower overhead than binary calls.
> 
> 
> Not at this stage - it was decided that a fork()/exec() interface
> allowed for the best compatibility going forward, as well as a clear
> licence boundary.  There are proposals for a shared lib interface for
> other winbind functions, but I don't yet see the need to extend it here.
> 
[YM] Ok.


Thanks!
Yimin


> Andrew Bartlett
>