peap/eap change in 3.0.x with inner_eap_module now required
Hi, Heads-up in case my note on github doesn't get seen before 3.0.11 arrives... Just compiled up latest 3.0.x HEAD and now get /srv/radius/mods-enabled/eap[51]: Failed to find 'Auth-Type eap' section. Cannot authenticate users. rlm_eap (outer-eap): Failed to initialise rlm_eap_peap /srv/radius/mods-enabled/eap[7]: Instantiation failed for module "outer-eap" at startup. This was working fine on a previous 3.0.10 (from around November time). EAP modules here are called "outer-eap" and "inner-eap" (for my sanity - we've got PEAP/EAP-TLS, so it's "double-stacked" :-) ) Adding in the new "inner_eap_module" option to the outer PEAP section fixes it (inner_eap_module = "outer-eap") but I'm not sure why it needs to break in 3.0.x? Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Jan 19, 2016, at 12:54 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Heads-up in case my note on github doesn't get seen before 3.0.11 arrives...
Just compiled up latest 3.0.x HEAD and now get
/srv/radius/mods-enabled/eap[51]: Failed to find 'Auth-Type eap' section. Cannot authenticate users. rlm_eap (outer-eap): Failed to initialise rlm_eap_peap
Yup. I added some more sanity checking, and it seems to have broken some configurations. The question is, should we relax those sanity checks, or are the configurations really broken?
EAP modules here are called "outer-eap" and "inner-eap" (for my sanity - we've got PEAP/EAP-TLS, so it's "double-stacked" :-) )
What does the inner-tunnel "authenticate" section? i.e. does it have: authenticate { ... inner-eep ... } or does it have: authenticate { ... Auth-Type EAP { inner-eep } ... }
Adding in the new "inner_eap_module" option to the outer PEAP section fixes it (inner_eap_module = "outer-eap") but I'm not sure why it needs to break in 3.0.x?
It doesn't need to break, of course. But sanity checks are good. The problem was that the PEAP module was *hard-coded* to use "Auth-Type EAP". Which worked fine for situation (2) above, but not so much for situation (1). Hmm... If I configure the inner-tunnel virtual server as (1), I get: /raddb/mods-enabled/inner-eap[15]: Failed to find 'Auth-Type inner-eap' section. Cannot authenticate users. ./raddb/mods-enabled/inner-eap[15]: Instantiation failed for module "inner-eap" That's wrong. Let me go fix that, at least. Alan DeKok.
On Jan 19, 2016, at 2:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
Hmm... If I configure the inner-tunnel virtual server as (1), I get:
No, my bad. It works. So my question again, is how the heck did it ever work when running inner-tunnel, Auth-Type EAP, and there's no "eap" module listed in "authenticate" ? If it breaks peoples systems, I can relax the checks. But I'd like to know just what the heck the system is actually doing. Alan DeKok.
On Tue, Jan 19, 2016 at 02:16:19PM -0500, Alan DeKok wrote:
On Jan 19, 2016, at 12:54 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote: I added some more sanity checking, and it seems to have broken some configurations.
OK. It's entirely possible my config is broken of course :)
The question is, should we relax those sanity checks, or are the configurations really broken?
I'm probably fairly unusual in having an eap instantiation (two even) that's not called "eap".
EAP modules here are called "outer-eap" and "inner-eap" (for my sanity - we've got PEAP/EAP-TLS, so it's "double-stacked" :-) )
What does the inner-tunnel "authenticate" section? i.e. does it have:
authenticate { ... inner-eep ... }
This. Well, default has authenticate { outer-eap } and inner-innel has authenticate { inner-eap } so basically the same as the default configration, except I've renamed the instances from eap to inner/outer-e.ap outer-eap does PEAP, inner-eap does EAP-TLS.
Adding in the new "inner_eap_module" option to the outer PEAP section fixes it (inner_eap_module = "outer-eap") but I'm not sure why it needs to break in 3.0.x?
It doesn't need to break, of course. But sanity checks are good.
Yeah, OK.
The problem was that the PEAP module was *hard-coded* to use "Auth-Type EAP". Which worked fine for situation (2) above, but not so much for situation (1).
But it has always worked for (1) before - that's the default config (albeit with unchanged instance name I admit). On Tue, Jan 19, 2016 at 02:26:57PM -0500, Alan DeKok wrote:
On Jan 19, 2016, at 2:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
Hmm... If I configure the inner-tunnel virtual server as (1), I get:
No, my bad. It works.
So my question again, is how the heck did it ever work when running inner-tunnel, Auth-Type EAP, and there's no "eap" module listed in "authenticate" ?
there is "outer-eap", just not "eap".
If it breaks peoples systems, I can relax the checks. But I'd like to know just what the heck the system is actually doing.
TBH I've never quite got my head around why there is e.g. Auth-Type pap { pap } for everything else, and just eap for the eap module. I've always guessed that if the correct Auth-Type section is set then it uses that section, otherwise it just goes an calls all modules not in a named section in order (as in authorize) and hopes that something picks it up? Guess I should go and read the code.... just haven't ever needed to check this as it's always just worked, albeit looked slightly odd :) Thanks, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Jan 19, 2016, at 3:39 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
I'm probably fairly unusual in having an eap instantiation (two even) that's not called "eap".
I've done some more spelunking, and calling the "eap" module is only done when it's proxying the inner-tunnel EAP data. I've pushed fixes which convert the error into a WARNING, which won't break existing configurations.
TBH I've never quite got my head around why there is e.g.
Auth-Type pap { pap }
for everything else, and just
eap
for the eap module. I've always guessed that if the correct Auth-Type section is set then it uses that section, otherwise it just goes an calls all modules not in a named section in order (as in authorize) and hopes that something picks it up?
It doesn't make much difference. Auth-Type pap { pap } is the same as just pap BUT using the Auth-Type wrapper lets you put policies into the section: Auth-Type back_door { if ((User-Name == "bob") && (User-Password == "bob")) { accept } else { pap } } :) Alan DeKok.
On Tue, Jan 19, 2016 at 03:43:21PM -0500, Alan DeKok wrote:
On Jan 19, 2016, at 3:39 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
I'm probably fairly unusual in having an eap instantiation (two even) that's not called "eap".
I've done some more spelunking, and calling the "eap" module is only done when it's proxying the inner-tunnel EAP data. I've pushed fixes which convert the error into a WARNING, which won't break existing configurations.
OK thanks - I'll push that out right now to test it.
Auth-Type back_door { if ((User-Name == "bob") && (User-Password == "bob")) { accept } else { pap } }
:)
Ssshhhh! Don't put that on a public mailing list. The next question is guaranteed to be "I've just done this with eap, and it doesn't work!!!" :) Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Tue, Jan 19, 2016 at 08:51:40PM +0000, Matthew Newton wrote:
On Tue, Jan 19, 2016 at 03:43:21PM -0500, Alan DeKok wrote:
On Jan 19, 2016, at 3:39 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
I'm probably fairly unusual in having an eap instantiation (two even) that's not called "eap".
I've done some more spelunking, and calling the "eap" module is only done when it's proxying the inner-tunnel EAP data. I've pushed fixes which convert the error into a WARNING, which won't break existing configurations.
OK thanks - I'll push that out right now to test it.
That looks better, thanks: # Linked to sub-module rlm_eap_peap peap { tls = "tls-common-outer" default_eap_type = "tls" copy_request_to_tunnel = yes use_tunneled_reply = no proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = yes require_client_cert = no soh_virtual_server = "soh-server" } tls: Using cached TLS configuration from previous invocation Failed to find 'Auth-Type eap' section in virtual server inner-tunnel. The server cannot proxy inner-tunnel EAP packets. # Instantiating module "inner-eap" from file /srv/radius/mods-enabled/eap # Linked to sub-module rlm_eap_tls then starts up fine, and is now authenticating live sessions... Rather than hard-coding "eap", does it make sense to do the attached patch? (Haven't tested it here.) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Tue, Jan 19, 2016 at 09:25:56PM +0000, Matthew Newton wrote:
Rather than hard-coding "eap", does it make sense to do the attached patch? (Haven't tested it here.)
List stripping...
From 36056d82fd92306f0809635e747ca70fc26bf2b4 Mon Sep 17 00:00:00 2001 From: Matthew Newton <mcn4@leicester.ac.uk> Date: Tue, 19 Jan 2016 21:23:00 +0000 Subject: [PATCH] use instantiation name
--- src/modules/rlm_eap/types/rlm_eap_peap/rlm_eap_peap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/modules/rlm_eap/types/rlm_eap_peap/rlm_eap_peap.c b/src/modules/rlm_eap/types/rlm_eap_peap/rlm_eap_peap.c index e43c9c7..f1a2d49 100644 --- a/src/modules/rlm_eap/types/rlm_eap_peap/rlm_eap_peap.c +++ b/src/modules/rlm_eap/types/rlm_eap_peap/rlm_eap_peap.c @@ -125,7 +125,9 @@ static int mod_instantiate(CONF_SECTION *cs, void **instance) /* * Don't expose this if we don't need it. */ - if (!inst->inner_eap_module) inst->inner_eap_module = "eap"; + if (!inst->inner_eap_module) { + inst->inner_eap_module = cf_section_name(cs); + } dv = dict_valbyname(PW_AUTH_TYPE, 0, inst->inner_eap_module); if (!dv) { -- 2.1.4 -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
I'm probably fairly unusual in having an eap instantiation (two even) that's not called "eap".
You're not alone. My outer config has: authorize { auth_log if ( RESTENA-Service-Type == "eduroam-lu" && User-Name =~ /restena.lu$/ ) { eap-staff } if ( RESTENA-Service-Type == "eduroam-lu" && User-Name !~ /restena.lu$/ ) { eap } } authenticate { Auth-Type eap-staff { eap-staff } eap } eap and eap-staff then have distinct virtual_server targets. The inner virtual server for the non-default instance eap-staff then does: authorize { ... mschap eap-staff pap ... } authenticate { Auth-Type PAP{ pap } Auth-Type MSCHAP { mschap } Auth-Type eap-staff { eap-staff } } This works fine in 3.0.10. After this conversation, I'm not entirely sure it will continue to. Do you think it's worth testing this or is EverythingAlright(tm) with this one? Greetings, Stefan Winter
EAP modules here are called "outer-eap" and "inner-eap" (for my sanity - we've got PEAP/EAP-TLS, so it's "double-stacked" :-) )
What does the inner-tunnel "authenticate" section? i.e. does it have:
authenticate { ... inner-eep ... }
This. Well, default has
authenticate { outer-eap }
and inner-innel has
authenticate { inner-eap }
so basically the same as the default configration, except I've renamed the instances from eap to inner/outer-e.ap
outer-eap does PEAP, inner-eap does EAP-TLS.
Adding in the new "inner_eap_module" option to the outer PEAP section fixes it (inner_eap_module = "outer-eap") but I'm not sure why it needs to break in 3.0.x?
It doesn't need to break, of course. But sanity checks are good.
Yeah, OK.
The problem was that the PEAP module was *hard-coded* to use "Auth-Type EAP". Which worked fine for situation (2) above, but not so much for situation (1).
But it has always worked for (1) before - that's the default config (albeit with unchanged instance name I admit).
On Tue, Jan 19, 2016 at 02:26:57PM -0500, Alan DeKok wrote:
On Jan 19, 2016, at 2:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
Hmm... If I configure the inner-tunnel virtual server as (1), I get:
No, my bad. It works.
So my question again, is how the heck did it ever work when running inner-tunnel, Auth-Type EAP, and there's no "eap" module listed in "authenticate" ?
there is "outer-eap", just not "eap".
If it breaks peoples systems, I can relax the checks. But I'd like to know just what the heck the system is actually doing.
TBH I've never quite got my head around why there is e.g.
Auth-Type pap { pap }
for everything else, and just
eap
for the eap module. I've always guessed that if the correct Auth-Type section is set then it uses that section, otherwise it just goes an calls all modules not in a named section in order (as in authorize) and hopes that something picks it up?
Guess I should go and read the code.... just haven't ever needed to check this as it's always just worked, albeit looked slightly odd :)
Thanks,
Matthew
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette 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
On Jan 20, 2016, at 6:47 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
This works fine in 3.0.10.
After this conversation, I'm not entirely sure it will continue to. Do you think it's worth testing this or is EverythingAlright(tm) with this one?
Please check v3.0.x head, but after yesterdays spelunking through the code, yes, it will work. What didn't work before was proxying the inner EAP session to another server, when the inner EAP module wasn't called "eap". It now works. Alan DeKok.
On Jan 19, 2016, at 12:54 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
EAP modules here are called "outer-eap" and "inner-eap" (for my sanity - we've got PEAP/EAP-TLS, so it's "double-stacked" :-) )
That makes sense.
Adding in the new "inner_eap_module" option to the outer PEAP section fixes it (inner_eap_module = "outer-eep")
Is that a typo? Are you sure it isn't "inner_eap_module = "inner-eap" Alan DeKok.
On Tue, Jan 19, 2016 at 02:42:44PM -0500, Alan DeKok wrote:
On Jan 19, 2016, at 12:54 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Adding in the new "inner_eap_module" option to the outer PEAP section fixes it (inner_eap_module = "outer-eep")
Is that a typo? Are you sure it isn't "inner_eap_module = "inner-eap"
Er, dunno - I was just trying things to get the server to start, not knowing exactly what inner_eap_module actually does. I didn't check that it would actually authenticate anything ;-) I have eap outer-eap { default_eap_type = peap ... tls-config tls-common-outer { ... } # permit plain eap-tls tls { tls = tls-common-outer virtual_server = check-eap-tls } # for peap/eap-tls peap { tls = tls-common-outer default_eap_type = tls copy_request_to_tunnel = yes use_tunneled_reply = no virtual_server = "inner-tunnel" soh = yes soh_virtual_server = "soh-server" # added 'inner_eap_module = "outer-eap"' here } } eap inner-eap { default_eap_type = tls ... tls-config tls-common-inner { ... } # for inner eap-tls tls { tls = tls-common-inner virtual_server = check-eap-tls } } Is 'inner_eap_module' overriding 'virtual_server = "inner-tunnel"', or just setting which module to call in the outer authenticate section? I assumed the latter. m. -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (3)
-
Alan DeKok -
Matthew Newton -
Stefan Winter