Jeffrey Hutzelman wrote:
--On Friday, February 08, 2008 08:19:32 PM +0000 A.L.M.Buxey@lboro.ac.uk wrote:
you MAY need to set "Auth-Type = krb5" for the required user or NAS setting depending on your config!
You will almost certainly have to do something -- there is no way for the rlm_krb5 module to know that you want to use it for veryifying passwords; that's not something that can be inferred from the request.
If all of your clients will be using plain passwords which you want to verify against Kerberos, and you won't be supporting EAP clients, then you can probably get away with something simple like adding the following to the users file:
DEFAULT Auth-Type := krb5 Fall-Through = No
Note that this violates the general advice of never setting Auth-Type, explicitly; this is necessary because rlm_krb5 does not provide any authorize handling and will not set Auth-Type automatically like many other modules do.
s/will not/cannot/? How eould rlm_krb5 run in authorize {} and know that the user is a valid kerberos user without getting a ticket?
If you are trying to support EAP or do something else complicated, then setting Auth-Type explicitly like this will probably break it, unless you are very careful to do so only under circumstances where it is the right thing to do. I'm afraid I can't provide help with that; it's rather complex and really the right thing to do is update rlm_krb5 so it works automatically like everything else. Perhaps someday I'll do that; I doubt the original author of that module cares any longer.
How would you envisage it working? At the moment, the "best" (least worst) option is to use something like this: authorize { preprocess eap mschap files } authenticate { Auth-Type MSCHAP { mschap } Auth-Type KRB5 { krb5 } } ..and in the files have this: DEFAULT Auth-Type = KRB5 For the archives: this is one of the VERY FEW instances where setting Auth-Type is ok. Note the operator "=" rather than ":=" (i.e. set only if unset). That way eap (tunnel outer) or mschap (peap tunnel inner) can take precedence, but fallback would be a PAP request via krb5. "files" has to come last in authorize for that to work safely. FreeRadius 2.0 makes this a bit easier with different virtual servers for inner versus outer tunnel. Another alternative would be to redesign such that the various PAP "oracles" (krb5, pam) are sub-modules of the pap module, perhaps run in a defined order: modules { pap { types { pam { service_name = foo } krb5 { default_realm = FOO.EDU } } default_check_order = pam krb5 } } authorize { preprocess files eap mschap pap } authenticate { Auth-Type MSCHAP { mschap } Auth-Type PAP { pap } } Just a thought. I can see problems with the above system though.