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?