[EMAIL PROTECTED] wrote: > > Ok, let's go for some scenarios. > > 1) User domain and workstation domain are the same. > Using the domain of the initial negotiate packet we can achieve multiple > not trusted domain authentication.
In theory yes. > 2) User domain differs from workstation domain but the two domains are in a > trust relationship > Given the trust, can we authenticate against the workstation domain instead > of the user one? Yes. > 3) User domain differs from workstation domain and they are not in a trust > relationship. > No hope. Is this a feasible situation? Not much to do in such case, except for setting up a trust relation.. > Anyway. > For points 2) and 3): can we send to the browser a second (and correct) > challenge packet after we receive the client authenticate packet with the > correct domain? I would not expect this to be possible, but you are welcome to try if you like to test the boundaries of the NTLM implemementation in Microsoft browsers.. I would expect the browser to display a login box in such case, as the server rejected the proposed user credentials.. > For me point 1) is the most important: the only one I must face up to. > Is it possible to include point 1) in squid ntlm authentication with some > warning about its limitations? Yes. There is a one-line change to have the client negotiate packet sent to the helper as part of the YR request.. the needed change can be found in the experimental ntlm_smbpasswd branch where I hope(d) to be able to experiment with an implementation of NTLMv2 which requires access to the negotiate packet to function properly.. The ntlm_smbpasswd branch can be found from http://devel.squid-cache.org/projects.html#ntlm_smbpasswd Regards Henrik
