It would seem that option A would be the best one. Just set the parent proxy to only accept requests from the child proxies. This would also spread the load a bit as well. If logging is an issue NFS is a possible solution.
I am not very familiar with NFS, but is it possible for multiple proxies to share one central log file? The windows in me keeps screaming about locks but AFIK this doesn't occur with *nix. If this is not possible then each could keep its own log centrally at least. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Henrik Nordstrom Sent: Thursday, February 13, 2003 7:20 PM To: Chris Vaughan Cc: '[EMAIL PROTECTED]' Subject: Re: [squid-users] NTLM authentication in Cache Hierachy The browser can only authenticate to the first proxy. This is a limitation of the HTTP protocol. It is then the responsibility of this proxy to authenticate to any upstream proxy if required. When using Basic HTTP authentication you can chain the authentication on multiple proxies IFF all of them shares the same password database. See the cache_peer login= option. This also works for Digest if the first proxy is not doing any authentication, but cannot be used for proxying the NTLM authentication scheme. If using NTLM of Digest scheme on the first proxy you cannot forward the authentication of the client to the upstream proxy. Your alternatives are then to either a) Reconfigure the upstream to allow requests from the sibling without requiring authentication b) Use the login= cach_peer option on the sibling to specify which user the sibling should authenticate as to the upstream proxy. Regards Henrik Chris Vaughan wrote: > > Greetings. > > I am trying to authenticate from a sibling cache using ntlm, sending > requests out through a parent. > > If the parent uses NCSA auth, the sibling serves back pages that > cannot be navigated due to authentication failures. > > If the parent is also using ntlm, then a password/userid prompt, that > will not accept any input, appears. > > Any Ideas? > > *************************************************************** > This message is intended for the addressee named and > may contain confidential information. If you are not the intended > recipient, please delete it and notify the sender. Views expressed in > this message are those of the individual sender, and are not > necessarily the views of the Department of Information Technology & > Management. > > This email message has been swept by MIMEsweeper > for the presence of computer viruses. > *************************************************************** ********************************************************** This message was virus scanned at siliconjunkie.net and any known viruses were removed. For a current virus list see http://www.siliconjunkie.net/antivirus/list.html
