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