Recently we've seen an extreme corner case with Freeradius, and I'm a bit puzzled on what the best way would be to fix this. The scenario uses Windows clients on Wifi with single-sign-on, PEAP, Freeradius as the Radius server where the inner-tunnel is used, and an Active Directory as backend (this could be either NPS/Radius or Winbind/NTLM authentication, both show this behaviour). The problem does not occur when acting as a real Radius proxy and let the NPS handle the authentication completely. The problem arises when the user is in the AD backend with a certain casing (e.g. "john_doe") but is logging in with a different casing ("John_Doe"). The first authentication succeeds and John Doe's laptop is connected to the wifi. Then, the session expires and the client tries to reauthenticate. Both the inner and outer Radius packets still show "John_Doe" as User-Name attribute, but the authentication fails. I tried recalculating the MS-CHAP2-Response value, and it looks like this has been calculated using the "john_doe" value as username. I'm not exactly sure if it normalizes the username to lowercase here, or if it uses the value as given in the AD backend (in this testcase, both were lowercased, but it sounds more logical to me that the user-name with casing was found via the AD domain). First thing I tried was switching to using the ntlmauth executable instead of a Radius tunnel or Winbind-libs (it was on a system without a build environment, so making changes to the source was not really an option here) and build a wrapper around it: Try an authentication, and if that fails: lowercase the username, recalculate the value that is given as the --challenge-parameter with the new username and try a new authentication. If that fails too, the password is probably incorrect. I switched to ntlm_auth because I didn't exactly see an option to try another authentication with Radius. The authentication succeeded, but the MS-CHAP2-Response attribute in the reply was still based on the username with the incorrect casing, so that failed too. After adding a script in the post-auth to calculate the correct value (which didn't have access to the username used for the authentication, so it just had to blindly try an authentication again, if that failed: lowercase the username and use that), recalculate and everything worked. Well, it worked as far as the proof of concept was concerned, of course this is not exactly a setup you would use in a real environment. The only sensible setup I could think of was to include this within the winbind library user (which would be rlm_mschap here because it's a 3.0 setup): add a boolean config option to retry authentication with a normalized username and use that for further hash calculations. This allows the option to save the user-name used for the authentication hash to be saved in the "session", so we could use it again without have to attempt more authentications. Normalizing to lowercase is probably a bad idea, the `wbinfo` tool allows us to search for the user, we could probably use that too in the winbind libs (and it gives an extra reason why putting this in the winbind code would be a good idea) -- Herwin Weststrate