Garber, Neal wrote:
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).
That seems to be a good explanation for it.
Does this seem like a plausible explanation for what’s happening?
Yes.
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!
Well... that's a good reason to make sure we do it right. Any day where we can replace another RADIUS server with FreeRADIUS is a good day.
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 suspect that it will. The mschap module should also pass the Name field when calling ntlm_auth, too. And maybe print a warning if the fields are different.
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.
Hmm... Microsoft is aberrant. I agree. :) And it gets a lot worse. What do you do when the password is internationalized? Even the Microsoft people I talk to say "good luck". Alan DeKok.