Hi,
Which leave the EAP-MD5 case,
which shouldn't be used at all these days. It's 2014.
since this one will be EAP and the server will not create an inner-tunnel.
Supporting this would still force me to invoke my SQL in all Access Request packet no?
I believe there is also an attribute EAP-Type which you could use with unlang a la: if ( !EAP-Message || ( EAP-Message && EAP-Type == "MD5-Challenge" ) ) { your_module } but I never had to do any such thing. Try it, and if it doesn't work, wait for someone else to pick up the thread. Meanwhile, I'll walk away scratching my head why someone would use EAP-MD5 anyway. Greetings, Stefan Winter
2014-03-27 10:21 GMT-04:00 Stefan Winter <stefan.winter@restena.lu <mailto:stefan.winter@restena.lu>>:
Hi,
> But if I put it under inner-tunnel/authorize will it still work with > PAP/CHAP (without 802.1x) and EAP-MD5 and others which are not using an > inner-tunnel? Since I can't known in advance when each will be used. > It is my understanding that for those without inner-tunnel I need to put > the code in the main authorize as well as within the inner-tunnel, which > will result in expensive SQL calls when 802.1x will be used because the > main global authorize will then be invoked.
Well, you could have mentioned in your initial post that you are also considering non-EAP scenarios. You didn't, so my reply was limited to EAP.
If you do non-EAP, then yes, your module needs to be in default/authorize - but it can be skipped if there *is* an EAP-Message attribute in the request.
Something like this inside default/authorize should do (v2; probably also works on v3):
if (!EAP-Message) { your_module }
Depending on your setup, you could also work with different virtual servers; instead of having "default", make it "default-eap" and "default-other"; one has your module in authorize, the other not. You then need to make sure that the non-EAP clients are processed by the default-other virtual server and vice versa.
Greetings,
Stefan Winter
> > > > 2014-03-27 8:58 GMT-04:00 Stefan Winter <stefan.winter@restena.lu <mailto:stefan.winter@restena.lu> > <mailto:stefan.winter@restena.lu <mailto:stefan.winter@restena.lu>>>: > > Hi, > > this is a usage question, redirecting to -users. > > You should call your module only in innner-tunnel/authorize, not in the > outer request (default/authorize). > > Greetings, > > Stefan Winter > > On 27.03.2014 13 <tel:27.03.2014%2013> <tel:27.03.2014%2013>:53, Yannick Koehler wrote: > > Hi, > > > > I have an authorization module to write for FreeRADIUS that does a > > fair amount of CPU intensive SQL queries 1-2 seconds time. But the > > problem is that when a 802.1x authentication is occuring this event > > occurs many times 4-5 times at each reception of RADIUS Access > Request. > > Also, at that time the username is not the final one (normally the > final > > one is sent within the MSCHAPv2 from within the TLS tunnel used by > PEAP > > or EAP-TLS or EAP-TTLS). > > > > Is there a way for my authorization module to trigger the work to be > > done only if EAP is at the stage of handling the internal > > authentication? Can for example my module communicate with the EAP > > module and look at an internal flag somewhere to know if the TLS > tunnel > > has been completed? > > > > I would like the following: > > > > Access Request (EAP identity response) -> authorization module - no > > CPU intensive > > <-- Access Challenge (EAP TLS Server Hello) > > > > Access Request (EAP TLS Client Hello) -> authorization module - no > > CPU intensive > > <-- Access Challenge > > > > etc. until TLS is established > > > > Access Request (EAP TLS MSCHAPv2) -> authorization module - CPU > > intensive query > > <-- Access Accept > > > > -- > > Yannick Koehler > > > > > > > > - > > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/devel.html > > > > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 <tel:%2B352%20424409%201> <tel:%2B352%20424409%201> > Fax: +352 422473 <tel:%2B352%20422473> <tel:%2B352%20422473> > > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 > > > > > -- > Yannick Koehler > Courriel: yannick@koehler.name <mailto:yannick@koehler.name> <mailto:yannick@koehler.name <mailto:yannick@koehler.name>> > Blog: http://corbeillepensees.blogspot.com
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg
Tel: +352 424409 1 <tel:%2B352%20424409%201> Fax: +352 422473 <tel:%2B352%20422473>
PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-- Yannick Koehler Courriel: yannick@koehler.name <mailto:yannick@koehler.name> Blog: http://corbeillepensees.blogspot.com
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66