[RADIATOR] Multiple handlers with inner MSCHAP-V2 authentication

[Heikki Vatiainen]

On 05/18/2011 12:48 PM, Remco van Noorloos wrote:

Hello Remco,

> Currently I'm trying to create a pretty advanced authentication
> mechanism using Radiator. What I'd like to do is to use the same
> procedure (which I've already configured in Radiator for 'normal'
> RADIUS requests) for EAP requests. I feel like I'm almost there, but
> it seems the last step doesn't function as I would expected.

More about that a bit later. About the config, you could try also this:

<Handler Request-Type=Accounting-Request>
    Identifier AccountingHandler
    # The rest as in current AccountingHandler
</Handler>
<Handler>
    Identifier AuthenticationHandler
    # The rest as in current AuthenticationHandler
</Handler>

This would replace the first Handler making the config shorter and maybe
easier to debug too.

> It seems that when Radiator dispatches an inner authentication RADIUS
> request, it's not following the 'normal' procedure. It executes the
> first AuthBy in the correct Handler. This AuthBy normally sets two
> variables which are used further in the authentication procedure.
> With the inner authentication however it quits after a result is
> returned from this SQL AuthBy query and it returns an Access-Reject.
> It should continue since there's an ContinueWhileAccept in top of the
> Handler. The AuthBy returns an Accept as well, but the EAP/PEAP
> module returns a Reject.

With ContinueWhileAccept the behaviour is correct. The result was not
accept, so authentication will not continue.

Note that you seem to get failure from the inner authentication, that is
EAP-MSCHAP-V2 fails, so I'd say this should be a good reason to fail the
whole authentication.

You might also benefit from separating inner authentication handlers
from outer authentication handlers. See for example goodies/eap_peap.cfg

You can catch the inner authentication with something like this:

<Handler TunnelledByPEAP=1>
...

If you could try separating Authentiation and Accounting and post the
results. I can take a look at what happens then.

> Am I missing something or is it a minor bug in Radiator?

In my opinion the policy is working as it should. The whole process
would be easier to follow if you could separate authentiation and
accounting and maybe handle the inner authentication with its own handler.

> Wed May 18 11:34:05 2011: DEBUG: Query is: 'EXEC spGetAuthenticationSource 'PROXSYS\rvannoorloos', 'Wireless-IEEE-802-11', 'Framed-User', ''': 
> Wed May 18 11:34:05 2011: DEBUG: Radius::AuthSQL looks for match with PROXSYS\rvannoorloos [anonymous]
> Wed May 18 11:34:05 2011: DEBUG: Radius::AuthSQL ACCEPT: : PROXSYS\rvannoorloos [anonymous]

Looks like the user was found,

> Wed May 18 11:34:05 2011: DEBUG: EAP result: 1, EAP MSCHAP-V2 Authentication failure

but maybe there's a password problem?

> Wed May 18 11:34:05 2011: DEBUG: AuthBy SQL result: REJECT, EAP MSCHAP-V2 Authentication failure
> Wed May 18 11:34:05 2011: DEBUG: AuthBy HANDLER result: REJECT, EAP MSCHAP-V2 Authentication failure
> Wed May 18 11:34:05 2011: INFO: Access rejected for anonymous: EAP MSCHAP-V2 Authentication failure
> Wed May 18 11:34:05 2011: DEBUG: Returned PEAP tunnelled packet dump:
> Code:       Access-Reject

Thanks!

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.