On 11/04/2012 17:24, James J J Hooper wrote:
Hi All,
FR 2.1.x Git, doing PEAP against AD via ntlm_auth. I thought that with:
allow_retry = yes [in modules/mschap]
and
send_error = yes [in modules/eap]
...FR has the functionality to take the second password attempt, and
re-try it against AD i.e. The scenario outlined in section 9.1.4 of
RFC2759: <http://tools.ietf.org/html/rfc2759#section-9.1.4>
I can't get it to work: Configuring as above does indeed make Windows
re-prompt for the password if the first attempt is bad, but when this
comes back to FR, nothing seems to be done with it.
I've had a look at the code. From the little I can understand of it, the
new challenge is generated into 'buffer', and sent back to the client in
the MS-CHAP-Error attribute (C=<new-challenge>). However the challenge in
buffer is not then "put somewhere safe" until the client sends it's
response against the new challenge [having re-prompted the user for the
correct password], and when the response comes in it isn't sent to
do_mschap()
Am I mistaken and this functionality hasn't been written yet? ...or have I
mis-configured something?
Ok - More delving into the code (rlm_eap_mschapv2.c) seems to indicate
that the bits missing in 2.1.x are possibly there in FR3:
+
+ /*
+ * Pxarse the new challenge out of the
+ * MS-CHAP-Error, so that if the client
+ * issues a re-try, we will know which
+ * challenge value that they used.
+ */
+ n = sscanf(response->vp_strvalue, "%*cE=%d R=%d C=%32s", &err, &retry,
&buf[0]);
+ if (n == 3) {
+ DEBUG2(" Found new challenge from MS-CHAP-Error: err=%d retry=%d
challenge=%s", err, retry, buf);
+ fr_hex2bin(buf, data->challenge, 16);
+ } else {
+ DEBUG2(" Could not parse new challenge from
MS-CHAP-Error: %d", n);
+ }
So I'll see about getting an FR3 test instance going :)
-James
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
