PEAP and MAC-auth checking with SQL
Christopher Kuhn
youarethehat at hotmail.com
Mon Mar 31 21:00:43 CEST 2014
Hello,
I'm currently running a FreeRADIUS server which is working just fine authenticating users with PEAP-MSCHAP. I now need to add some functionality which basically amounts to mac authentication. However, due to the way our switch stacks handle it, all requests still come in as some kind of EAP request which includes a username. Requests will be one of two things. Either:
1) Our current, real authentication scheme where we want to use PEAP-MSCHAP for 'DOMAIN\user' (or 'user at domain'). These users need to go through the whole AAA process.OR2) A request where User-Name = Calling-Station-Id; the switch sends an EAP request with the supplicant's MAC as the username. As long as the MAC is on my whitelist, it can be approved.
In either case, I need to check the Calling-Station-Id against a whitelist. If it isn't on the list, it is rejected. If it is there, it either continues through the PEAP-MSCHAP authentication (request type 1), or is approved more-or-less immediately (request type 2). Although I realize the authed_macs function can already do this, I have been told to use SQL for both scalability and to use features like user-group mapping (so we have more information in the accounting database).
Here are my problems/questions:1) Can I use the SQL module to check an attribute (e.g., Calling-Station-Id) irrespective of User-Name during Authorization and still have the User-Name logged during Accounting? If so, can you point me at any particular configuration sections, modules, or attributes I should be working with?
2) Is it appropriate to create different realms for the two different cases? If so, will a virtual server in the realm for my PEAP-MSCHAP still be able to hand off the inner PEAP processing to inner-tunnel virtual server? I only ask the second question because the proxy.conf warns that requests proxied to an internal virtual server may not then be proxied to any other internal or external server.
Thank you,Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140331/95693c0d/attachment.html>
More information about the Freeradius-Users
mailing list