Question on ntlm_auth tool

[Andrew Bartlett]

On Sat, 2004-09-11 at 03:09, Yimin Chen wrote:
> Hi Andrew,
> 
> 
> Thank you very much for your reply! I have some more questions inline :)
> 
> At 06:44 PM 9/10/2004 +1000, 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.

When I talk about these authentication protocols, I refer to any scheme
that just passes 8 bytes of challenge, and 24/>=24 bytes of response as
an NTLM client.  This is typical in CIFS, before 'extended security'. 
MS would also calls this MSCHAP, because this exactly what they did for
their PPP and VPN solution (gag!).

NTLMSSP is the blob-based authentication scheme, where the client
intiates the session with a much longer NTLMSSP 'Negotiate' packet,
which any intermediate application does not need a parse.  The design of
this protocol is such that NTLMSSP should be passed to the 'security
engine' unmodified.  (ntlm_auth takes the role of SSPI, if you
application was on Windows)

You may have code, such as the apache 'mod_ntlm' or similar that parses
this code.  This should not be used, in any way.  Instead, by passing
the entire blob to Samba's ntlm_auth, it can parse it, and handle the
whole process.  

Then ntlm_auth generates the challenge internally, and wraps it up in an
NTLMSSP challenge packet, and asks your application to return it to the
client.   ntlm_auth then expects an NTLMSSP negotiate packet, which
included details about usernames and passwords inline.

At no stage should you ever need to base64 decode the NTLMSSP data from
the client, as ntlm_auth expects it unmodified (and conveniently, it
expects it in base64 :-).

> >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?

Incorrect.

You must use Samba tools to join Samba to the domain, and configure
winbind to talk to the domain controller.  Then Samba's ntlm_auth can be
asked to handle the entire NTLMSSP layer.  It will return a username,
and as per our earlier conversation, could be asked to return a series
of groups.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at samba.org
Authentication Developer, Samba Team            http://samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040911/58790f8b/attachment.bin