On Oct 21, 2014, at 8:22 AM, Dave Duchscher <daved@nostrum.com> wrote:
We had a strange case where a users was unable to authenticate with our VPN server but could on wireless. I think I have tracked down the problem and am hoping I can get help with a fix.
My test environment is a stock freeradius 2.2.5 server with default configuration files. The only change was to manually add the NT-Password to check to the authorize section.
update control { NT-Password := 'CD09F6070B94F498FC9D6668800E6854'; }
That is the NT hash for the password 'pass\word'. Test client is radtest on the same system.
radtest -d /usr/local/etc/raddb -t pap -x username pass\\word localhost 100 testing123
Testing this with the NT hash for the password 'password' works. When I test with password 'pass\word', I see the wrong NT hash being generated so authentication fails.
Tue Oct 21 08:03:54 2014 : Info: [pap] login attempt with password "pass\word" Tue Oct 21 08:03:54 2014 : Info: [pap] Using NT encryption. Tue Oct 21 08:03:54 2014 : Info: [pap] expand: %{User-Password} -> pass\\word Tue Oct 21 08:03:54 2014 : Info: [pap] NT-Hash of pass\\word = 5a022f09a08097a8f2ca5d16ef3df23e Tue Oct 21 08:03:54 2014 : Info: [pap] expand: %{mschap:NT-Hash %{User-Password}} -> 5a022f09a08097a8f2ca5d16ef3df23e Tue Oct 21 08:03:54 2014 : Info: [pap] Passwords don't match
From what I am seeing it look like the password is sent across correctly but then the backslash is escaped and that escaped result is hashed which gets us to the wrong hash.
Any ideas?
I fixed my problem by modifying rlm_pap to create the NT-Hash directly instead of using radius_xlat to send the request to the rlm_mschap module. This avoids all the escaping and expansion issues of radius_xlat with passwords that have characters like backslash, dollar sign, and curly braces. -- Dave