RE: [squid-users] NTLM authentication in Cache Hierachy

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: hno@marasystems.com [mailto:hno@marasystems.com] On Behalf Of
Henrik Nordstrom
Sent: Thursday, February 13, 2003 7:20 PM
To: Chris Vaughan
Cc: 'squid-users@squid-cache.org'
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
Received on Fri Feb 14 2003 - 01:38:36 MST