Re: MS-CHAP-V2 with no retry
Hi Alan, I just wanted to make sure you know what we are currently running - we started with 2.1.x after patches were put in place related to retry/no-retry - this version works properly for no-retry but does not operate correctly with retry allowed. We next applied the patch from Phil which corrected the challenge - this by itself still did not work properly with retry. We next tweaked that patch to send a request rather than failure if retry was being allowed and this worked as it should have. Phil indicated that he had reworked the mschap module to deal with password changes and as part of that change resulted in the correct behavior if his original patch to fix the challenge was left unmodified. I personally think his approach is better but more complex because it also has code related to password change (a feature we would not use). I think it would be highly desirable to get a version of the patch which works correctly with retry enabled since it significantly reduces support calls in environments which have required password changes. From your perspective which approach to getting retry enabled working do you recommend for 2.11 so we can be testing the same version: o my tweaks of Phil's single "challenge" patch o Phil's challenge and password change patches o a simpler two patch solution which does not do passwords - the challenge patch and a rearrangement patch which detects responses to retry challenges? Is there any thing I can do to help get this accomplished? johnh... On Tue, 26 Apr 2011, Alan DeKok wrote: Date: Tue, 26 Apr 2011 07:57:09 From: Alan DeKok Reply-To: FreeRadius users mailing list To: FreeRadius users mailing list Subject: Re: MS-CHAP-V2 with no retry john.hayw...@wheaton.edu wrote: Just a brief update. In addition to Windows-7 behavior on Windows-XP, Macs and Iphones are as expected with this retry patch - user is presented with a password dialog box and the connection is not aborted - user only needs to enter the correct password to be connected and no "contact your network administrator" or other messages occur. Our support people are thrilled. If it's that useful, it should go into 2.1.11. I'd prefer to have everyone possible test this, so that we're sure it doesn't break anything. Remember: FreeRADIUS depends on all of you for it's success. The more you give, the better it gets. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
I like your changes better. It allows to in the future add a retry max so
each failure could be counted and send a R=0 after a certain number of
failures.
I had briefly looked at the other area and decided it would take more
changes work with a response from a failure code than adjust it over when
sending the failure with a challenge.
Do we know if the password change (and adjustments to retry which make it
work) will be included in 2.1.11?
johnh...
On Thu, 21 Apr 2011, Phil Mayers wrote:
Date: Thu, 21 Apr 2011 12:17:55
From: Phil Mayers
Reply-To: FreeRadius users mailing list
To: freeradius-users@lists.freeradius.org
Subject: Re: MS-CHAP-V2 with no retry
On 04/21/2011 04:03 PM, john.hayw...@wheaton.edu wrote:
Thanks again for your work on this facility.
I built and installed with the new patches.
Unfortunately things did not quite work - however with a small change I
could get the retry to work properly on a windows7 machine.
The problem is that when we do a retry in addition to setting the
challenge value we also need to change the data->code to challenge
rather than failure. When the response comes back we can correctly deal
with it.
Hmm. I don't see that behaviour. That is probably due to the later changes I
made in the EAP-MSCHAPv2 state machine, here:
https://github.com/philmayers/freeradius-server/commit/8e3eece6e3c397f3a4b0c06a37a80bc8964997fd
Specifically, the old code compares client current opcode against server last
opcode; the patch I wrote above does a switch over server last opcode, then
permits one or more valid client opcodes. Response is specifically permitted
after failure, as it change-password (opcode 7).
original patch -- with suggested changes
678 - pairmove2(&response, &handler->request->reply->vps,
This patch is a bit "magic" for my tastes. The only reason it works is
because eapmschapv2_compose completely ignores data->code - it chooses the
EAP-MSCHAPv2 opcode based on the 2nd VALUE_PAIR* argument.
So essentially you're setting data->code to trick the state machine in
mschapv2_authenticate, but to someone unfamiliar with the code it would read
like you're sending a challenge back, which you're not - you're sending a
failure back.
An alternative approach would be:
--- rlm_eap_mschapv2.c~ 2010-10-13 13:34:16.0 +0100
+++ rlm_eap_mschapv2.c 2011-04-21 18:08:19.0 +0100
@@ -424,10 +424,6 @@
* a challenge.
*/
case PW_EAP_MSCHAPV2_RESPONSE:
- if (data->code != PW_EAP_MSCHAPV2_CHALLENGE) {
- radlog(L_ERR, "rlm_eap_mschapv2: Unexpected response
received");
- return 0;
- }
/*
* Ensure that we have at least enough data
i.e. remove the check for "client opcode 'response' only valid if we sent a
'challenge'". Or of course, widen the check to:
challenge
or
failure
Anyway, they're more or less equivalent. A matter of taste I guess.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
Just a brief update.
In addition to Windows-7 behavior on Windows-XP, Macs and Iphones are as
expected with this retry patch - user is presented with a password
dialog box and the connection is not aborted - user only needs to enter
the correct password to be connected and no "contact your network
administrator" or other messages occur.
Our support people are thrilled.
johnh...
On Thu, 21 Apr 2011, john.hayw...@wheaton.edu wrote:
Date: Thu, 21 Apr 2011 10:03:30
From: john.hayw...@wheaton.edu
Reply-To: FreeRadius users mailing list
To: FreeRadius users mailing list
Subject: Re: MS-CHAP-V2 with no retry
Thanks again for your work on this facility.
I built and installed with the new patches.
Unfortunately things did not quite work - however with a small change I could
get the retry to work properly on a windows7 machine.
The problem is that when we do a retry in addition to setting the challenge
value we also need to change the data->code to challenge rather than failure.
When the response comes back we can correctly deal with it.
original patch -- with suggested changes
678 -pairmove2(&response, &handler->request->reply->vps,
679 -PW_MSCHAP_ERROR);
678 +pairmove2(&response, &handler->request->reply->vps,
679 +PW_MSCHAP_ERROR);
add failure code by default
data->code = PW_EAP_MSCHAPV2_FAILURE;
680 +if (response) {
681 + int n,err,retry;
682 + char buf[34];
683 + 684 + DEBUG2(" MSCHAP-Error: %s", response->vp_strvalue);
685 +
686 + /*
687 + * parse the new challenge out of the MS-CHAP-Error, so if the
client
688 + * issues a re-try, we'll know the challenge value they used
689 + */
690 + n = sscanf(response->vp_strvalue, "%*cE=%d R=%d C=%32s", &err,
&retry, &buf);
691 + if (n==3) {
692 +DEBUG2(" Found new challenge from MS-CHAP-Error: err=%d
retry=%d challenge=%s", err, retry, buf);
693 +fr_hex2bin(buf, data->challenge, 16);
Set code to challenge if we find a challenge
data->code = PW_EAP_MSCHAPV2_CHALLENGE;
694 + } else {
695 +DEBUG2(" Could not parse new challenge from MS-CHAP-Error: %d",
n);
696 + }
697 +}
680
remove this code since set above
698 data->code = PW_EAP_MSCHAPV2_FAILURE;
END OF original patch ===
johnh...
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
Thanks again for your work on this facility.
I built and installed with the new patches.
Unfortunately things did not quite work - however with a small change I
could get the retry to work properly on a windows7 machine.
The problem is that when we do a retry in addition to setting the challenge
value we also need to change the data->code to challenge rather than
failure. When the response comes back we can correctly deal with it.
original patch -- with suggested changes
678 -pairmove2(&response, &handler->request->reply->vps,
679 -PW_MSCHAP_ERROR);
678 +pairmove2(&response, &handler->request->reply->vps,
679 +PW_MSCHAP_ERROR);
add failure code by default
data->code = PW_EAP_MSCHAPV2_FAILURE;
680 +if (response) {
681 + int n,err,retry;
682 + char buf[34];
683 +
684 + DEBUG2(" MSCHAP-Error: %s", response->vp_strvalue);
685 +
686 + /*
687 + * parse the new challenge out of the MS-CHAP-Error, so if the client
688 + * issues a re-try, we'll know the challenge value they used
689 + */
690 + n = sscanf(response->vp_strvalue, "%*cE=%d R=%d C=%32s", &err, &retry,
&buf);
691 + if (n==3) {
692 +DEBUG2(" Found new challenge from MS-CHAP-Error: err=%d retry=%d
challenge=%s", err, retry, buf);
693 +fr_hex2bin(buf, data->challenge, 16);
Set code to challenge if we find a challenge
data->code = PW_EAP_MSCHAPV2_CHALLENGE;
694 + } else {
695 +DEBUG2(" Could not parse new challenge from MS-CHAP-Error: %d",
n);
696 + }
697 +}
680
remove this code since set above
698 data->code = PW_EAP_MSCHAPV2_FAILURE;
END OF original patch ===
johnh...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
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 Reply-To: FreeRadius users mailing list To: freeradius-users@lists.freeradius.org Subject: Re: MS-CHAP-V2 with no retry On 04/20/2011 11:14 PM, john.hayw...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
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? 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. johnh... On Wed, 13 Apr 2011, john.hayw...@wheaton.edu wrote: Date: Wed, 13 Apr 2011 16:19:26 From: john.hayw...@wheaton.edu To: FreeRadius users mailing list Subject: Re: MS-CHAP-V2 with no retry First - thanks to the free radius group for all the work on this over the weekend. There have been some fixes and extensions to my original patches and I saw a commit on Friday before some fixes and extensions were in place. Can someone point me to exactly what I need to "git" to get the current version of freeradius with the patches so I can do some testing at our site? TIA. johnh... On Mon, 11 Apr 2011, Phil Mayers wrote: Date: Mon, 11 Apr 2011 08:45:13 From: Phil Mayers Reply-To: FreeRadius users mailing list To: freeradius-users@lists.freeradius.org Subject: Re: MS-CHAP-V2 with no retry On 11/04/11 11:22, Phil Mayers wrote: On 10/04/11 15:41, James J J Hooper wrote: This C= needs to be saved and eventually make it's way in to data->challenge so that the line lower down: memcpy(challenge->vp_strvalue, data->challenge, MSCHAPV2_CHALLENGE_LEN); It's actually a bit more complex; the new challenge is being generated inside rlm_mschap as part of the error, but AFACIT rlm_eap_mschapv2 needs to know it, so that it can add it to the fake request which it then passes *back* into rlm_mschap as an MS-CHAP-Challenge attribute. This would also get us part of the way there to password change via mschap (Samba currently lacks the specific API call to do this, with the values available in an MSCHAP CPW packet, but it might be possible to compile a C helper which does it...) The attached patch against git v2.1.x branch makes EAP-MSCHAPV2 retry work for me. It needs a bit of work, specifically there should be a: num_retries ...parameter, and the EAP module should keep track of retry attempt counts, and stop when either: try_number > num_retries or R=0 in the MS-CHAP-Error attribute Also, I pulled the EAP-MSCHAPV2 state machine to bits, so I'm not sure it should go into 2.1.11 - there's probably not enough testing time. It works for a Windows XP SP3 client here, as well as with a jury-rigged eapol_test/wpa_cli combo. I'll spin up an SSID and give it a try with real clients later today. Of note: this gets us nearer to MS-CHAP change-password functionality; I've looked into this a couple of times recently and Samba has almost all the bits required to make it work... However, that would require some infrastructure for the server to override the MS-CHAP error code, currently hard-coded at 691 - 648 is "password expired" and would need to be set, either by parsing the output of ntlm_auth (for those that use it) or from some SQL/database attribute (for those using Cleartext/NT-Password) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
First - thanks to the free radius group for all the work on this over the weekend. There have been some fixes and extensions to my original patches and I saw a commit on Friday before some fixes and extensions were in place. Can someone point me to exactly what I need to "git" to get the current version of freeradius with the patches so I can do some testing at our site? TIA. johnh... On Mon, 11 Apr 2011, Phil Mayers wrote: Date: Mon, 11 Apr 2011 08:45:13 From: Phil Mayers Reply-To: FreeRadius users mailing list To: freeradius-users@lists.freeradius.org Subject: Re: MS-CHAP-V2 with no retry On 11/04/11 11:22, Phil Mayers wrote: On 10/04/11 15:41, James J J Hooper wrote: This C= needs to be saved and eventually make it's way in to data->challenge so that the line lower down: memcpy(challenge->vp_strvalue, data->challenge, MSCHAPV2_CHALLENGE_LEN); It's actually a bit more complex; the new challenge is being generated inside rlm_mschap as part of the error, but AFACIT rlm_eap_mschapv2 needs to know it, so that it can add it to the fake request which it then passes *back* into rlm_mschap as an MS-CHAP-Challenge attribute. This would also get us part of the way there to password change via mschap (Samba currently lacks the specific API call to do this, with the values available in an MSCHAP CPW packet, but it might be possible to compile a C helper which does it...) The attached patch against git v2.1.x branch makes EAP-MSCHAPV2 retry work for me. It needs a bit of work, specifically there should be a: num_retries ...parameter, and the EAP module should keep track of retry attempt counts, and stop when either: try_number > num_retries or R=0 in the MS-CHAP-Error attribute Also, I pulled the EAP-MSCHAPV2 state machine to bits, so I'm not sure it should go into 2.1.11 - there's probably not enough testing time. It works for a Windows XP SP3 client here, as well as with a jury-rigged eapol_test/wpa_cli combo. I'll spin up an SSID and give it a try with real clients later today. Of note: this gets us nearer to MS-CHAP change-password functionality; I've looked into this a couple of times recently and Samba has almost all the bits required to make it work... However, that would require some infrastructure for the server to override the MS-CHAP error code, currently hard-coded at 691 - 648 is "password expired" and would need to be set, either by parsing the output of ntlm_auth (for those that use it) or from some SQL/database attribute (for those using Cleartext/NT-Password) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: MS-CHAP-V2 with no retry
A couple of comments on how clients behave: o It was my impression based on comments from our support area that the unpatched code (which does not follow the rfc) serving a windows client presented the user with a dialogue box on failure. I have not tested this. I assumed that if windows could deal reasonably with a server which did not follow the rfc they could also work with one that did (possibly wrong assumption - but they are the ones which wrote the rfc). o It is known that various versions of the mac client fail in different respects - however they seem to fail consistently in that if retry is allowed they fail to increment the ID when retrying - on the MS radius server discards the retry because it is not following the protocol. You can get macs to play by configuring the server to not allow retries. So if you are going to test macs on the MS radius server you might try both with retry and without retry. o In this case it appears that in this case there have been more issues with mac wpa_clients than windows wpa_clients. o Testing of both windows and mac with out the patch and with the patch need to be done. johnh... From: freeradius-users-bounces+john.hayward=wheaton@lists.freeradius.org [freeradius-users-bounces+john.hayward=wheaton@lists.freeradius.org] on behalf of Alan DeKok [al...@deployingradius.com] Sent: Friday, April 08, 2011 2:54 AM To: FreeRadius users mailing list Subject: Re: MS-CHAP-V2 with no retry Phil Mayers wrote: > +1 - In my experience it's necessary to cater for windows' weirdness > *first*. Most other clients have sane behaviours. I'm concerned about > the "we didn't do much windows testing" line... Yup. I've just pushed some changes to the git "v2.1.x" branch. See: raddb/modules/mschap - allow_retry - retry_msg raddb/eap.socn - send_error The default is no change. See the documentation for how to test the new features. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
On Wed, 9 Mar 2011, Alan DeKok wrote:
Date: Wed, 9 Mar 2011 01:25:10
From: Alan DeKok
Reply-To: FreeRadius users mailing list
To: FreeRadius users mailing list
Subject: Re: MS-CHAP-V2 with no retry
John Hayward wrote:
Any idea of the time frame?
A long time.
Should I spend my time looking at the code and proposing a patch?
Sure.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I don't know if this should be sent to the developers list instead.
=== Background ===
When there is a failure of the client to match the challenge of the
server:
According to rfc2759 a failure packet in section 6 a failure packet
includes a message like:
"E=ee R=r C= V=vv M="
where E is the error code, R 1/0 allow/disallow retry C an ascii version
of the challenge V=3 and M= some text message.
After this mschap failure message is sent by the server an acknowledgment
which seems to be have a failure code should be returned from the client.
At that point the server can close the eap connection with a failure.
What the 2.1.10 code (and earlier) appears to do is after mschap is
detected immediately close the eap connection with a failure.
The effect for windows XP/7 machines connecting wirelessly using mschapv2
is that they are presented with a dialog box and can enter new
credentials.
What happens with mac/iphones/androids/ubuntu is that they appear to be
confused and time out and re-send (at various rates) authentication
attempts without presenting a dialog box to the user.
For some environments (such as using Novell NDS to authenticate) if
configured modules/ldap edir_account_policy_check=yes then these repeated
failures result in account lock outs.
Scenario: Institution requires periodic change of password - user uses a
web site to change password - user forgets to update their
mac/iphone/android - user turns on their mac/iphone/android - shortly
after user cannot access any resources (such as blackboard/portal etc)
because their account is locked out.
== proposed fix
Modify freeradius to follow rfc2759.
This requires patches to two source files:
o src/modules/rlm_mschap/rlm_mschap.c to include a message which conforms
to rfc2759
o src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c to use the
response created by rlm_mschap.c and send that back, also accept an
authentication failure acknowledgment before sending eap failure packet.
Below are the diffs:
=== rlm_mschap.c (from src/modules/rlm_mschap/)
1242,1252c1242
< /* JCH - changes to include challenge and message */
< char msg[100];
< strcpy(msg, "E=691 R=0 C=");
< int i, offset = strlen(msg);
< char *ptr = &msg[offset];
< for (i=0; i<16; i++, ptr+=2) {
<sprintf(ptr, "%02X", response->vp_octets[i+2]);
< }
< *ptr = 0;
< strcat(msg, " V=3 M=May Need to reset cashed password"
);
< mschap_add_reply(request, &request->reply->vps,
---
mschap_add_reply(request, &request->reply->vps,
1254c1244
<"MS-CHAP-Error", msg, strlen(msg));
---
"MS-CHAP-Error", "E=691 R=1", 9);
1299d1288
< /* JCH should we check for MS-CHAPV2 and modify the reply to include challenge
? */
from /src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c
198c198,200
< length = 4 + MSCHAPV2_FAILURE_MESSAGE_LEN;
---
/* JCH need to be change length to work with full v2 message */
//length = 4 + MSCHAPV2_FAILURE_MESSAGE_LEN;
length = 4 + reply->length-1;
215c217,222
< memcpy((eap_ds->request->type.data + 4),
MSCHAPV2_FAILURE_MESSAG
E, MSCHAPV2_FAILURE_MESSAGE_LEN);
---
/* JCH need to copy the failure message from mschapv2 - it contains
ascii
version of the challenge C=...
*/
memcpy((eap_ds->request->type.data + 4),
(reply->vp_strvalue+1),
(reply->length-1));
//MSCHAPV2_FAILURE_MESSAGE, MSCHAPV2_FAILURE_MESSAGE_LEN);
487a495,505
/*JCH added - is this is an ack of a failure message */
case PW_EAP_MSCHAPV2_FAILURE:
if (data->code != PW_EAP_MSCHAPV2_FAILURE) {
radlog(L_ERR, "rlm_eap_mschapv2: Unexpected FAILURE
received");
return 0;
}
//JCH needed??? handler->request->options &=
~RAD_REQUEST_OPTION
_PROXY_EAP;
eap_ds->request->code = PW_EAP_FAILURE;
return 1;
Duplicate "Auth: Login OK:"
Free Radius Fans, First - thanks to the people who contribute to this product! Our environment - Wireless 802.1x, Novell NDSLdap to lookup passwords or mysql, Peap with mschapv2. I observe when a client successfully authenticates to the radius server there are two "Auth: Login OK:" messages - one with a via TLS tunnel and one without. In looking at the eap messages (ID 9 or 10) it appears that the inner tunnel return a success but the outer sends another request. I wonder if this is what is expected, or if I have a configuration issue, or if there is a bug in the free radius code. In looking at the RFCs for eap a success packet is to have no data. It appears that mschap-v2 passes back a success packet with an authenticator response string (S=...). I am not sure what the exact sequence of packets should be at the end of a successful authentication. The log file running radius -x -x -X are at: http://cs.wheaton.edu/~johnh/FreeRadius if people want to see. TIA for help you can provide. johnh... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Trying to get my sql configuration right.
On Sat, 12 Mar 2011, John Dennis wrote: Date: Sat, 12 Mar 2011 09:28:10 From: John Dennis To: FreeRadius users mailing list Cc: john.hayw...@wheaton.edu Subject: Re: Trying to get my sql configuration right. On 03/11/2011 06:33 PM, john.hayw...@wheaton.edu wrote: Hi Radius People, I am getting the message from sql authentication: !!! !!! Please update your configuration so that the "known good" !!! !!! clear text password is in Cleartext-Password, and not in User-Password. !!! !!! From other posts the solution is to update the configuration to replace the attribute "User-Password" to be "Cleartext-Password" in the radcheck table. In the radcheck table I actually have "Password" which probably get mapped to User-Password and then the warning occurs. If I change an entry in radcheck table to actually have Cleartext-Password in the radcheck table I get: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. and it fails to authenticate (but does not produce the warning message ;-) What might be causing the attribute "Password" from the table to get mapped to "User-Password" and what is suggested that I change to have radius be happy? johnh... To make radius happy follow the very clear instructions from the warning message ;-) There is no mapping of Password to User-Password. The correct attribute is Cleartext-Password in the radcheck table, assure that is the value in the table and that is the value being returned from the SQL query. Actually there is equivalent mapping of both Password and User-Password In the /usr/share/freeradius/dictionary.compat there is: ATTRIBUTE Password2 string encrypt=1 In dictionary.rfc2865 there is: ATTRIBUTE User-Password 2 string encrypt=1 So when either User-Password or Password are attributes they get set up the same. While the directions are clear they did not address the situation that a person has an old style Password attribute in their database - maybe the message could be changed. Something else is going on, but we can't tell what because you didn't include the full output of radiusd -X, but before you post it you should carefully *read* the output of radiusd -X, it will show you what values are being returned and how the processing proceeds. If after you've very carefully read the output *yourself* and and you're still stuck then post it here. This was discovered by reading the output myself, then adding additional debugging, then looking at the code to discover the dictionary translation. I don't think this could have been divined by the reading of the log itself (at least I was not able to do so). Alan DeKok pointed out one needs to also change the operator - that was my mistake. What seems to be true is: 1) using Password or User-Password in the attribute along with operator == : warning and authenticated 2) using User-Cleartext with the == operator : no warning - not authenticated (pap does not see Auth-Type 3) using User-Cleartext with the :- operator : no warning and authenticated 4) (guess) using Password or User-Password along with := operator : warning and authenticated Obviously 3 is where we want to be. johnh... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Trying to get my sql configuration right.
Hi Radius People, I am getting the message from sql authentication: !!! !!! Please update your configuration so that the "known good" !!! !!! clear text password is in Cleartext-Password, and not in User-Password. !!! !!! From other posts the solution is to update the configuration to replace the attribute "User-Password" to be "Cleartext-Password" in the radcheck table. In the radcheck table I actually have "Password" which probably get mapped to User-Password and then the warning occurs. If I change an entry in radcheck table to actually have Cleartext-Password in the radcheck table I get: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. and it fails to authenticate (but does not produce the warning message ;-) What might be causing the attribute "Password" from the table to get mapped to "User-Password" and what is suggested that I change to have radius be happy? johnh... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help migrating from 1.1.7 to 2.1.10 - clear text password being lost
Hi Radius Fans,
I am trying to move our current environment from 1.1.7 to 2.1.10 and are
having a problem getting things to work.
We have a Novell NDSLdap server which provides clear text passwords for
Novell users.
We are using peap-mschapv2.
What might be causing the request->config to be at a different location
between when the clear text password is stored and when it is needed to
authenticate?
What happens is that when a packet is sent from the server to the client
radius discards the request-config which contains the password on the identity
reply.
In the inner-tunnel you need to have ldap specified (as well as the
default) so that it will look up the password (again). (my mistake)
I was surprised that it appears that in the current environment for both
default and inner-tunnel:
# The example below uses module failover to avoid querying all
# of the following modules if the EAP module returns "ok".
# Therefore, your LDAP and/or SQL servers will not be queried
# for the many packets that go back and forth to set up TTLS
# or PEAP. The load on those servers will therefore be reduced.
#
eap {
ok = return
}
That there are 3 queries to the ldap server and 3 queries to the sql
server (which is a lot better than the 12 of each which occur without
this option)
I assumed that if radius looked up the password via ldap or sql in default
it might have them for inner - but i guess the identity could be different
for inner vs default.
johnh...
johnh...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Help migrating from 1.1.7 to 2.1.10 - clear text password being lost
Hi Radius Fans, I am trying to move our current environment from 1.1.7 to 2.1.10 and are having a problem getting things to work. We have a Novell NDSLdap server which provides clear text passwords for Novell users. We are using peap-mschapv2. In looking at the logs and Eap-Messages we see: response 01 identity (username) -> server The server looks up the user in ndsldap and: Info: [ldap] Added the eDirectory password (password removed) in check items as Cleartext-Password Then the server sends a request 02 to use EAP-TLS There are a series of responses (mostly appear to be ack) and requests to get the tunnel setup which succeeds. Near the end the client sends a response (ID=8) which is a response to the mschap2 challenge. When the server is processing this response it reports: Info: [mschap] No Cleartext-Password configured. Cannot create LM-Password. I put in some additional debugging and found that address of the request->config_item has changed from when the ldap module put the cleartext password in as a pair and when the mschap module attempts to remove it. The ldap module is called in authorize and the mschap is called in authenticate. What might be causing the request->config to be at a different location between when the clear text password is stored and when it is needed to authenticate? johnh... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: MS-CHAP-V2 with no retry
Any idea of the time frame? Should I spend my time looking at the code and proposing a patch? johnh... From: freeradius-users-bounces+john.hayward=wheaton@lists.freeradius.org [freeradius-users-bounces+john.hayward=wheaton@lists.freeradius.org] on behalf of Alan DeKok [al...@deployingradius.com] Sent: Saturday, March 05, 2011 12:23 AM To: FreeRadius users mailing list Subject: Re: MS-CHAP-V2 with no retry john.hayw...@wheaton.edu wrote: > 1) In freeradius version 2.1.10 and older (at least 1.1.7) when there was >a bug in that when there was a PW_EAP_MSCHAPV2_FAILURE while there was >a response sent back to the client but there was no message in the >response. It's more complicated. The server would send EAP-Failure, and nothing else. > 2) The patch given resolves that problem - giving the message >of the rlm_mschap.c module of E=691 R=1 On closer inspection, the patch doesn't resolve anything. It still sends an EAP-Failure. It should instead send an EAP-Response with EAP-MSCHAPv2-Failure, and the "E=691 R=1" failure code. After the client has ACKed that, it should *then* send EAP-Failure. i.e. fixing it is likely a fair bit more work. > 3) It is possible to configure in radius.conf the message on failure by: No. That sends back an MS-CHAP-Error. The code has to package that MS-CHAP-Error into an EAP sub-type, and send it back to the client in an *additional* request/response round trip, before finally sending EAP-Failure. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
See comments below - johnh...
Phil Mayers wrote:
On 04/03/11 09:46, Alan DeKok wrote:
Isn't that what this code does in rlm_eap_mschapv2.c:
It's *supposed* to add the error message. But so far as I can see,
it's never called when the PW_MSCHAP_ERROR is used.
Perhaps I'm mis-reading it?
Nope. It's just never used.
Anyways, due to that (and other) issues, I've attached a new patch.
That *should* just re-use the MS-CHAP-Error string from the MS-CHAP
module, without over-writing it with a fixed error.
Is this a proper statement of the summary of where we are:
1) In freeradius version 2.1.10 and older (at least 1.1.7) when there was
a bug in that when there was a PW_EAP_MSCHAPV2_FAILURE while there was
a response sent back to the client but there was no message in the
response.
2) The patch given resolves that problem - giving the message
of the rlm_mschap.c module of E=691 R=1
3) It is possible to configure in radius.conf the message on failure by:
post-auth {
Post-Auth-Type REJECT {
if (reply:MS-CHAP-Error =~ /E=691 R=1/) {
update reply {
MS-CHAP-Error := "E=691 R=0"
}
}
}
}
Let me know where I am wrong in these assertions.
I will try to test the patch in our environment and let the results be
known next week.
johnh...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS-CHAP-V2 with no retry
On Thu, 3 Mar 2011, Phil Mayers wrote: Date: Thu, 3 Mar 2011 17:09:42 From: Phil Mayers Reply-To: FreeRadius users mailing list To: freeradius-users@lists.freeradius.org Subject: Re: MS-CHAP-V2 with no retry It has been reported that if the Microsoft NPS server is configured for no retries (E=691 R=0) that mac/iphones/ipads then act like windows xp machines in that they report to the user that the password needs attention. Would it be possible to modify rlm_mschap.c to be conigured as to how many retries were allowed before returning authentication failure with no retry? Obviously it's possible. It's not clear it would help though; are you using plain MS-CHAP or EAP-MSCHAP? EAP-MSCHAP Can you explain what you're trying to accomplish; I didn't really understand your email in full (not sure what the stuff about Macs was all about; not sure whether "change password" means "user tries again with a different password string" or "user executes the change-password protocol because their old one has expired) We have most things (portal authentication, blackboard, wireless) using freeradius with Novell NDSLdap for authentication. We also have a password change policy which requires user periodically change their password. They can most easily do so by going to a website set up for that. Here is the sequence of events which leads to a heavy support load. 1) User initially set up their wireless connection using a current password. 2) The device caches the password. 3) The user operates for a long period of time without issue. 4) The user is notified their password will expire in a short time in the future by e-mail - telling them to change their password at the password change web site. 5) The user goes to the password change web site and changes their password. 6) After the password change has occurred - When the user attempts to connect to the wireless network: a) for wireless Windows running xp they see a message indicating they need to re-enter their password for the computer (the cashed old password no longer works) and the user enters the current password and life goes on. *** b) for wireless apple devices (os 10.6, iphones, ipads) they get no such message the device just keeps trying to authenticate and failing without prompting the user - after a certain number of failures the Novell NDS Ldap locks the user because intruder lock out facility. Now the user cannot login to systems which use uses NDSLdap authentication. User shows up at support center confused. It is known that the apple supplicant fails to increment the ID on the retry which is required by the MS-CHAP protocol. At least one person report that if the radius server responds with a failed authentication error message (E=691 R=0) - which indicates the client should not retry - causes the apple device to prompt the user for a new password. This is the same behavior which windows xp users see. I am not asking that freeradius server be used to change the password. I am asking that it be configurable as to how many retries are allowed (eg how many E=691 R=1) before a no retries failed authentication message (E=691 R=0) is sent. If a no retries failed authentication message (E=691 R=0) is sent I believe that that the apple device to re-prompt the user to update the password. johnh... > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
MS-CHAP-V2 with no retry
According to RFC2759 section 9.1.3 - 9.1.5 an authentication failure can return (E=691 R=0) --- failure no retry or (E=691 R=1) failure, disable short timeout and allow a retry with ++ID. freeradius apparently only returns (E=691 R=1) in three different places in src/modules/rlm_mschap/rlm_mschap.c apple wireless clients have a known bug Bug ID# 8112557 which fails to increment the ID in the response to the challenge failure message. The Microsoft NPS logs this failure and silently discards the retry attempt. The effect is that the user of the apple device never sees a message that tells them the need to change their password. I am unsure if free radius checks the ID of a retry packet from a device but the effect is similar - users are left in the dark as to why they cannot connect when their password has been changed. It has been reported that if the Microsoft NPS server is configured for no retries (E=691 R=0) that mac/iphones/ipads then act like windows xp machines in that they report to the user that the password needs attention. Would it be possible to modify rlm_mschap.c to be conigured as to how many retries were allowed before returning authentication failure with no retry? johnh... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
