ntlm_auth not respected

Wed Aug 21 20:28:14 CEST 2013

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