> No, adding Basic is not an option because I will have to provide > special "proxy passwords" to the users, or make them enter their > Windows passwords by hand. This is highly undesirable. Once they > logon into Windows, they must have (or not have) Web access > transparently. > > If you know how to achieve SSO with Basic auth, please share. > I have a few idea's for out-of-band SSO, some of which I have experimented with... 1. agent running on AD server(s) looking at event logs for login events. I've done this from Linux using a wmi client but too much load. The proposed agent would run on the windows server, collect IP<->username mappings, and squid would ask "which username is this IP address". Obviously there are shortcomings with this - it only works for domain joined devices, and assumes 1:1 username:IP, which is not true on a multiuser device (terminal server) 2. as above but also an agent looking at Exchange logs (or imap or pop3 etc), which would allow authentication of mobile devices etc as long as they check their email via Exchange. This still has similar shortcomings to #1. 3. some bastardisation of identd. I've posted before about this. Identd assumes that the destination server is asking "who owns this connection" and so only gives port numbers because the IP is assumed from the ident connection (I have patched squid to fake the source address of the destination server so it works in transparent mode). Ident also has some serious security shortcomings, but they wouldn't be hard to solve. This new ident protocol would need: . to access the full details of the connection so a third party (eg squid) could ask who owns the connection) . to provide two-way authentication so that the endpoint would know that squid was authorised to ask about the connection, and so that squid would trust the endpoint to give a proper answer and not fake it . make a single connection between squid and the endpoint, rather than a new ident connection for every tcp connection which is a huge drain on resources. This still has the drawback that it isn't going to work on mobile devices, requires an agent installed on each endpoint, and requires that squid knows enough details about the connection to be able to give the details to the endpoint (a router NAT-ing connections to squid would break this, you'd need to use WCCP), but it would solve the multiuser terminal problem. Some combination of all three of the above would cover pretty much everything, and you could use a captive portal for whatever is left. Apart from the ident fake-the-source-ip-address hack (works quite well!), and the wmi callout from Linux (works but too slow), the rest is just theory, but should be possible. James _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
