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?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
