Re: ntlm_auth not respected
On 21/08/13 23:44, Chris Parker wrote: Okay, pardon my confusion then. I had been following a howto online and it reported that the command when run manually will produce the key. Either way, I'm still having a failure in MSCHAP with radtest that I'm not quite grasping. Well, as I explained in my other email, mschap == challenge/response, modules/ntlm_auth != challenge/response. To reiterate, modules/ntlm_auth is almost certainly not what you want, and is not intended to be used as-is. I would unconfigure it and concentrate on getting modules/mschap working. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ntlm_auth not respected
Thank you for setting me on the right track; I have followed the directions on
http://deployingradius.com/documents/configuration/active_directory.html (the
bottom section on MSCHAP) and have ntlm_auth in the authenticate {} - as per
those directions.
When I run the ntlm_auth command manually, it works find / as does running
wbinfo -a
root@leopard:/etc/freeradius# wbinfo -a wyse1%K503D
plaintext password authentication succeeded
challenge/response password authentication succeeded
Ready to process requests.
rad_recv: Access-Request packet from host 127.0.0.1 port 60046, id=111,
length=113
User-Name = wyse1
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
MS-CHAP-Challenge = 0xe07a375bed09f1f7
MS-CHAP-Response =
0x0001065b157b183b4d29d455414b184c57af4912b1d74f4ed726
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
[mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
++[mschap] returns ok
++[digest] returns noop
[suffix] No '@' in User-Name = wyse1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No known good password found for the user. Authentication may
fail because of this.
++[pap] returns noop
Found Auth-Type = MSCHAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group MS-CHAP {...}
[mschap] Told to do MS-CHAPv1 with NT-Password
[mschap]expand: %{Stripped-User-Name} -
[mschap]... expanding second conditional
[mschap] WARNING: Deprecated conditional expansion :-. See man unlang for
details
[mschap]expand: %{User-Name:-None} - wyse1
[mschap]expand: --username=%{%{Stripped-User-Name}:-%{User-Name:-None}}
- --username=wyse1
[mschap] mschap1: e0
[mschap]expand: --challenge=%{mschap:Challenge:-00} -
--challenge=e07a375bed09f1f7
[mschap]expand: --nt-response=%{mschap:NT-Response:-00} -
--nt-response=065b157b183b4d29d455414b184c57af4912b1d74f4ed726
Exec-Program output: Reading winbind reply failed! (0xc001)
Exec-Program-Wait: plaintext: Reading winbind reply failed! (0xc001)
Exec-Program: returned: 1
[mschap] External script failed.
[mschap] MS-CHAP-Response is incorrect.
++[mschap] returns reject
Failed to authenticate the user.
Login incorrect (mschap: External script says Reading winbind reply failed!
(0xc001)): [wyse1/via Auth-Type = mschap] (from client localhost port
1812)
Using Post-Auth-Type Reject
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} - wyse1
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 111 to 127.0.0.1 port 60046
Waking up in 4.9 seconds.
Cleaning up request 0 ID 111 with timestamp +15
Ready to process requests.
On Aug 22, 2013, at 5:50 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
On 21/08/13 23:44, Chris Parker wrote:
Okay, pardon my confusion then. I had been following a howto online
and it reported that the command when run manually will produce the
key.
Either way, I'm still having a failure in MSCHAP with radtest that
I'm not quite grasping.
Well, as I explained in my other email, mschap == challenge/response,
modules/ntlm_auth != challenge/response.
To reiterate, modules/ntlm_auth is almost certainly not what you want, and
is not intended to be used as-is. I would unconfigure it and concentrate on
getting modules/mschap working.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ntlm_auth not respected
Sorry for the individual emails, but I got things working with MSCHAP (w/
ntlm_auth) and WPA-EAP.
My issue was that when I got the two winbind errors, I did some more searching
and there's the potential that the freerad user did not have access to pipe
named: /var/run/samba/winbindd
That pipe is owned as follows:
drwxr-x--- 2 root winbindd_priv 60 Aug 22 11:15 winbindd_privileged/
That being the case, you need to add the user freerad to that group, so it can
execute with the right privileges.
Sending Access-Request of id 52 to 127.0.0.1 port 1812
User-Name = wyse1
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
MS-CHAP-Challenge = 0xf38d9f1a3dcb27e9
MS-CHAP-Response =
0x0001941d3ff95601f8f335e7eff7c97e1abf28df15abd28b7fda
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=52, length=84
MS-CHAP-MPPE-Keys =
0xd22b3a1df401aa61a721c8a31ba91082
MS-MPPE-Encryption-Policy = 0x0001
MS-MPPE-Encryption-Types = 0x0006
Now, is it safe to disable modules (by commenting them out of the sites-enabled
files) that aren't related to the MSCHAP process? This is just in passing
curiosity.
On Aug 22, 2013, at 10:14 AM, Chris Parker cparke...@me.com wrote:
Thank you for setting me on the right track; I have followed the directions
on http://deployingradius.com/documents/configuration/active_directory.html
(the bottom section on MSCHAP) and have ntlm_auth in the authenticate {} - as
per those directions.
When I run the ntlm_auth command manually, it works find / as does running
wbinfo -a
root@leopard:/etc/freeradius# wbinfo -a wyse1%K503D
plaintext password authentication succeeded
challenge/response password authentication succeeded
Ready to process requests.
rad_recv: Access-Request packet from host 127.0.0.1 port 60046, id=111,
length=113
User-Name = wyse1
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
MS-CHAP-Challenge = 0xe07a375bed09f1f7
MS-CHAP-Response =
0x0001065b157b183b4d29d455414b184c57af4912b1d74f4ed726
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
[mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
++[mschap] returns ok
++[digest] returns noop
[suffix] No '@' in User-Name = wyse1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No known good password found for the user. Authentication
may fail because of this.
++[pap] returns noop
Found Auth-Type = MSCHAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group MS-CHAP {...}
[mschap] Told to do MS-CHAPv1 with NT-Password
[mschap] expand: %{Stripped-User-Name} -
[mschap] ... expanding second conditional
[mschap] WARNING: Deprecated conditional expansion :-. See man unlang
for details
[mschap] expand: %{User-Name:-None} - wyse1
[mschap] expand: --username=%{%{Stripped-User-Name}:-%{User-Name:-None}}
- --username=wyse1
[mschap] mschap1: e0
[mschap] expand: --challenge=%{mschap:Challenge:-00} -
--challenge=e07a375bed09f1f7
[mschap] expand: --nt-response=%{mschap:NT-Response:-00} -
--nt-response=065b157b183b4d29d455414b184c57af4912b1d74f4ed726
Exec-Program output: Reading winbind reply failed! (0xc001)
Exec-Program-Wait: plaintext: Reading winbind reply failed! (0xc001)
Exec-Program: returned: 1
[mschap] External script failed.
[mschap] MS-CHAP-Response is incorrect.
++[mschap] returns reject
Failed to authenticate the user.
Login incorrect (mschap: External script says Reading winbind reply failed!
(0xc001)): [wyse1/via Auth-Type = mschap] (from client localhost port
1812)
Using Post-Auth-Type Reject
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} - wyse1
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 111 to 127.0.0.1 port 60046
Waking up in 4.9 seconds.
Cleaning up request 0 ID 111 with timestamp +15
Ready to process requests.
On Aug 22, 2013, at 5:50 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
On 21/08/13 23:44, Chris Parker wrote:
Okay, pardon my confusion then. I had been following a howto online
and it reported that the command when run manually will produce the
key.
Either way, I'm still having a failure in MSCHAP with radtest that
Re: ntlm_auth not respected
On 22/08/13 15:14, Chris Parker wrote: Exec-Program output: Reading winbind reply failed! (0xc001) Check the permissions on the winbind socket directory, specifically that the freeradius daemon user can access it; this is usually at: /var/cache/samba/winbindd_privileged or /var/lib/samba/winbindd_privileged - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ntlm_auth not respected
On 08/21/2013 05:11 AM, Chris Parker wrote:
Log output:
rad_recv: Access-Request packet from host 127.0.0.1 port 35826, id=114,
length=57
User-Name = wyse1
User-Password = K503D
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = wyse1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[ntlm_auth] expand: --username=%{mschap:User-Name} - --username=wyse1
[ntlm_auth] expand: --password=%{User-Password} - --password=K503D
Exec-Program output: NT_STATUS_OK: Success (0x0)
Exec-Program-Wait: plaintext: NT_STATUS_OK: Success (0x0)
Exec-Program: returned: 0
++[ntlm_auth] returns ok
You're running ntlm_auth in the authorize section, and then:
[pap] WARNING! No known good password found for the user. Authentication may
fail because of this.
++[pap] returns noop
ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the
user
...nothing in the authenticate section.
You either want:
authorize {
...
ntlm_auth
if (ok) {
update control {
Auth-Type := Accept
}
}
...
}
...or:
authorize {
...
# don't run ntlm_auth here, and right at the bottom
if (User-Password) {
# PAP request, tell ntlm_auth to run in authenticate
update control {
Auth-Type = ntlm_auth
}
}
}
authenticate {
Auth-Type ntlm_auth {
ntlm_auth
}
}
HOWEVER - you should note that the (EXTREMELY unfortunately named)
ntlm_auth module instance is usually not what you want for wireless.
Wireless is typically 802.1x with PEAP/MSCHAP, which will entail setting
up the ntlm_auth configuration *item* of the mschap module.
Read the extensive docs, wiki, and walkthrough on deployingradius.com
for more info.
Failed to authenticate the user.
Login incorrect: [wyse1/K503D] (from client localhost port 1812)
Using Post-Auth-Type Reject
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} - wyse1
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 7 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 7
Sending Access-Reject of id 114 to 127.0.0.1 port 35826
Waking up in 4.9 seconds.
Cleaning up request 7 ID 114 with timestamp +843
Ready to process requests.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ntlm_auth not respected
Thank you Phil!
That resolved my first steps, and I figured there was something like that. I
have poured over deployingfreeradius.com, but for the life of me I could not
find anything of assistance for my set up.
I have enabled the ntlm_auth line in modules/mschap but no password is sent to
ntlm_auth to be checked.
So the fact that it's failing makes sense, since there's no password being read
in and thus it fails authorize. So this is just escaping me on how to get the
password into ntlm_auth via MSCHAP.
On top of that, when my access point succeeds against the users file, I suspect
it's doing EAP but the logs never say I have detected EAP, setting EAP
rad_recv: Access-Request packet from host 127.0.0.1 port 60203, id=86,
length=113
User-Name = wyse1
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
MS-CHAP-Challenge = 0x9e2069a2b9faf93d
MS-CHAP-Response =
0x0001b48195bef7a73a38839411904a51717092c530d4bef03520
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
[mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
++[mschap] returns ok
++[digest] returns noop
[suffix] No '@' in User-Name = wyse1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[ntlm_auth] expand: --username=%{mschap:User-Name} - --username=wyse1
[ntlm_auth] expand: --password=%{User-Password} - --password=
Exec-Program output: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc06a)
Exec-Program-Wait: plaintext: NT_STATUS_WRONG_PASSWORD: Wrong Password
(0xc06a)
Exec-Program: returned: 1
++[ntlm_auth] returns reject
Invalid user: [wyse1/via Auth-Type = mschap] (from client localhost port 1812)
Using Post-Auth-Type Reject
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} - wyse1
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 86 to 127.0.0.1 port 60203
Waking up in 4.9 seconds.
Cleaning up request 0 ID 86 with timestamp +6
Ready to process requests.
On Aug 21, 2013, at 3:25 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
On 08/21/2013 05:11 AM, Chris Parker wrote:
Log output:
rad_recv: Access-Request packet from host 127.0.0.1 port 35826, id=114,
length=57
User-Name = wyse1
User-Password = K503D
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = wyse1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[ntlm_auth] expand: --username=%{mschap:User-Name} - --username=wyse1
[ntlm_auth] expand: --password=%{User-Password} - --password=K503D
Exec-Program output: NT_STATUS_OK: Success (0x0)
Exec-Program-Wait: plaintext: NT_STATUS_OK: Success (0x0)
Exec-Program: returned: 0
++[ntlm_auth] returns ok
You're running ntlm_auth in the authorize section, and then:
[pap] WARNING! No known good password found for the user. Authentication
may fail because of this.
++[pap] returns noop
ERROR: No authenticate method (Auth-Type) found for the request: Rejecting
the user
...nothing in the authenticate section.
You either want:
authorize {
...
ntlm_auth
if (ok) {
update control {
Auth-Type := Accept
}
}
...
}
...or:
authorize {
...
# don't run ntlm_auth here, and right at the bottom
if (User-Password) {
# PAP request, tell ntlm_auth to run in authenticate
update control {
Auth-Type = ntlm_auth
}
}
}
authenticate {
Auth-Type ntlm_auth {
ntlm_auth
}
}
HOWEVER - you should note that the (EXTREMELY unfortunately named)
ntlm_auth module instance is usually not what you want for wireless.
Wireless is typically 802.1x with PEAP/MSCHAP, which will entail setting up
the ntlm_auth configuration *item* of the mschap module.
Read the extensive docs, wiki, and walkthrough on deployingradius.com for
more info.
Failed to authenticate the user.
Login incorrect: [wyse1/K503D] (from client localhost port 1812)
Using Post-Auth-Type Reject
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group REJECT {...}
Re: ntlm_auth not respected
When I poke around and try to deconstruct the issue, I find that ntlm_auth when
run manually retrieve the NT key, it does not do anything. It just says
NT_STATUS_OK: Success (0x0)
If I run the --diagnostics flag this is what I get...
root@leopard:/etc/freeradius# ntlm_auth --domain=WONKY --username=wyse1
--diagnostics
password:
Wrong Password (0xc06a)
Wrong Password (0xc06a)
Wrong Password (0xc06a)
Wrong Password (0xc06a)
Wrong Password (0xc06a)
Wrong Password (0xc06a)
Wrong Password (0xc06a)
So I doubt this issue is with FR, but more of that Samba is being cranky. I can
never get ntlm_auth to give me that NT key, which I feel if I could resolve
that, I could continue with FR.
On Aug 21, 2013, at 8:55 AM, Chris Parker cparke...@me.com wrote:
Thank you Phil!
That resolved my first steps, and I figured there was something like that. I
have poured over deployingfreeradius.com, but for the life of me I could not
find anything of assistance for my set up.
I have enabled the ntlm_auth line in modules/mschap but no password is sent
to ntlm_auth to be checked.
So the fact that it's failing makes sense, since there's no password being
read in and thus it fails authorize. So this is just escaping me on how to
get the password into ntlm_auth via MSCHAP.
On top of that, when my access point succeeds against the users file, I
suspect it's doing EAP but the logs never say I have detected EAP, setting
EAP
rad_recv: Access-Request packet from host 127.0.0.1 port 60203, id=86,
length=113
User-Name = wyse1
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
MS-CHAP-Challenge = 0x9e2069a2b9faf93d
MS-CHAP-Response =
0x0001b48195bef7a73a38839411904a51717092c530d4bef03520
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
[mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
++[mschap] returns ok
++[digest] returns noop
[suffix] No '@' in User-Name = wyse1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[ntlm_auth] expand: --username=%{mschap:User-Name} - --username=wyse1
[ntlm_auth] expand: --password=%{User-Password} - --password=
Exec-Program output: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc06a)
Exec-Program-Wait: plaintext: NT_STATUS_WRONG_PASSWORD: Wrong Password
(0xc06a)
Exec-Program: returned: 1
++[ntlm_auth] returns reject
Invalid user: [wyse1/via Auth-Type = mschap] (from client localhost port
1812)
Using Post-Auth-Type Reject
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} - wyse1
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 86 to 127.0.0.1 port 60203
Waking up in 4.9 seconds.
Cleaning up request 0 ID 86 with timestamp +6
Ready to process requests.
On Aug 21, 2013, at 3:25 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
On 08/21/2013 05:11 AM, Chris Parker wrote:
Log output:
rad_recv: Access-Request packet from host 127.0.0.1 port 35826, id=114,
length=57
User-Name = wyse1
User-Password = K503D
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
# Executing section authorize from file
/etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = wyse1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[ntlm_auth] expand: --username=%{mschap:User-Name} -
--username=wyse1
[ntlm_auth] expand: --password=%{User-Password} - --password=K503D
Exec-Program output: NT_STATUS_OK: Success (0x0)
Exec-Program-Wait: plaintext: NT_STATUS_OK: Success (0x0)
Exec-Program: returned: 0
++[ntlm_auth] returns ok
You're running ntlm_auth in the authorize section, and then:
[pap] WARNING! No known good password found for the user. Authentication
may fail because of this.
++[pap] returns noop
ERROR: No authenticate method (Auth-Type) found for the request: Rejecting
the user
...nothing in the authenticate section.
You either want:
authorize {
...
ntlm_auth
if (ok) {
update control {
Auth-Type := Accept
}
}
...
}
...or:
authorize {
...
# don't run ntlm_auth here, and right
Re: ntlm_auth not respected
On 21/08/2013 19:28, Chris Parker wrote: So I doubt this issue is with FR, but more of that Samba is being cranky. I can never get ntlm_auth to give me that NT key, which I feel if I could resolve that, I could continue with FR. No. NT_KEY is only generated by mschap, not by username/password auth. See my other email. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ntlm_auth not respected
On 21/08/2013 13:55, Chris Parker wrote: Thank you Phil! That resolved my first steps, and I figured there was something like that. I have poured over deployingfreeradius.com, but for the life of me I could not find anything of assistance for my set up. Yeah... to be honest, I think I've just confused matters. I have enabled the ntlm_auth line in modules/mschap but no password is sent to ntlm_auth to be checked. So the fact that it's failing makes sense, since there's no password being read in and thus it fails authorize. So this is just escaping me on how to get the password into ntlm_auth via MSCHAP. On top of that, when my access point succeeds against the users file, I suspect it's doing EAP but the logs never say I have detected EAP, setting EAP I see a lot of confusion in that paragraph. In brief: RADIUS supports multiple authentication algorithms, and the client chooses the algorithm. modules/ntlm_auth can only handle PAP, which sends a username password. modules/mschap can handle MSCHAP, which sends a challenge/response based on the password eap handles EAP, and then calls other modules to handle what runs inside the EAP tunnel. You're getting confused because you seem to be trying to configure modules/ntlm_auth to handle MSCHAP, which won't work. MSCHAP doesn't send the password to the server; just a one-time function of it. My advice - go back to the default configs, and ignore modules/ntlm_auth. It's not really intended for use as-is; it's a sample config for people to build on if the have advanced knowledge of the server. Re-read the stuff on deployingradius.com - if you're trying to do WPA-Enterprise (aka 802.1x) then it is definitive. If you're trying to do something else, describe what, and show a *full* debug of a client trying and failing. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ntlm_auth not respected
Okay, pardon my confusion then. I had been following a howto online and it reported that the command when run manually will produce the key. Either way, I'm still having a failure in MSCHAP with radtest that I'm not quite grasping. On Aug 21, 2013, at 17:49, Phil Mayers p.may...@imperial.ac.uk wrote: On 21/08/2013 19:28, Chris Parker wrote: So I doubt this issue is with FR, but more of that Samba is being cranky. I can never get ntlm_auth to give me that NT key, which I feel if I could resolve that, I could continue with FR. No. NT_KEY is only generated by mschap, not by username/password auth. See my other email. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
