3.0.11 update broke my PEAP
Hi, this looks suspiciously like a bug to me. I updated from 3.0.10 to 3.0.11 with a perfectly working and unchanged configuration. In 3.0.11, all PEAP is broken with a slightly enigmatic error message which suggests my config may be sub-par; I can't really determine what should be wrong with it. Here's -X, the end of authorize and beginning of authenticate inside inner-tunnel: (484) sql-commonauth: User found in radcheck table (484) sql-commonauth: Conditional check items matched, merging assignment check items (484) sql-commonauth: NT-Password := 0xREALLYITISTHEPASSWORDBUTIREDACTEDIT rlm_sql (sql-commonauth): Released connection (0) (484) [sql-commonauth] = ok (484) } # redundant = ok (484) [mschap] = noop (484) pap: Normalizing NT-Password from hex encoding, 32 bytes -> 16 bytes (484) pap: WARNING: Auth-Type already set. Not setting to PAP (484) [pap] = noop (484) } # authorize = updated (484) Found Auth-Type = eap (484) # Executing group from file /usr/local/freeradius/config/raddb/sites-enabled/inner-tunnel (484) authenticate { (484) eap: Expiring EAP session with state 0x3a79dfac3a78c68e (484) eap: Finished EAP session with state 0x4db614dc4dbc0e2d (484) eap: Previous EAP request found for state 0x4db614dc4dbc0e2d, released from the list (484) eap: Peer sent packet with method EAP MSCHAPv2 (26) (484) eap: Calling submodule eap_mschapv2 to process data (484) eap_mschapv2: Auth-Type sub-section not found. Ignoring. (484) eap_mschapv2: # Executing group from file /usr/local/freeradius/config/raddb/sites-enabled/inner-tunnel (484) eap: Sending EAP Failure (code 4) ID 10 length 4 (484) eap: Freeing handler (484) [eap] = reject (484) } # authenticate = reject (484) Failed to authenticate the user (484) Using Post-Auth-Type Reject So... the inner-tunnel eap comes as far as realising it should call the eap_mschapv2 sub-module; but that one bails out claiming it can't find its own config? Well mods-enabled/eap has a mschapv2 EAP type configuration just fine: eap { default_eap_type = peap [...] peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "inner-tunnel" } mschapv2 { } } So which sub-section would be missing here? Strange. I've rolled back with the exact same config to 3.0.10 and things started working again like a charm. Greetings, Stefan Winter -- 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 Mon, Feb 15, 2016 at 09:06:00AM +0100, Stefan Winter wrote:
this looks suspiciously like a bug to me. I updated from 3.0.10 to 3.0.11 with a perfectly working and unchanged configuration. In 3.0.11, all PEAP is broken with a slightly enigmatic error message which suggests my config may be sub-par; I can't really determine what should be wrong with it.
Alan added a patch to check that all eap types that are used are actually defined in a virtual server (or along those lines). But it may have caused a few issues with configs that might not have been quite correct before. I'm guessing this is one of those cases.
(484) eap: Calling submodule eap_mschapv2 to process data (484) eap_mschapv2: Auth-Type sub-section not found. Ignoring. (484) eap_mschapv2: # Executing group from file /usr/local/freeradius/config/raddb/sites-enabled/inner-tunnel
So which sub-section would be missing here? Strange.
Check you've not commented out the Auth-Type MS-CHAP {} section from authenticate {}. Whether this is tightening up things a bit too far in terms of config checks, I'm not sure. 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>
Hi,
Check you've not commented out the Auth-Type MS-CHAP {} section from authenticate {}.
I did not comment it out (that would have broken 3.0.10 as well I think); one of the things I checked before posting. Sorry for not being precise enough in the first try :-) Greetings, Stefan Winter -- 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 Feb 15, 2016, at 3:06 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
this looks suspiciously like a bug to me. I updated from 3.0.10 to 3.0.11 with a perfectly working and unchanged configuration. In 3.0.11, all PEAP is broken with a slightly enigmatic error message which suggests my config may be sub-par; I can't really determine what should be wrong with it.
I added more sanity checks to give startup errors instead of run-time errors. This shouldn't cause issues for people with correct configurations.
(484) eap: Calling submodule eap_mschapv2 to process data (484) eap_mschapv2: Auth-Type sub-section not found. Ignoring.
That's actually produced by the main modules code. EAP-MSCHAPv2 is asking the modules code to run "Auth-Type MSCHAP", and the modules code is saying "nope, this virtual server doesn't have any MS-CHAP". You probably have an "inner-tunnel" virtual server where you've removed "mschap" from the "authenticate" section. The EAP-MSCHAPv2 module looks up the value for "Auth-Type MSCHAP" when it starts, and caches it. But critically, that value is global. There's no guarantee that the "Auth-Type MSCHAP" section exists in the virtual server which is using EAP-MSCHAPv2. Doing that extra validation at startup time would require some significant code changes. The EAP-MSCHAPv2 module would have to get a list of all virtual servers where it's used, and then troll through those, looking for MSCHAP modules. Or, having the EAP-MSCHAPv2 do a dlopen() of the rlm_mschap module directly, and call it directly. That might be weirder, but simpler. Alan DeKok.
Hi,
You probably have an "inner-tunnel" virtual server where you've removed "mschap" from the "authenticate" section.
I Don't. My authenticate{} in inner-tunnel is: authenticate { Auth-Type PAP{ pap_hash_debugfallback } Auth-Type MS-CHAP{ mschap_hash_debugfallback } eap } mschap_hash_debugfallback is a policy doing weird things, but one of those things is that it calls "mschap" just like the default shipped inner-tunnel does. Greetings, Stefan Winter
The EAP-MSCHAPv2 module looks up the value for "Auth-Type MSCHAP" when it starts, and caches it. But critically, that value is global. There's no guarantee that the "Auth-Type MSCHAP" section exists in the virtual server which is using EAP-MSCHAPv2.
Doing that extra validation at startup time would require some significant code changes. The EAP-MSCHAPv2 module would have to get a list of all virtual servers where it's used, and then troll through those, looking for MSCHAP modules.
Or, having the EAP-MSCHAPv2 do a dlopen() of the rlm_mschap module directly, and call it directly. That might be weirder, but simpler.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- 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 Feb 17, 2016, at 3:25 AM, Stefan Winter <stefan.winter@restena.lu> wrote: I Don't. My authenticate{} in inner-tunnel is:
authenticate { Auth-Type PAP{ pap_hash_debugfallback } Auth-Type MS-CHAP{
Ah... change that to MSCHAP, and it will work. You probably have an Auth-Type MSCHAP" defined somewhere else, and that's used first. Alan DeKok.
Hi,
Auth-Type MS-CHAP{
Ah... change that to MSCHAP, and it will work.
??? The config reads "MS-CHAP" with a dash because - it's been like that for the last decade - no migration warning told me it's deprecated - the default config (!!) for 3.0.11 has the dash in inner-tunnel and default Are you saying you changed the Auth-Type to MSCHAP without dash, but pretty much literally told no-one that it is so?
You probably have an Auth-Type MSCHAP" defined somewhere else, and that's used first.
Indeed, there are two other virtual servers which have this without dash (but I wouldn't know why!). So, having the more recent/correct dashless config "somewhere" magically kills all the previously nicely working dashed config? Wow. Greetings, Stefan Winter -- 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 Feb 17, 2016, at 8:51 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
Are you saying you changed the Auth-Type to MSCHAP without dash, but pretty much literally told no-one that it is so?
No. I'm saying it tries to be compatible with whatever you have, and sometimes it doesn't succeed.
Indeed, there are two other virtual servers which have this without dash (but I wouldn't know why!).
Then change all of them to MS-CHAP. And it will work.
So, having the more recent/correct dashless config "somewhere" magically kills all the previously nicely working dashed config?
I'm saying that the configuration never really did what you expected. It "worked", for accidental versions of "worked". Alan DeKok.
Hi,
Indeed, there are two other virtual servers which have this without dash (but I wouldn't know why!).
Then change all of them to MS-CHAP. And it will work.
Well I now changed all of them consistently to MSCHAP, and confirm that this works. I guess I could alternatively change all of them to MS-CHAP and it would still work. I still can't get my head around this... if the name doesn't matter, could I consistently change it to Auth-Type FOOBAR{} and it would still work? Or are both MSCHAP and MS-CHAP two reserved words for essentially the same thing, and using both in the same config now (as in 3.0.11+) yields unexpected results? And the unexpected results are the "correct" results?
I'm saying that the configuration never really did what you expected. It "worked", for accidental versions of "worked".
The subtlety of why it's wrong is too subtle for me. It worked for an incredibly long time over many many versions. And if the two keywords can't co-exist in the same config then this doesn't seem documented anywhere. Greetings, Stefan Winter -- 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 Feb 17, 2016, at 9:09 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
Well I now changed all of them consistently to MSCHAP, and confirm that this works.
That's good.
I guess I could alternatively change all of them to MS-CHAP and it would still work.
Yes.
I still can't get my head around this... if the name doesn't matter, could I consistently change it to Auth-Type FOOBAR{} and it would still work?
The name does matter. The problem is that people had *both* names, and complained that they didn't both work. So the code was updated to allow for both in some situations. The result is that people had inconsistent configurations. And... that caused problems.
Or are both MSCHAP and MS-CHAP two reserved words for essentially the same thing, and using both in the same config now (as in 3.0.11+) yields unexpected results? And the unexpected results are the "correct" results?
The PEAP module tries both MSCHAP and MS-CHAP. Because the PEAP module can't tell what you really have in the "authenticate" section. I'll make this configurable, and explicit in the config for 3.0.12.
I'm saying that the configuration never really did what you expected. It "worked", for accidental versions of "worked".
The subtlety of why it's wrong is too subtle for me. It worked for an incredibly long time over many many versions. And if the two keywords can't co-exist in the same config then this doesn't seem documented anywhere.
They can exist in the same config. The problem is that the EAP-MSCHAPv2 module has to *guess* which one is being used. If you have both "MSCHAP" and "MS-CHAP" in the same config, it can guess wrong. The solution is to make this guess explicit in the EAP-MSCHAPv2 module configuration. Alan DeKok.
participants (3)
-
Alan DeKok -
Matthew Newton -
Stefan Winter