CPU intensize authorization module issue
Stefan Winter
stefan.winter at restena.lu
Thu Mar 27 15:35:31 CET 2014
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 at restena.lu
> <mailto:stefan.winter at 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 at restena.lu
> <mailto:stefan.winter at restena.lu>
> > <mailto:stefan.winter at restena.lu <mailto:stefan.winter at 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 at koehler.name <mailto:yannick at koehler.name>
> <mailto:yannick at koehler.name <mailto:yannick at 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 at koehler.name <mailto:yannick at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8A39DC66.asc
Type: application/pgp-keys
Size: 3243 bytes
Desc: not available
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140327/04bfaf5f/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140327/04bfaf5f/attachment-0001.pgp>
More information about the Freeradius-Users
mailing list