On Mar 17, 2006, at 5:45 PM, Phil Mayers wrote:
George C. Kaplan wrote:
Or you're using an authentication method (Kerberos, in my case) that
isn't one of the standard methods assocated with the authorization
module. (As Alan points out, you have to know what you're doing
to make
this work).
Hmm. PAP seems to be the big problem area in these situations. I
have a notion the correct thing would be:
[...]
Right; you configure each authorization module to set the appropriate
Auth-Type.
Sort-of bad example. In theory, you should only ever need to set
that if you have >1 competing module for a particular Auth-Type. My
example did, your use case by the sounds of it does not.
I don't think I understand your examples. A NAS is sending a User-
Name and User-Password, and somehow I have to tell radiusd, "Use
Kerberos to authenticate these users." I don't see how I can do that
except by setting 'Auth-Type = Kerberos' *somewhere*.
Out of interest, are you finding rlm_krb5 stable? Under high
concurrency?
Yes, except (and it's a big "except") for signals. I posted
something about this a little while ago: when radiusd gets a HUP or
TERM signal, it sometimes becomes unresponsive, using 98% CPU. A
'kill -9' is usually necessary to get it unstuck. I'm not sure, but
I think it happens when a signal arrives just as rlm_krb5 is being
called.
If I don't signal the daemon, it hums along with no problems.
--
George C. Kaplan [EMAIL PROTECTED]
Communication & Network Services 510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
