MSCHAP Authentication Issue

[Garber, Neal]

I realize that this issue has been brought up many times in the past.  However, I believe I have new information that I haven't seen reported before..

I'm having a problem with Windows XP supplicant authenticating to FR with PEAP/MSCHAPv2 where authentication fails "sometimes" depending upon various factors.  The same device I'm using to test wireless authentication, never has an issue authenticating to my old dain-bramaged Cisco ACS servers.  As a result, I decided to investigate what might be different about FreeRadius (perhaps Samba I thought, but didn't want to make assumptions).

I don't profess to be an MS-CHAP expert, so what I'm about to say may be completely off-base.. After performing many tests (see below) and reviewing RFC2579 and the code in rlm_mschap.c, I'm hypothesizing that the problem is with how rlm_mschap calculates the challenge hash that is passed to ntlm_auth.  Specifically, rlm_mschap uses the User-Name attribute as part of the calculation of the hash.  What I'm finding is that, in some cases, the User-Name attribute doesn't match the case of the Name field in the MS-CHAP response (i.e., the userid is the same, it just differs in case).  In the tests I've performed, when these userids don't match in case, I get a Logon Failure from ntlm_auth.  I'd really like this to "just work" as is commonly said around these parts without additional gymnastics (such as changing all userids to lowercase).

Does this seem like a plausible explanation for what's happening?  If not, does anyone have any other ideas?  I need to resolve this in order to retire two old and cranky (and fairly useless because they don't really do authorization) ACS servers!  I'm going to try a change to rlm_mschap so it passes the Name field from the MS-CHAP response to the challenge_hash function (as opposed to the User-Name attribute) to see if that resolves the issue.  I realize that ultimately it's Windows fault that it doesn't pass the userid with consistent case (i.e., Identity vs. MS-CHAP response); but, I don't want the ACS server to be seen as a better, more tolerant solution.  So, it would be great to make FR more tolerant of this aberrant behaviour.

Thanks in advance for any advice/help/suggestions you can provide..

Here's what I tested and what I observed that caused me to draw the above conclusion:

Background: Windows XP SP3 laptop using std. Windows wireless supplicant EAP/PEAP/MS-CHAPv2 -> Cisco 1232AP -> FR 2.1.6 (with rlm_perl patch) running on FreeBSD 7.2.  In all the tests below, the same SSID, wireless network configuration on the laptop, AP, userid and password were used (the domain and user listed below are contrived, but are representative of the case I saw in the debug output).

Laptop Logon Method

Wireless Credentials Passed Man/Auto

MS-CHAP Response Packet Name field

User-Name Request Attribute

ntlm_auth Authentication Result

Domain logon (via Ethernet) with all lowercase userid entered on gina

Manually entered all lowercase userid when supplicant prompted

MYDOMAIN\myuser

MYDOMAIN\myuser

SUCCESS

Domain logon (via Ethernet) with all lowercase userid entered on gina

Supplicant configured to auto. pass Windows credentials

MYDOMAIN\MyuseR

MYDOMAIN\myuser

Logon failure (0xc000006d)

Locally cached credentials (on laptop) with all lowercase userid entered on gina

Manually entered all uppercase userid when supplicant prompted

MYUSER

MYUSER

SUCCESS

Locally cached credentials (on laptop) with all lowercase userid entered on gina

Manually entered all lowercase userid when supplicant prompted

myuser

myuser

SUCCESS

Locally cached credentials (on laptop) with all lowercase userid entered on gina

Supplicant configured to auto. pass Windows credentials

MYDOMAIN\MyuseR

MYDOMAIN\MyuseR

SUCCESS


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090814/bd56eed3/attachment.html>