> "McNutt, Justin M." <[EMAIL PROTECTED]> wrote: > > 1) FreeRADIUS refuses to authenticate any user who does > not have an = > > account on the local workstation. > > That's most likely the fault of PAM, if the user is trying to log > into the box.
The user is not trying to log into the box. The user is logging into a switch that uses the RADIUS server for authentication/authorization. > PAM does username/password authentication, nothing else. Not so. PAM can provide several different authorization functions as well. Hence the 'auth', 'session', 'account', and 'password' keywords in PAM config files. > > Testing with other services (httpd, sshd) shows that Kerberos and = > > pam_krb5.so are working properly. Cistron RADIUS 1.6.4 did > not have = > > this problem. > > Hmmm.. the FreeRADIUS PAM code is pretty similar to the Cistron PAM > code, so I don't know why there's any difference. I don't know either, which is why I asked. :-) > > 2) There is some difference between the way FreeRADIUS 0.5 > and Cistron = > > RADIUS 1.6.4 respond when there is no user in the > raddb/users file to = > > match an authentication request (and there is no default). > > I don't think so. They both should reject the user. I figured this one out. FreeRADIUS has an option to delay the response. This delay - even if set to only a second or two - is more than the BayStack is willing to wait. By changing the FreeRADIUS server so that it responds immediately, the BayStack acts normally (the reject message appears immediately when authentication fails). > > With Cistron RADIUS, this works. No matter what user name > is used, if I = > > enter the locally-configured password for the switch I can > gain access. = > > However with FreeRADIUS 0.5, the BayStack says "Querying RADIUS = > > server..." and waits forever. > > That is probably a different problem. Use 'tcpdump' to see what's > going on. Yup. Working on it (using Ethereal). --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
