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 <[email protected]> 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 <[email protected]> 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
