Hi,
now I have reinstalled the PF server and configured the AD Auth like
described in the documentation but with no success.
I get the same error message like before.
I have no idea where the mistake is. Maybe there is a bug?
Greetings
Tobias
2016-03-23 16:29 GMT+01:00 Tobias Friede <[email protected]>:
> Hi,
>
> I have no Idea where the problem is, today I recreated the Domain config,
> enabled NTLM logging on my DC, sniffed the traffic with Wireshark, tried
> different SAMBA version.... but no Idea where the problem is :(
>
> *so here are my logs (created a new user for that to):*
>
> [root@NAC adminuser]# chroot /chroots/BS-3/ ntlm_auth --username=radtest
> --password=radtest123 --request-nt-key
>
> NT_STATUS_OK: Success (0x0)
>
> *Seems to be OK, now I try to auth via PEAP:*
> *In the RADIUS Debugging log i see the same error message like before:*
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] Creating challenge
> hash with username: radtest
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] Client is using
> MS-CHAPv2 for radtest, we need NT-Password
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] expand:
> /chroots/%{PacketFence-Domain} -> /chroots/BS-3
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] expand:
> --username=%{mschap:User-Name:-None} -> --username=radtest
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] Creating challenge
> hash with username: radtest
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] expand:
> --challenge=%{mschap:Challenge:-00} -> --challenge=7a25a654d3f14436
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] expand:
> --nt-response=%{mschap:NT-Response:-00} ->
> --nt-response=c5c1e007118215e18d61bd9f377a49a9a355cd1cdc52926a
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] Exec: program
> returned: 139
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] External script failed.
>
> Wed Mar 23 16:18:25 2016 : Debug: [chrooted_mschap] FAILED:
> MS-CHAP2-Response is incorrect
>
> Wed Mar 23 16:18:25 2016 : Debug: +++[chrooted_mschap] = reject
>
>
> *The Radius log on the PF WebIf shows this:*
> chrooted_mschap: External script says NT_KEY:
> 6B6C9DD14B1F277EE02E7515E6065298
>
> *Auth with Challange:*
> [root@NAC adminuser]# chroot /chroots/BS-3/ ntlm_auth --username=radtest
> --challenge=7a25a654d3f14436
> --nt-response=c5c1e007118215e18d61bd9f377a49a9a355cd1cdc52926a
> --request-nt-key
>
> NT_KEY: 6B6C9DD14B1F277EE02E7515E6065298
>
> Tanks for your patience with me :)
>
> Greetings
> Tobias
>
>
>
>
> 2016-03-23 15:37 GMT+01:00 Louis Munro <[email protected]>:
>
>>
>>
>> On Mar 22, 2016, at 14:45 , Tobias Friede <[email protected]> wrote:
>>
>> it's very strange, I get different error messages for auth with the
>> correct password an with a wrong password.
>> With correct password (ntlm_auth in chroot is working), I get this fail
>> reason: chrooted_mschap: External script says NT_KEY:
>> B002F4642C1050FB999F6AF5B3502F9F
>> With wrong password I get this: chrooted_mschap: External script says
>> Logon failure (0xc000006d)
>>
>>
>> That is the expected behaviour.
>> ntlm_auth is supposed to return the NT_KEY upon successful authentication.
>> Any return code other than 0 means that the authentication failed.
>>
>> Unfortunately the eapol_test output is not going to show us anything
>> interesting in this case.
>> The problem is between the PacketFence server and (possibly) the Active
>> Directory.
>> All the eapol_test output proves is that it really uses the password you
>> expect it to.
>>
>> I would be more interested in seeing first the output from the ntlm_auth
>> calls done manually, and then through FreeRADIUS.
>> That is to say you should try something like the following:
>>
>> # chroot /chroots/BS ntlm_auth —username ‘fritob’ —password
>> MYSECRETPASSWORD --request-nt-key
>>
>> If that works, then compare it with the debugging output of FreeRADIUS.
>>
>> FreeRADIUS isn’t doing anything fancier than calling ntlm_auth itself and
>> then checking the return code.
>> If it’s 0 then the request is authenticated, anything else is rejected.
>>
>> You can also try to manually call ntlm_auth with the same parameters as
>> what FreeRADIUS does.
>> FreeRADIUS will print out those parameters when running in debug mode (or
>> under raddebug).
>> So you could copy them and try something like:
>>
>> # chroot /chroots/BS ntlm_auth —username {whatever FR sees as username}
>> —challenge {FR challenge} —nt-response —request-nt-key
>>
>> If that does not work, it could indicate that either the username or
>> password sent to FR is incorrect (or the account is locked out etc.)
>>
>> FreeRADIUS will never actually see your password.
>> It’s not sent in a PEAP request.
>> Only a challenge is sent.
>>
>> Regards,
>> --
>> Louis Munro
>> [email protected] :: www.inverse.ca
>> +1.514.447.4918 x125 :: +1 (866) 353-6153 x125
>> Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (
>> www.packetfence.org)
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
>> _______________________________________________
>> PacketFence-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>
>>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
