FW: MSCHAP Authentication Issue
I apologize for posting in the wrong list (and for posting this again - I'm doing so to allow the thread to continue on the proper list)..
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 constructed a test program by extracting challenge_hash from rlm_mschap.c (and all supporting functions). I then extracted the peer challenge, authenticator challenge and NT-Response from the debug output of a failed request (User-Name was all lowercase, Name field was mixed case). I called challenge_hash with the all lowercase userid (to ensure it generated the same challenge as the failed request) - the challenge was identical. I then generated another challenge with the userid from the Name field in the response. Then, I executed ntlm_auth manually with the original challenge and the new challenge. The original failed (as I expected) and, low and behold, the new challenge (created using the Name field's userid) succeeded! I will now proceed to create a patch. I was planning to do a strncasecmp to ensure the only difference between the userid part of User-Name and the userid part of the Name field is case. If there are non-case differences, do you think a RLM_REJECT is in order or do you think it should just warn and use whatever is present (I can't think of a normal case where this would occur, but if you think this is better, then I would definitely use the Name field for the username parameter too)? I was thinking of rejecting the request, in this case, so this couldn't be used to bypass authorization. Interestingly, I copied the challenge and response from a successful and failed attempt and manually called ntlm_auth varying the case of the --username parameter and it didn't affect the results. In other words, --username=MYUSER or --username=myuser or --username=MyuseR all behave the same if the --challenge and --nt-response are correct).
Garber, Neal wrote:
I constructed a test program by extracting challenge_hash from rlm_mschap.c (and all supporting functions). I then extracted the peer challenge, authenticator challenge and NT-Response from the debug output of a failed request (User-Name was all lowercase, Name field was mixed case). I called challenge_hash with the all lowercase userid (to ensure it generated the same challenge as the failed request) - the challenge was identical. I then generated another challenge with the userid from the Name field in the response. Then, I executed ntlm_auth manually with the original challenge and the new challenge. The original failed (as I expected) and, low and behold, the new challenge (created using the Name field's userid) succeeded!
OK. That warrants a fix.
I will now proceed to create a patch. I was planning to do a strncasecmp to ensure the only difference between the userid part of User-Name and the userid part of the Name field is case. If there are non-case differences, do you think a RLM_REJECT is in order or do you think it should just warn and use whatever is present (I can't think of a normal case where this would occur, but if you think this is better, then I would definitely use the Name field for the username parameter too)? I was thinking of rejecting the request, in this case, so this couldn't be used to bypass authorization.
I think that if the NAME and User-Name fields are substantially different, the module should return a reject. This gets hard when you have DOMAIN\user, user@domain, and various kinds of realm stripping.
Interestingly, I copied the challenge and response from a successful and failed attempt and manually called ntlm_auth varying the case of the --username parameter and it didn't affect the results. In other words, --username=MYUSER or --username=myuser or --username=MyuseR all behave the same if the --challenge and --nt-response are correct).
Because ntlm_auth does little more than hand the data to Active Directory. Presumably Active directory has some way of working around this issue. Alan DeKok.
I have attached the patch that corrects the calculation of the MS-CHAP challenge hash that is passed to ntlm_auth. This patch fixes issues that occur, in some circumstances, with userid case sensitivity. I'm new to git, so I apologize, in advance, if I didn't do this correctly. I did: $ git clone git://git.freeradius.org/freeradius-server.git radiusd $ cd radiusd $ git checkout -b local ... made changes $ git add . $ git commit $ git format-patch origin If I should have done something differently, please let me know and I will do so next time. (Also, if you want me to redo this patch differently, I can do that too.) Thanks..
participants (2)
-
Alan DeKok -
Garber, Neal