It often helps to see if you can break down the problem into independent pieces. Does EAP work elsewhere? etc. As I mentioned, it is successfully authenticating supplicants using PEAP-MSCHAP against an AD database.
The debug output: Ready to process requests. rad_recv: Access-Request packet from host 10.25.22.31 port 49181, id=0, length=118 > NAS-IP-Address = 10.25.22.31 > NAS-Port-Type = Ethernet > NAS-Port = 76 > User-Name = "28d2441b77c9" > Acct-Session-Id = "050004EE" > Calling-Station-Id = "28-D2-44-1B-77-C9" > EAP-Message = 0x0200001101323864323434316237376339 Message-Authenticator = 0x0c1c468757ad8814bb6dae782e1ac927 Which looks like EAP, not a MAC auth request. It seems that the switch simply extracts the soruce MAC from any traffic, then sends that as the username and password. This actually seems desirable, as it doesn't require an actual 802.1X supplicant on the user end, and I would think this would allow FreeRADIUS to process it like any standard EAP request. WARNING: !! EAP session for state 0x8246357d82472c19 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility That should be a hint. Did you read that page? Yes; although that warning appears in the debug logs for our current auth method, it has not interfered with authentication thus far. [eap] Response appears to match, but EAP type is wrong. The EAP supplicant is broken. FreeRADIUS sent it PEAP, and it responded with EAP-MD5. Take the switch, and throw it in the garbage. It's garbage. The switch is *not* garbage. It's one of half a dozen SG500's in the network, which, general reliability aside, have a 0% chance of being replaced. Regardless, how did you know it was EAP-MD5? And is that the reason for its failure? 1) Why does finding the user in SQL not seem to count for authentication (is it supposed to return updated)? Because that's how it works. Finding the user is just ONE piece that's required. If you put gas in your car, it might not move. It still needs tires, and engine, etc. So are the other parts in this analogy radreply items, or something I don't quite grasp? 2) Why does FreeRADIUS continue on to try LDAP, even showing it as the exclusive reason for failure? You told it to use SQL then LDAP. And no, it does *not* show LDAP as the exclusive reason for failure. Read the debug log. Okay, will do. I just assumed from the Login incorrect ( [ldap] User not found): [28d2441b77c9] part of the log. 3) What am I missing that will cause an Access-Accept if a user is found in SQL? Because EAP requires a series of back & forth messages in lock-step. The server is doing it correctly. The switch isn't. So the problem is the EAP type mismatch with the switch?
Christopher Kuhn wrote:
It seems that the switch simply extracts the soruce MAC from any traffic, then sends that as the username and password. This actually seems desirable, as it doesn't require an actual 802.1X supplicant on the user end, and I would think this would allow FreeRADIUS to process it like any standard EAP request.
That's fine so far.
WARNING: !! EAP session for state 0x8246357d82472c19 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility
That should be a hint. Did you read that page?
Yes; although that warning appears in the debug logs for our current auth method, it has not interfered with authentication thus far.
It indicates that there's a problem. Would you ignore a large red warning light on your car dashboard?
[eap] Response appears to match, but EAP type is wrong.
The EAP supplicant is broken. FreeRADIUS sent it PEAP, and it responded with EAP-MD5.
Take the switch, and throw it in the garbage. It's garbage.
The switch is *not* garbage. It's one of half a dozen SG500's in the network, which, general reliability aside, have a 0% chance of being replaced.
I really don't care. It's garbage. It's not following the EAP specifications. That is the root cause of the problem.
Regardless, how did you know it was EAP-MD5?
Because I can read the protocol traces from the hex EAP-Message. I've been doing this for ~15 years now.
And is that the reason for its failure?
No. The failure is because FreeRADIUS tells the switch "Let's do EAP-TTLS" (or whatever). The switch responds with "OK, I'm doing EAP-MD5". That's broken. The switch SHOULD respond with an EAP NAK saying "No, I don't want EAP-TTLS. I want EAP-MD5". But it doesn't. So it's garbage.
So are the other parts in this analogy radreply items, or something I don't quite grasp?
EAP depends on a large number of independent pieces. If one works, that doesn't mean EAP will succeed. They ALL need to work.
So the problem is the EAP type mismatch with the switch?
The problem is that the switch isn't following the EAP protocol. I don't care if you have a million other identical switches that work perfectly. This one is broken. Your choices are: a) use a working switch b) force FreeRADIUS to use EAP-MD5 for this switch. e.g. authorize { ... if (switch x) { update control { EAP-Type := MD5 } } eap ... } (a) will always work. (b) *might* work, but there's no guarantee. Once the switch refuses to follow proper procedure, *anything* can happen. You're better of fixing the switch than adding crap to your FreeRADIUS configuration. If all of the other switches behave this way, file a bug report with Cisco. Alan DeKok.
participants (2)
-
Alan DeKok -
Christopher Kuhn