Trying other authentication methods when the first is invalid

[Meyers, Dan]

Sorry for the wall of tet, I'd rather give too much info than not enough.

Our FreeRADIUS server (version 2.1.8 running on Ubuntu 10.04 LTS x64, installed from packages) currently does mac-based authentication of hosts onto edge switches using perl scripts (rlm_perl) talking to the API for our network access control system. I would like to extend this to also be able to support 802.1x based authentication, but only for certain specific networks (ones with access to more important servers or similar. For example the finance network should need 802.1x to auth, but our student residence network shouldn't as then no games consoles and the like would work).

The initial method I had set up was to look for the presence of an EAP-Message in the request in the authorize section, and call the eap module if EAP-Message was present to set Auth-Type to EAP and then do authentication using eap (tls or peap) (and then expect to hand off to perl in post_auth just for the VLAN assignment) or to call the perl module to set Auth-Type as Perl if there was no EAP-Message, and handle it in authenticate as a simple MAC auth using perl. (The reason for not just calling eap then perl all the time is that the rlm_perl module, despite my authorize subroutine containing simply "$RAD_CHECK{'Auth-Type'} = 'Perl'; return RLM_MODULE_OK;", seems to alter the value of User-Name such that calling eap in authenticate *always* fails with the error "Identity does not match User-Name, setting from EAP Identity." and rejects the user if perl has been called in authorize, even if it is called after eap and the eap stanza reads "eap { ok = return }"). This worked fine on our HP Procurve switches.

Anyway, we have got some Juniper EX2200 switches. The problem with these is that they do mac-auth as a 'fake' 802.1x auth. The request has the User-Name attribute set to the MAC address correctly, but also has an EAP-Message present, it just doesn't contain anything we want to have to care about (It actually contains, once the eap header has been decoded, the md5 of the mac-address). This causes the eap module, if called in authorize, to think the request should be handled by itself and set Auth-Type to EAP and expect to do eap-md5 (even if the default-auth-type in eap.conf is set to something else, like peap). However, as we do not actually want to do an eap-md5 auth we have no Cleartext-Password anywhere for the tens of thousands of MAC addresses (with new ones every day, which we auth onto a special 'unregistered' network with limited access instead of rejecting) on our network.

The eap module in this case returns 'invalid' in authentication, rather than 'reject'. I was hoping I could detect this and tell it to move on to perl if this happened. I can't seem to make that work. As soon as eap returns invalid, all further processing is halted for that request and FreeRADIUS jumps straight to the Post-Auth REJECT section. Can anyone suggest a way around this? I was originally thinking that I could use the perl module after eap in authorize to check if the decoded eap data was simply an md5 hash of the MAC, and set Auth-Type to Perl even though there was an EAP-Message in that case, but of course if I ever then do that check on a valid 802.1x auth EAP breaks (as I mentioned above). 

Thanks for any help anyone can offer

-- 
Dan Meyers
Lancaster University