Sorry to blather around again, but I read the logs intensively myself and
made some observations.
One thing first, forget about the PHEIN.. user, his authentication
looked up until reboot, I'd say its a different problem maybe not related
or just a consequence of earlier problems.
In all other cases I made the following observations:
1) the authentication cache is pretty ineffective. Actually its still
surprisingly effective. It would be better IMHO if same users always
ended up on the same ntlm-auth process. Maybe make a cheap hash
(sum over user name string characters) and use it to map to the
ntlm-auth process. For load balancing maybe send requests to the next
free ntlm-auth process. But then remember where that user was
authenticated and send all following requests for him to the same
process.
Ideally there should be one process per user and the pw cache in squid
itself (or shared mem between ntlm-auth processes), IMHO.
2) Authentication never fails the first time. Or other way around, when
Authentication has failed and we got disconnected, after the reconnect
when (libntlmssp.c:153):Connecting to server was printed.
Then the next authentication succeeds (even when for the same user).
This does not hold for the automatic reconnects now done. But I
heard something this is also due to the now invalidated challenge?
Anyway, urgent question/suggestion (might even try to hack it together
tonight): What happens if we voluntarily disconnect after each successful
Authentication? I'd really like to have that as an option to ntlm_auth.
Maybe the DC just thinks: Hey you process on TCP/netbios session xyz on
machine abc, you really should decide now as which user you want to run.
I think for safety we really should startup a new socket
with a new TCP origin port for each authentication. I think it's really
interesting to see how every connection dies after 1 or 2 successful
attempts in a row. I don't know why its sometimes up to 3, maybe some
time matters come in here, or there are other limits based on the
TCP origin port which I didn't see.
It would explain too why test installions with a single or very few users
seem to work but if you have one or two handfuls (5-10) it already
breaks down.
3) And at last a question: What would happen if I restrict myself to 1
ntlm process (to increase cache hits). Assume I'd accept it slowing
down authentication a bit. But if there is currently no authenticator
free, will it just block and wait for a free one or does the user get a
definitive error?
Regards,
Michael.
-- Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de, or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on any machine in the net, it's very likely it's me. -- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Thu Oct 26 2000 - 06:02:05 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:55:58 MST