It seems that I have ntlm_auth configured to talk to Samba correctly. As it positively works when run from the CLI and FR even shows a positive login, but that positive login never seems to be sent to the authentication stage. More food for thought once I tackle this, is that when I try to link all this together with a Netgear WAP, plain-text users in the users file works perfectly fine. 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 [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 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.
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
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 = 0x0001000000000000000000000000000000000000000000000000b48195bef7a73a38839411904a51717092c530d4bef03520 # 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 (0xc000006a) Exec-Program-Wait: plaintext: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a) 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.mayers@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 {...} [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
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 (0xc000006a) Wrong Password (0xc000006a) Wrong Password (0xc000006a) Wrong Password (0xc000006a) Wrong Password (0xc000006a) Wrong Password (0xc000006a) Wrong Password (0xc000006a) 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 <cparkervt@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 = 0x0001000000000000000000000000000000000000000000000000b48195bef7a73a38839411904a51717092c530d4bef03520 # 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 (0xc000006a) Exec-Program-Wait: plaintext: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a) 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.mayers@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 {...} [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
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.
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.mayers@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
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.
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 = 0x0001000000000000000000000000000000000000000000000000065b157b183b4d29d455414b184c57af4912b1d74f4ed726 # 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! (0xc0000001) Exec-Program-Wait: plaintext: Reading winbind reply failed! (0xc0000001) 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! (0xc0000001)): [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.mayers@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
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 = 0x0001000000000000000000000000000000000000000000000000941d3ff95601f8f335e7eff7c97e1abf28df15abd28b7fda rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=52, length=84 MS-CHAP-MPPE-Keys = 0x0000000000000000d22b3a1df401aa61a721c8a31ba910820000000000000000 MS-MPPE-Encryption-Policy = 0x00000001 MS-MPPE-Encryption-Types = 0x00000006 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 <cparkervt@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 = 0x0001000000000000000000000000000000000000000000000000065b157b183b4d29d455414b184c57af4912b1d74f4ed726 # 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! (0xc0000001) Exec-Program-Wait: plaintext: Reading winbind reply failed! (0xc0000001) 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! (0xc0000001)): [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.mayers@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
On 22/08/13 15:14, Chris Parker wrote:
Exec-Program output: Reading winbind reply failed! (0xc0000001)
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
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.
participants (2)
-
Chris Parker -
Phil Mayers