Problems with DBM and MS-CHAP - SOLVED!

[Tom Griffin]

Hello,

After some more extensive debugging, I believe we have got to the bottom 
of this issue.

The MS-CHAP module seems to use 'Auth-Type = mschap' (single equals) and 
not 'Auth-Type := MS-CHAP' (colon equals) as described in the comments 
of radius.conf.

Since the dbm module was ran before the mschap module, Auth-Type was 
being set to Local as instructed in the DBM user file. The mschap module 
running after that doesn't change the Auth-Type value since it is using 
SINGLE equals which will never overwrite an existing value. As a result, 
the Local setting remained in place and mschap was never considered.

We have solved this issue by changing the both the order of operation 
for dbm/mschap and by modifying the DBM database for all users.

As for why this issue is not present in version 1.0.1, I do not know. 
But I would like to see the mschap module do Auth-Type := mschap (using 
colon-equals) so it will ALWAYS use mschap if mschap attributes are 
found, regardless of what any earlier modules have set Auth-Type to.

I hope this is of help to anyone in similar situations.

Thanks,
Tom Griffin

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


-- 
Tom Griffin
Data Network Administrator
The University of Sheffield
Corporate Information & Computing Services
285 Glossop Road, Sheffield, S10 2HB

e: t.griffin at sheffield.ac.uk
t: (0114) 222 3013