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
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
