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