George C. Kaplan wrote:
Phil Mayers wrote:
Sort of. AFAIK nothing else sets Autz-Type. But quite a few modules set
Auth-Type based on the incoming requests e.g. the "mschap" modules sets
Auth-Type=MS-CHAP if the mschap attributes are in the request. Ditto the
"chap" and "eap" modules. "pap" is a bit more complex and has changed in
CVS head.
Generally, you should not set Auth-Type in the users file. It's a sign
you're doing something wrong. Perhaps if you told us what you're trying
to do?
I've been wondering about this, in relation to the rlm_perl module. We
see "Don't set Auth-Type in the users file" all over the place, but with
rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for
authorization, I *have to* set the Auth-Type in the users file.
You shouldn't really ever have to set it AT ALL, EVER, though some of
the fixes that make that a doable proposition are only in newer (CVS?)
versions of FR - e.g. the reworking of the PAP module, optional setting
of the Auth-Type on the ldap module, {algo} detection in the
User-Password field, and so forth.
As far as I can tell, there are really 2 classes of FreeRadius module:
1. Authentication algorithm modules - these do two things:
* in authorize, examine the request for attributes indicating the
request is using the algorithm they implement. If present, set Auth-Type
to AUTHALGO.
* in authenticate, get run by "Auth-Type AUTHALGO" conditionals,
and execute the auth algorithm using the request data and any other data
(e.g. check items added by other modules)
2. Authorization modules that add data to config items (and other
things as well, but mainly that)
There is a special case of the first which hand off "algorithms" to
external sources - for example, the ldap and pam "authenticate" handler
really implements PAP, but by doing something different (and it's
further complicated by the fact that ldap is ALSO an authorization
module AND it's authenticate function is dependent on configure items it
adds at authorize time - specifically Ldap-UserDN)
The only case I can see where you need to Auth-Type is when you have a
need for >1 copy of an authentication algorithm with different
parameters e.g. for different services. This can typically be handled
more cleanly IMHO with Autz-Type. So, for example:
modules {
# shared modules - no state, irrelevant which service they answer
chap {
authtype = CHAP
}
# service 1 modules
mschap mschap1 {
# we'll to MS-CHAP internally
authtype = MS-CHAP1
}
files files1 {
userfile = ${confdir}/users1
}
# service 2 modules
mschap mschap2 {
# we'll call out to ntlm_auth DOMAIN1
ntlm_auth = "/opt/samba_DOMAIN1/bin/ntlm_auth --args"
authtype = MS-CHAP2
}
files files2 {
userfile = ${confdir}/users2
}
# service 3 modules
mschap mschap3 {
# 2nd install of samba e.g. no interdomain trust between domains
# so join both!
ntlm_auth = "/opt/othersamba/bin/ntlm_auth --args"
authtype = MS-CHAP3
}
files files3 {
userfile = ${confdir}/users3
}
}
authorize {
preprocess
files
Autz-Type SERVICE1 {
files1
mschap1
chap
}
Autz-Type SERVICE2 {
files2
mschap2
chap
}
Autz-Type SERVICE3 {
files3
mschap3
chap
}
}
authenticate {
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP1 {
mschap1
}
Auth-Type MS-CHAP2 {
mschap2
}
Auth-Type MS-CHAP3 {
mschap3
}
}
/etc/raddb/users:
DEFAULT Huntgroup-Name=="service1", Autz-Type := "SERVICE1"
DEFAULT Huntgroup-Name=="service2", Autz-Type := "SERVICE2"
DEFAULT Huntgroup-Name=="service3", Autz-Type := "SERVICE3"
This isn't really a problem (since it all works the way I want), but it
seems inconsistent, especially considering that other modules can modify
the request or check items. So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
I can't say specifically in that case. It does seem odd. But that still
doesn't make setting Auth-Type any cleaner ;o)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
