Trying other authentication methods when the first is invalid
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
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.
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).
That phrase is a trigger for me. "contains the MD5 hash of the password" is a horribly vague description. Where is this hash contained? Why is it "contained", and not part of a well-defined EAP type?
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
OK... so it's EAP-MD5. *PLEASE* just say this. "The switch does EAP-MD5 with the MAC address as the password". That's *much* easier than reading a wall of text.
... As soon as eap returns invalid, all further processing is halted for that request and FreeRADIUS jumps straight to the Post-Auth REJECT section.
That's how user rejection works. If you reject the user, you don't keep looking for more things to do.
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,
Huh? You *are* aware that the server comes with an EAP-MD5 module, right? Why not just use that? The "wall of text" indicates to me that you're lost in the weeds looking for a solution. The more you get lost, the bigger the description becomes, and the more complicated the solution. Once you (a) know it's EAP-MD5, and (b) know that the password is the MAC, and (c) know that the MAC is in the User-Name, the solution becomes rather obvious. Do what Phil says. It should work. Alan DeKok.
participants (3)
-
Alan DeKok -
Meyers, Dan -
Phil Mayers