Must set auth-type - but why?
John Horne
john.horne at plymouth.ac.uk
Fri May 11 13:40:22 CEST 2007
Hi,
I am in the process of upgrading a couple of servers from using
FreeRadius 1.0.1 (on FC3), to FreeRadius 1.1.6 (on CentOS 5). In our
'users' file we have a few entries such as:
bob Auth-Type = Local,User-Password := "abc",Proxy-To-Realm := LOCAL
This works fine with FR 1.0.1. By default we proxy all requests with the
NULL realm, so the 'Proxy-To-Realm' had to be included. These users
(listed in the 'users' file) connect from Windows XP clients using
MS-CHAPv2.
However, with FR 1.1.6, this type of user entry failed. After some
investigating of the list archives, I saw that the use of Auth-Type
generally seemed not to be required. FreeRadius would work out what to
do.
It didn't. I removed the Auth-Type and still got login failures. The
following however, setting the Auth-Type, did work:
bob Auth-Type = MSCHAP,User-Password := "abc",Proxy-To-Realm := LOCAL
Whilst trying to sort this out, I noted Alan DeKok's comments (in the
list archives) that generally Auth-Type does not need to be set (or
indeed should *not* be set), and that FR will do the right thing. I am,
therefore, a bit concerned that in this instance it seems that Auth-Type
must be set for FR to work. I am wondering if this is because I have
perhaps made some other error in the radiusd.conf file.
Using FR 1.1.6, and running 'radiusd -X', I see failures when not using
Auth-Type, and this is in fact exactly the same as if I used 'Auth-Type
= Local':
==================================================================
rad_recv: Access-Request packet from host 127.0.0.1:33137, id=20,
length=149
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "bob"
MS-CHAP-Challenge = 0xb3b1f660b5ea874b1c876ca0c058e629
MS-CHAP2-Response =
0xe0008a5ba595d775a04d4169716641ae087e0000000000000000da72659a62c6a221bd42a1079c1114f714f46bc286ab4047
Calling-Station-Id = "141.163.60.7"
NAS-IP-Address = 141.163.199.250
NAS-Port = 0
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 0
users: Matched entry bob at line 8
modcall[authorize]: module "files" returns ok for request 0
rlm_mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
modcall[authorize]: module "mschap" returns ok for request 0
rlm_realm: No '@' in User-Name = "bob", looking up realm NULL
rlm_realm: Found realm "NULL"
rlm_realm: Adding Stripped-User-Name = "bob"
rlm_realm: Proxying request from user bob to realm NULL
rlm_realm: Adding Realm = "NULL"
rlm_realm: Preparing to proxy authentication request to realm "NULL"
modcall[authorize]: module "suffix" returns updated for request 0
modcall: leaving group authorize (returns updated) for request 0
WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm!
Cancelling invalid proxy request.
rad_check_password: Found Auth-Type
auth: type Local
auth: No User-Password or CHAP-Password attribute in the request
auth: Failed to validate the user.
Login incorrect: [bob] (from client localhost port 0 cli 141.163.60.7)
Cancelling proxy as request was already rejected
Request 0 rejected in proxy_send.
Server rejecting request 0.
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 5 seconds...
rad_recv: Access-Request packet from host 127.0.0.1:33137, id=20,
length=149
Sending Access-Reject of id 20 to 127.0.0.1 port 33137
--- Walking the entire request list ---
Waking up in 3 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 20 with timestamp 464449e2
Nothing to do. Sleeping until we see a request.
==================================================================
As can be seen it says that rlm_mschap sees it is an MS-CHAP request and
sets the Auth-Type. But it then later says:
rad_check_password: Found Auth-Type
auth: type Local
and then fails because of no User-Password or CHAP-Password attribute.
If I set the Auth-Type in the 'users' file, then I get:
=====================================================================
rad_recv: Access-Request packet from host 127.0.0.1:33137, id=21,
length=149
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "bob"
MS-CHAP-Challenge = 0xdc450c11091700477a0d759da792a0a7
MS-CHAP2-Response =
0x8f007bdfb77f958d304d40526eabbcb6cfdf0000000000000000d16a13d382097bbc5cfb8d41468f6422ee9eff3f038f9eab
Calling-Station-Id = "141.163.60.7"
NAS-IP-Address = 141.163.199.250
NAS-Port = 0
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 0
users: Matched entry bob at line 8
modcall[authorize]: module "files" returns ok for request 0
rlm_mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
modcall[authorize]: module "mschap" returns ok for request 0
rlm_realm: No '@' in User-Name = "bob", looking up realm NULL
rlm_realm: Found realm "NULL"
rlm_realm: Adding Stripped-User-Name = "bob"
rlm_realm: Proxying request from user bob to realm NULL
rlm_realm: Adding Realm = "NULL"
rlm_realm: Preparing to proxy authentication request to realm "NULL"
modcall[authorize]: module "suffix" returns updated for request 0
modcall: leaving group authorize (returns updated) for request 0
WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm!
Cancelling invalid proxy request.
rad_check_password: Found Auth-Type MSCHAP
auth: type "mschap"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
rlm_mschap: Told to do MS-CHAPv2 for bob with NT-Password
rlm_mschap: adding MS-CHAPv2 MPPE keys
modcall[authenticate]: module "mschap" returns ok for request 0
modcall: leaving group authenticate (returns ok) for request 0
Login OK: [bob] (from client localhost port 0 cli 141.163.60.7)
WARNING: Cancelling proxy to Realm LOCAL, as the realm is local.
Sending Access-Accept of id 21 to 127.0.0.1 port 33137
MS-CHAP2-Success =
0x8f533d31334430304342353844313130454643343131313043333241424237434145394236454443454531
MS-MPPE-Recv-Key = 0x273434105c0ed9fc6e57a499d5abffee
MS-MPPE-Send-Key = 0x98eed82e84689dc22315e6d3d83733f8
MS-MPPE-Encryption-Policy = 0x00000002
MS-MPPE-Encryption-Types = 0x00000004
Finished request 0
=====================================================================
As can be seen the Auth-Type in the users file is seen and rlm_mschap
now does the right thing:
rlm_mschap: Told to do MS-CHAPv2 for bob with NT-Password
In the radiusd.conf file, which is basically the same from FR 1.0.1 to
1.1.6, the relevant (I hope) sections are:
=====================================================================
modules {
pap {
auto_header = yes
}
$INCLUDE ${confdir}/eap.conf
mschap {
# - this line used in FR 1.0.1 authtype = MS-CHAP
use_mppe = yes
require_encryption = yes
require_strong = yes
}
[ rest of modules section snipped ]
authorize {
preprocess
eap
files
mschap
suffix
}
authenticate {
Auth-Type PAP {
pap
}
mschap
eap
}
=====================================================================
So my question is, does anyone have an explanation for this behaviour?
Obviously it is great that our 'users' files entries work under
FreeRadius 1.1.6 with only a minor change. However, since generally
Auth-Type should not be required, it is a worry that we *have* to set it
to get FR to work. Since the radiusd output shows that FR sees this is
an MS-CHAP request, I would have thought it would handle it correctly.
It doesn't, but instead treats it as a 'Local' type request.
Thanks,
John.
--
---------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: John.Horne at plymouth.ac.uk Fax: +44 (0)1752 233839
More information about the Freeradius-Users
mailing list