On ons, 2008-05-21 at 00:47 +0100, Markus Moeller wrote: > Yes I know it is out of squids control. I hoped someone has experienced this > before and has a way to handle the IE negotiate response with NTLM. I was > expecting to see the same NTLMSSP packets inside the negotiate exchange as > in the pure ntlm exchange and I am wondering if it stops me forwarding the > NTLM packets to auth_ntlm for processing. Forwarding them to an NTLMSSP provider should work even without the workstation or domain nae. Those are optional strings. The NEGOTIATE packet negotiates the form of NTLM being used and it's attributes. The acual authentication is taking place in the second two packets (challenge and response). If the client and server had agreed beforehand on what NTLM flavor to use they could in theory skip the NEGOTIATE packet.. Only when all three have contacted is the domain controller contacted to verify the result, using the response packet + challenge parameters from the challenge packet.. At least that's what i remember from the old days when we were digging into the NTLM protocol exchanges, before handing that off completely to the Samba group. Regards Henrik
Attachment:
signature.asc
Description: This is a digitally signed message part
