Problems with DBM and MS-CHAP

[Tom Griffin]

Hello All,

See below for the original problem.

This issue is still present in 1.1.7. Please can you confirm whether 
this bug has been rectified? The debug output is showing exactly the 
same messages as before.

Many thanks,
Tom Griffin

-------

Alan DeKok wrote:
...
 >/ rlm_mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' /
...
 >/ rad_check_password: Found Auth-Type Local /

Whoops. That looks to be a bug. 1.1.7 should be released this week, to 
fix that, and other issues. Alan DeKok.

-------

Tom Griffin wrote:

Hello,

I am having a problem with Freeradius v1.1.6. We have one server 
(running v1.0.1) which works as we want it to, but when trying to build 
a new v1.1.6 server to act in the same way is proving to be difficult.

All our users are stored in a local DBM database and authentication is 
either by MS-CHAP (when coming via a Cisco VPN 3000 concentrator) or by 
EAP (when coming via Cisco Aironet 1200).

Using the Cisco client (and also the VPN concentrator test function) the 
authentication is successful, the same is true with EAP (ie. the DBM 
module is working). But when using MS-CHAP authentication is rejected. 
Here is the debug output;

rad_recv: Access-Request packet from host xx.xx.xx.xx:1044, id=176, 
length=154
        User-Name = "cs1tg"
        NAS-Port = 4054
        Service-Type = Framed-User
        Framed-Protocol = PPP
        Tunnel-Client-Endpoint:0 = "xx.xx.xx.xx"
        MS-CHAP-Challenge = 0xd1076979a50becf0731656741b3a469a
        MS-CHAP2-Response = 
0x0200ca320fdd144e34edc132ba42560c4619000000000000000064a36039b976de05bc0e340fbd2b5b0b1bff37a302ccc3f2
        NAS-IP-Address = xx.xx.xx.xx
        NAS-Port-Type = Virtual
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
  modcall[authorize]: module "preprocess" returns ok for request 1
    rlm_realm: No '@' in User-Name = "cs1tg", looking up realm NULL
    rlm_realm: No such realm "NULL"
  modcall[authorize]: module "suffix" returns noop for request 1
rlm_dbm: try open database file: /usr/local/etc/raddb/../usradmin/users
rlm_dbm: Call parse_user:
sm_parse_user.c: check for loops
Add cs1tg to user list
sm_parse_user: start parsing: user: cs1tg
parse buffer: <<Auth-Type := Local, User-Password == "BLANKED">>
rlm_dbm: recod parsed
process pattern
rlm_dbm: Pattern matched, look for request
parse buffer: <<Service-Type = Framed-User, Framed-Protocol = PPP, Class 
= "OU=Unishef">>
rlm_dbm: recod parsed
rlm_dbm: Reply found
Remove cs1tg from user list
  modcall[authorize]: module "dbm" returns ok for request 1
  rlm_mschap: Found MS-CHAP attributes.  Setting 'Auth-Type  = mschap'
  modcall[authorize]: module "mschap" returns ok for request 1
  rlm_eap: No EAP-Message, not doing EAP
  modcall[authorize]: module "eap" returns noop for request 1
modcall: leaving group authorize (returns ok) for request 1
  rad_check_password:  Found Auth-Type Local
auth: type Local
auth: No User-Password or CHAP-Password attribute in the request
auth: Failed to validate the user.
Login incorrect: [cs1tg] (from client vpn2 port 4054)


My main concern is the apparent incorrect Auth-Type of 'mschap' rather 
than 'MS-CHAP' that I would have expected to see (which is most likely 
why rad_check_password is falling back to Local).

The interesting thing is that when I disable DBM and add a test user 
locally, the MS-CHAP module successfully authenticates the user, 
suggesting there is some incompatibility between newer versions of 
freeradius, dbm and mschap (since we are using this combination on 
another server with v1.0.1)

Here are the main sections of the config;

modules {
    mschap {
        authtype = MS-CHAP # I have tried with this line blanked also
    }
    dbm {
        usersfile = ${confdir}/../usradmin/users
    }
}
authorize {
        preprocess
        suffix
        dbm
        mschap
        eap
}
authenticate {
        Auth-Type MS-CHAP {
                mschap
        }
        eap
}

I have tried many different orderings of the authorize section as well 
as combinations of variables in the mschap module config, but these have 
all given the same result. The config shown above is the version that is 
working on the older server.

Any help would be greatly appreciated.

Regards,
Tom Griffin