MS-CHAP-V2 with no retry

John.Hayward at wheaton.edu John.Hayward at wheaton.edu
Thu Apr 21 03:53:48 CEST 2011


Thanks for the patches - I've built a new server and hopefully will test 
tomorrow.

On the re-reading of config I can live without the HUP not causing mschap 
to re-read it's config - just assumed that it would.

johnh...
On Wed, 20 Apr 2011, Phil Mayers wrote:

> Date: Wed, 20 Apr 2011 17:53:42
> From: Phil Mayers <p.mayers at imperial.ac.uk>
> Reply-To: FreeRadius users mailing list
>     <freeradius-users at lists.freeradius.org>
> To: freeradius-users at lists.freeradius.org
> Subject: Re: MS-CHAP-V2 with no retry
> 
> On 04/20/2011 11:14 PM, John.Hayward at wheaton.edu wrote:
>> I have been able to do some testing with the adjustments for MS-CHAP-V2
>> related to error and retires.
>> 
>> There are two items I observed with testing:
>> 
>> 1) If I sent a HUP signal to the server it appears to re-read the
>> configuration files but for some reason does not re-read the mschap
>> module - so changing this module while testing seemed to require a
>> restart on the server. Is that the expected behavior?
>
> rlm_mschap doesn't implement a HUP handler AFAICT. It probably wouldn't be 
> terribly hard to write one - the module is fairly stateless. It's probably 
> best to just restart the server though.
>
>> 2) If retry=yes then on Windows-7 on failure a notification is given if
>> they click they are presented with a message indicating their username
>> or password are incorrect and given an opportunity to re-enter only a
>> password. If they enter the correct password the authentication fails
>> and they have to re-connect to get a duologue box where they can enter
>> both the username and password. I have not traced down to determine why
>> the client thinks there is a failure (eg need to see if FRS thinks it is
>> a failure or not). This I believe is not what should be happening.
>
> I think this is probably because the EAP-MSCHAP modules needs to parse and 
> store the new challenge in the error message. If it doesn't, the server and 
> client will disagree on the challenge/response value and auth will fail
>
> This patch implements the required behaviour (as part of the "support 
> password change" code):
>
> https://github.com/philmayers/freeradius-server/commit/44a81366fb0b909d9165ec5650004bd979c0f9d9
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html
>



More information about the Freeradius-Users mailing list