> 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.

My feelings exactly :)

> 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).

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to