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.