I'm working on fine tuning my radiusd.conf file, and found that I get 13 authorize request to the LDAP server for one XXX (client, request, logon?!). I have 802.1x (RADIUS) enabled on my WiFi router, and when requesting a network on my client, there's 13 authorize requests... Using multilog which logs exactly when every line is done, all 13 requests is done during the same second, but it still seem to be 13 requests... ? The thing that strikes me is that first it returns 'notfound' then on the line below it returns 'updated'... Including my radiusd.conf, the 'users' file (stripped of comments and no sensitive info) (192.168.1.254 is the WiFi Router). Also, in the ldap filter, I have '(!(accountStatus=disabled))' which don't seem to work as expected.. I DO get a failure in the authorization section, but the EAP is still done (and succeedes, hence no failures): Logfile 1 is without the 'accountStatus' attribute, and logfile 2 is with the account disabled... In the disabled state, I get 'only' 12 authorize request for some reason... ? On the other hand (looking closer on a "grep '^ modcall' logoutput") shows that there are NINE requests... ? And that it's enough if ONE authorization module succeeds for the authorization to be OK... ? Attatchments to bug, so the files in question is now on http://bayour.com/problems/freeradius/.
On Wed, 2007-08-22 at 19:29 +0200, Turbo Fredriksson wrote:
I'm working on fine tuning my radiusd.conf file, and found that I get 13 authorize request to the LDAP server for one XXX (client, request, logon?!).
You can reduce this somewhat by doing this: authorize { preprocess eap files Autz-Type INNER { ldap } } ...then in /etc/raddb/users: DEFAULT FreeRadius-Proxied-To == 127.0.0.1, Autz-Type := "INNER" ...which will only run the LDAP auth for the EAP inner request. You'll still see two queries though for PEAP/MSCHAP
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
On Wed, 2007-08-22 at 19:29 +0200, Turbo Fredriksson wrote:
I'm working on fine tuning my radiusd.conf file, and found that I get 13 authorize request to the LDAP server for one XXX (client, request, logon?!).
You can reduce this somewhat by doing this:
authorize { preprocess eap files Autz-Type INNER { ldap } }
...then in /etc/raddb/users:
DEFAULT FreeRadius-Proxied-To == 127.0.0.1, Autz-Type := "INNER"
...which will only run the LDAP auth for the EAP inner request. You'll still see two queries though for PEAP/MSCHAP
I see. I'll try that as soon as my girlfriend leaves again, I can only fiddle with the WiFi router when she's not home :) In the mean time, what does all this do, and why didn't my work? Will this also solve my problem with the ldap query?
Hi,
...which will only run the LDAP auth for the EAP inner request. You'll still see two queries though for PEAP/MSCHAP
I see. I'll try that as soon as my girlfriend leaves again, I can only fiddle with the WiFi router when she's not home :)
In the mean time, what does all this do, and why didn't my work? Will this also solve my problem with the ldap query?
upgrading to 2.0 CVS should also reduce the number of calls as its sorted the EAP out a lot. in answer to your question 1) proxy part makes sure that only INNER is called when its proxied to 127.0.0.1 2) INNER Auth part ensures that the ldap module is only called for the INNER part of the check...not for everything else. also very very useful as it stops outer ID junk and debris from being checked. alan
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
DEFAULT FreeRadius-Proxied-To == 127.0.0.1, Autz-Type := "INNER"
1) proxy part makes sure that only INNER is called when its proxied to 127.0.0.1
Ok, think I got this. Does it matter WHERE in the file this DEFAULT is? And is the keyword 'INNER' important? I.e. Can it be any word, or must it be just 'INNER' (uppercased and all)?
2) INNER Auth part ensures that the ldap module is only called for the INNER part of the check...not for everything else. also very very useful as it stops outer ID junk and debris from being checked.
What IS 'the INNER part' (may depend on the answer on my first question above) as opposed to 'the outer'? In context I get the general idea, but the actual definition on INNER and OUTER?
On Fri, 2007-08-24 at 13:49 +0200, Turbo Fredriksson wrote:
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
DEFAULT FreeRadius-Proxied-To == 127.0.0.1, Autz-Type := "INNER"
1) proxy part makes sure that only INNER is called when its proxied to 127.0.0.1
Ok, think I got this. Does it matter WHERE in the file this DEFAULT is? And is the keyword 'INNER' important? I.e. Can it be any word, or must it be just 'INNER' (uppercased and all)?
You'll need to understand how the "users" file is processed to grasp that. Please see doc/processing_users_file for more info.
2) INNER Auth part ensures that the ldap module is only called for the INNER part of the check...not for everything else. also very very useful as it stops outer ID junk and debris from being checked.
What IS 'the INNER part' (may depend on the answer on my first question above) as opposed to 'the outer'? In context I get the general idea, but the actual definition on INNER and OUTER?
You're getting hung up on the specifics, which is probably my fault for giving minimal info; Autz-Type is a general mechanism. Please see doc/Autz-Type for more info.
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
2) INNER Auth part ensures that the ldap module is only called for the INNER part of the check...not for everything else. also very very useful as it stops outer ID junk and debris from being checked.
What IS 'the INNER part' (may depend on the answer on my first question above) as opposed to 'the outer'? In context I get the general idea, but the actual definition on INNER and OUTER?
You're getting hung up on the specifics, which is probably my fault for giving minimal info; Autz-Type is a general mechanism. Please see doc/Autz-Type for more info.
I'm only slightly wiser from reading that... Shouldn't 'eap' and 'mschap' be in this Authz-Type to then? ----- s n i p ---- authorize { preprocess auth_log chap mschap digest IPASS suffix realmpercent ntdomain eap files Autz-Type INNER { ldap } } ----- s n i p ---- What I don't understand is why everything is done so many times! The 'authorize' section is done a whole bunch of times, just to authenticate ONE user [request]. If I have undestood the Authz-Type file correctly (which I'm quite sure I haven't), I'd put the whole 'authorize' section in a 'Authz-Type' section! But that can't be right...
On Sat, 2007-08-25 at 21:12 +0200, Turbo Fredriksson wrote:
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
2) INNER Auth part ensures that the ldap module is only called for the INNER part of the check...not for everything else. also very very useful as it stops outer ID junk and debris from being checked.
What IS 'the INNER part' (may depend on the answer on my first question above) as opposed to 'the outer'? In context I get the general idea, but the actual definition on INNER and OUTER?
You're getting hung up on the specifics, which is probably my fault for giving minimal info; Autz-Type is a general mechanism. Please see doc/Autz-Type for more info.
I'm only slightly wiser from reading that... Shouldn't 'eap' and 'mschap' be in this Authz-Type to then?
No
----- s n i p ---- authorize { preprocess auth_log chap mschap digest IPASS suffix realmpercent ntdomain eap files Autz-Type INNER { ldap } } ----- s n i p ----
What I don't understand is why everything is done so many times! The 'authorize' section is done a whole bunch of times, just to authenticate ONE user [request].
No. The authorize section is run once per request. What you are missing is that EAP authentication usually involved two authentication algorithms - an outer versus an inner - and always involves MANY request-response pairs, like so (this is just an indicative example - it's more complex than this): Nas 1: Access-Request EAP-Message (eap-type=foo) Srv 1: Access-Challenge EAP-Message (eap-nak, try type PEAP) Nas 2: Access-Request EAP-Message (eap-type=PEAP) Srv 2: Access-Challenge EAP-Message (first bit of server TLS setup) Nas 3: Access-Request EAP-Message (first bit of client TLS setup) Srv 3: Access-Challenge EAP-Message (complete TLS setup) Nas 4: Access-Request EAP-Message TLS-encrypted(EAP-MSCHAP start) Srv 4: Access-Challenge EAP-Message TLS-encrypted(EAP-MSCHAP challenge) Nas 5: Access-Request EAP-Message TLS-encrypted(EAP-MSCHAP reponse) Srv 5: Access-Challenge EAP-Message TLS-encrypted(EAP-MSCHAP ok) Nas 6: Access-Request EAP-Message TLS-encrypted(EAP-done?) Srv 6: Access-Accept EAP-Message TLS-encrypted(EAP-done?) If you look at the request/response pairs 4 & 5, these are the "inner" request. The way FreeRadius handles these is after TLS-decryprting them, it "proxies" them to itself. When you say: DEFAULT FreeRadius-Proxied-To == 127.0.0.1, Autz-Type := INNER ...and this: authorize { preprocess eap files Autz-Type INNER { ldap } } ...what you are instructing the server is to to this: * for each request, run the modules * preprocess * eap * files * if the Autz-Type is set, then run the modules inside there * inside the "files" request, if this request is an EAP "proxied to myself" request, set the Autz-Type Clear?
If I have undestood the Authz-Type file correctly (which I'm quite sure I haven't), I'd put the whole 'authorize' section in a 'Authz-Type' section!
Well no, obviously not - that would be pointless. For dealing with the EAP inner versus outer requests, one would normally run the bar minimum modules directly in authorize (preprocess, eap, files) then run the rest of the modules only for the inner auth type The upcoming FreeRadius 2.0 handles this better.
Phil Mayers wrote:
I'm only slightly wiser from reading that... Shouldn't 'eap' and 'mschap' be in this Authz-Type to then?
No
I will note that in CVS head (2.0-pre2), this is *much* easier to understand. There's a configuration file for the outer tunnel piece, and a separate one for the inner tunnel.
The upcoming FreeRadius 2.0 handles this better.
Much, much, much, better. One of the reasons that 2.0 has taken so long is that the new features that make it worthy of a "2.0" have only gone in recently. Alan DeKok.
Alan DeKok wrote:
Phil Mayers wrote:
I'm only slightly wiser from reading that... Shouldn't 'eap' and 'mschap' be in this Authz-Type to then?
No
I will note that in CVS head (2.0-pre2), this is *much* easier to understand. There's a configuration file for the outer tunnel piece, and a separate one for the inner tunnel.
Sounds promising. Can you already foresee, when pre2 will be released? Norbert Wegener
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Norbert Wegener -
Phil Mayers -
Turbo Fredriksson