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: authorize { preprocess chap mshcap eap files # final auth type pap } authenticate { Auth-Type PAP { # how to auth PAP requests AMODULE # default "unix" BMODULE # default "pap" } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } # why does "eap" not live inside an Auth-Type? Auth-Type EAP { eap } } ...which would approximate the current defaults. What would be really neat for cleanness would be Autz-Type subsections inside authenticate, e.g.: authenticate { Autz-Type SERVICE1 { Auth-Type PAP { pam } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap-DOMAIN1 } } Autz-Type SERVICE2 { Auth-Type PAP { ldap2 } } } Problem is that's not terribly backwards-compatible.
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. Out of interest, are you finding rlm_krb5 stable? Under high concurrency?