On 11/01/13 13:23, Meyers, Dan wrote:
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
Wait, what? Seriously? Can you show a debug of one of these requests?
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.
Hang on; is it EAP-MD5, or some "fake" EAP? If it's EAP-MD5, what is the switch using as the password? A fixed value, or the MAC address? You might find it's as simple as doing: authorize { ... if (EAP-Message) { if (User-Name =~ /[0-9a-f]{16}/) { # mac-based auth as EAP-MD5 update control { Cleartext-Password := "%{User-Name}" } } eap } else { my_perl } ... }
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?
Maybe. I'd need to see a debug of one of these horribly broken-sounding EAP requests. If it's actually broken, you're hosed. If it's just doing EAP-MD5 for mac-auth with some fixed or well-known password, you just need to set that password.