michele.de-martin@electrolux.it 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
This archive was generated by hypermail 2b29 : Sat Mar 01 2003 - 12:03:35 MST