tis 2006-05-23 klockan 12:53 -0400 skrev Michael W. Lucas:
> At times it has seemed that clients attempting to authenticate are
> being rejected despite having good passwords. Similarly, users have
> been able to get out to the Internet without a legitimate username and
> password. Squid's debugging output shows that the authenticator was
> returning an "ok" response for these nonexistent usernames and
> passwords. At the time this happened, we would see "Warning: Received
> invalid reply digest from server" errors. A "squid -k reconfigure"
> made those go away by restarting the authenticator children, of
> course, but running that once a minute is not an ideal solution.
The "invalid digest" indicates the radius server and squid_radius_auth
didn't agree on the shared secret authentication.
> The problem persisted, but I now logged requests that did and didn't
> match and could compare them to the Radius logs. The Radius
> authenticator returned an error when the Radius server had returned
> OK.
As the problem is seen with both radius client implementations I would
suspect there is something fishy going on with your server making it
send out either malformed responses or changing between different
secrets..
> At the time of the error, netstat -na -u on the RHEL box shows:
>
> udp 2352 0 10.184.1.94:33009 10.184.1.56:1812 ESTABLISHED
> lsof shows that the process with the big recv queue is the
> authenticator. This happens with both squid_radius_auth and my perl
> applet.
This is a good hint, especially if combined with the digest error
above..
I think I know what is going in squid_radius_auth here. The code dealing
with retransmits looks a bit fishy..
Regards
Henrik
This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:02 MDT