Hello list, After a bit of digging, I would like to ask a question to ensure this idea is even possible. :) I am running FR 2 on Debian. What I would like to do is have a WPA2 PEAP/MS_ChapV2 Cisco wireless SSID hook into the FR server above. The FR server currently is using rlm_perl to handle authentication and this does work with FR running with -x and a client test using radtest: Sending Access-Request of id 184 to <ip> port 1812 User-Name = "jrichar4" User-Password = "removed" NAS-IP-Address = 127.0.1.1 NAS-Port = 10 rad_recv: Access-Accept packet from host <ip> port 1812, id=184, length=20 on the server I see: rlm_perl: Added pair User-Name = jrichar4 rlm_perl: Added pair User-Password = <removed> rlm_perl: Added pair NAS-IP-Address = 127.0.1.1 rlm_perl: Added pair NAS-Port = 10 rlm_perl: Added pair Crypt-Password = <removed> rlm_perl: Added pair Auth-Type = Perl I wrote some Perl in the rlm_perl code that uses Perl's Authen::Radius to proxy the lookup to a different production FR server containing the set of all users. Neat. I hope to use this server to flip VLANs using $RAD_REPLY{'Tunnel-Private-Group-ID'} based on an eventual db lookup to control wireless machine infections without mutzing with an existing server. When the SSID is wired in, we see this: [peap] Got inner identity 'jrichar4' # Executing section authorize from file /etc/freeradius/sites-enabled/inner-tunnel rlm_perl: Added pair User-Name = jrichar4 rlm_perl: Added pair EAP-Message = 0x0206000c016d736865746b61 rlm_perl: Added pair EAP-Type = Identity rlm_perl: Added pair FreeRADIUS-Proxied-To = 127.0.0.1 rlm_perl: Added pair Crypt-Password = * rlm_perl: Added pair Auth-Type = EAP rlm_perl: Added pair Proxy-To-Realm = LOCAL rlm_perl: Added pair EAP-Type = MS-CHAP-V2 I would prefer the use Auth-Type = Perl in the EAP inner tunnel. Is this possible? I am hoping something simple is amiss as this is close to working! I have only: DEFAULT Auth-Type = Perl in users. In inner tunnel I have: authenticate { .... Auth-Type Perl { perl } ... eap } Do I need to overload anything in eap.conf? Thank you all and kind regards, Josh Richard University of Minnesota Duluth USA
Josh Richard wrote:
What I would like to do is have a WPA2 PEAP/MS_ChapV2 Cisco wireless SSID hook into the FR server above.
OK...
The FR server currently is using rlm_perl to handle authentication and
Please, no. Authentication includes things like EAP. Doing EAP in Perl is not a good idea.
I wrote some Perl in the rlm_perl code that uses Perl's Authen::Radius to proxy the lookup to a different production FR server containing the set of all users. Neat.
Uh... that is an incredibly bad idea. FreeRADIUS already does proxying. Why do it in Perl? You're going to get it wrong.
When the SSID is wired in, we see this:
[peap] Got inner identity 'jrichar4' # Executing section authorize from file /etc/freeradius/sites-enabled/inner-tunnel rlm_perl: Added pair User-Name = jrichar4 rlm_perl: Added pair EAP-Message = 0x0206000c016d736865746b61 rlm_perl: Added pair EAP-Type = Identity rlm_perl: Added pair FreeRADIUS-Proxied-To = 127.0.0.1 rlm_perl: Added pair Crypt-Password = * rlm_perl: Added pair Auth-Type = EAP rlm_perl: Added pair Proxy-To-Realm = LOCAL rlm_perl: Added pair EAP-Type = MS-CHAP-V2
I would prefer the use Auth-Type = Perl in the EAP inner tunnel. Is this possible?
Yes. See raddb/sites-enabled/inner-tunnel
Do I need to overload anything in eap.conf?
No. But in general, this is a terrible idea. FreeRADIUS has proxying and DB plugins. Redoing all of that in Perl is asking for un-needed complexity. Alan DeKok.
On Sat, Feb 26, 2011 at 12:57 AM, Alan DeKok <aland@deployingradius.com> wrote:
Josh Richard wrote:
The FR server currently is using rlm_perl to handle authentication and
Please, no. Authentication includes things like EAP. Doing EAP in Perl is not a good idea.
I was not going to use EAP in Perl, but use Perl to handle additional logic to determine goodness or badness of a client MAC address in the event of an issue. Also being able to dynamically set the user VLAN is potentially useful. Perl is only being used to handle the auth. You are correct, using Radius native Proxying may be a better idea. Thanks.
I wrote some Perl in the rlm_perl code that uses Perl's Authen::Radius to proxy the lookup to a different production FR server containing the set of all users. Neat.
Uh... that is an incredibly bad idea. FreeRADIUS already does proxying. Why do it in Perl? You're going to get it wrong.
Not wrong, just different. Again, loud and clear.
Yes. See raddb/sites-enabled/inner-tunnel
Do I need to overload anything in eap.conf?
No.
Thanks for the direction on the above. Combining both answers to this thread yields a TTLS/PAP solution which avoids challenge-response.
But in general, this is a terrible idea. FreeRADIUS has proxying and DB plugins. Redoing all of that in Perl is asking for un-needed complexity.
In general I agree it may be terrible, but there are aspects of this approach which may yield a more flexible solution... Again, thank you. -josh
participants (2)
-
Alan DeKok -
Josh Richard