SQL MAC Authentication

Alan DeKok aland at deployingradius.com
Mon Dec 16 15:17:59 CET 2013


Christopher Kuhn wrote:
> We have now been trying to implement MAC address authentication on the wired network, using a Cisco switch and this same FreeRADIUS server. The goal is to use a MySQL database of MACs to check against. However, testing so far has failed to auth the test machines.

  It often helps to see if you can break down the problem into
independent pieces.  Does EAP work elsewhere?  etc.

> The radius.radcheck table:
> 
> +----+--------------+--------------------+----+--------------+
> | id | username     | attribute          | op | value        |
> +----+--------------+--------------------+----+--------------+
> |  1 | 28d2441b77c9 | Cleartext-Password | := | 28d2441b77c9 |
> |  2 | aabbcc112233 | Cleartext-Password | := | aabbcc112233 |
> +----+--------------+--------------------+----+--------------+

  That's OK.

> 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.

> 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?

> [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.

> What I do not understand:
> 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.

> 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.

> 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.

  Alan DeKok.


More information about the Freeradius-Users mailing list