"Henrik Nordström" <henrik@xxxxxxxxxxxxxxxxxxx> wrote in message
news:1270330950.9955.60.camel@xxxxxxxxxxxxxxxxxxxxxxxx
lör 2010-03-27 klockan 18:42 +0100 skrev Khaled Blah:
Hi all,
I'm developing an authentication helper (Negotiate/NTLM) for squid and
I am trying to understand more how squid handles this process
internally. Most of all I'd like to know how and how long squid caches
authentication results. I have looked at the debug logs and they show
that squid seems to do "less caching" for Negotiate/NTLM than it does
for Basic/Digest authentication.
Due to the nature of NTLM & Negotate authentication it's the helper
performing the Negotiate/NTLM handshake, and because of this there is no
cache in Squid for these schemes as there is nothing to use as cache
key.
basic & digest auth is handled internally by Squid, and enables Squid to
cache the credentials validity.
In theory we could implement NTLM in similar manner, but it would then
not be possible to integrate with Windows domain controllers / active
directory.
Don't know enough of Kerberos to tell what possibilities there may be to
cache in Negotiate auth.
In the case of Kerberos each request which has the Negotiate header has data
encrypted with the key which is stored in the keytab. The server will just
decrypt the data with the key from the keytab and if successful return the
username contained in the decrypted data. There is no possibility to cache
anything.
I am wondering whether I can do
something about this so that a once verified user will only get his
credentials re-verified after a certain time and not all during. I am
grateful to any insight the list can give me. Thanks in advance!
In 2.7 there is a generic auth cache based on source IP, useful when the
clients are single-user workstations.
Regards
Henrik
