PEAP/EAP-MSCHAPv2 module modification problem

Alan DeKok aland at
Thu May 23 16:17:18 CEST 2013

Ivan Ostres wrote:
> On 5/23/13 2:59 PM, Alan DeKok wrote:
> The thing is that I need to use (1) whenever possible so I can do the
> lookup in (1) while in rlm_eap and simply do
> "pairmake_config("NT-Password",....). 

  As I said, your design is wrong.

  The EAP module SHOULD NOT be doing password lookups to external systems.

  And the server really isn't set up for things like "try authentication
1, if it fails, try authentication 2".

> Then in eap-mschapv2 handler I
> need to check whether this password is ok (I can do that by checking
> response from peer and then if password appear to be wrong I need to
> contact (2) to check whether password is really wrong or just  (1) was
> wrong. If password in (2) is correct, I need to update record in (1).

  Keeping systems in sync is really outside of FreeRADIUS.  But you can
do what you want in the default configuration.  All you need is to
create a module which looks up passwords in (1) or in (2).

> Since I don't want to open new connection to (1) and (2) for every
> authentication

  You don't.  That's why the git "head" has a connection pool API.  See
rlm_sql, rlm_ldap, rlm_redis, etc.

> I wanted to keep connections open in rlm_eap module
> instead in eap-mschapv2 handler but somehow I need to know whether
> password from (1) or (2) was eventually used to update (1) if needed -
> that;s why I asked how can I propagate info from eap-mschapv2 handler
> back to rlm_eap.

  You're asking the wrong question.  You SHOULD be doing this in the
"inner-tunnel" virtual server:

authorize {



authenticate {
	Auth-Type MS-CHAP {
		mschap {
			reject = 1
		if (reject) {
			update reply {
				MS-CHAP-Error !* 0x00


  That will fix the problem.  It will also ensure that your module will
*continue* working when the server is upgraded.  You won't need
source-code patches.

  And you won't be fighting with the internals of the EAP module.  The
whole reason you're having issues is because the module isn't *designed*
to support what you're doing.  Because it's wrong.

  Alan DeKok.

More information about the Freeradius-Devel mailing list