Must set auth-type - but why?

11 May 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@plymouth.ac.uk       Fax: +44 (0)1752 233839