No EAP Start, assuming it's an on-going EAP conversation

[Matthew Newton]

On Tue, Nov 06, 2012 at 10:59:45PM -0000, dvmp wrote:
> [mschap]        expand: --nt-response=%{mschap:NT-Response:-00} ->
> --nt-response=3213a667f5405fe084a9e7291e326e0f0c68ce28482c998a
> Exec-Program output: NT_KEY: 56F8FF72C1E6DB98E25A86F7E98A3C53
> Exec-Program-Wait: plaintext: NT_KEY: 56F8FF72C1E6DB98E25A86F7E98A3C53
> Exec-Program: returned: 0
> [mschap] adding MS-CHAPv2 MPPE keys
> ++[mschap] returns ok
> MSCHAP Success
> ++[eap] returns handled

OK, mschap seems to succeed.

> } # server inner-tunnel
> [peap] Got tunneled reply code 11
...
> [peap] Got tunneled Access-Challenge
> ++[eap] returns handled
> Sending Access-Challenge of id 173 to ip_AP_cisco port 1645
>         EAP-Message =
> 0x0109005b190017030100505317a8177c77666155012c3211bf6b1c09ef17d29e1bb1fdcf91
> ae82bf7dc5baae0e670350b67151aefb6bc5e1f18861cd55c6cdb04a829d8d59349be4ae0f68
> a1ccd3f6714ea7a663b7c98ff3904cf9
>         Message-Authenticator = 0x00000000000000000000000000000000
>         State = 0x2bebcbfd2de2d2392b8b84ab35544cf2
> Finished request 386.
> Going to the next request
> Waking up in 4.9 seconds.

Client is sent the access challenge for the user's device with the mschap success.

> rad_recv: Access-Request packet from host ip_AP_cisco port 1645, id=174,
> length=167
>         User-Name = "DOMAIN\\userADaccount"
>         Framed-MTU = 1400
>         Called-Station-Id = "003a.994b.fd40"
>         Calling-Station-Id = "e02a.8255.86ba"
>         Service-Type = Login-User
>         Message-Authenticator = 0xbfbafd91f0c8db0b664454958ff46920
>         EAP-Message = 0x020200190153554d4f4c434f4d50414c5c5343313031383536

User's device sends back an EAP Identity

> [eap] EAP packet type response id 2 length 25
> [eap] No EAP Start, assuming it's an on-going EAP conversation

Which is why this isn't picked up as part of the previous PEAP
conversation, so the client isn't sent an Access-Accept

...

> Exec-Program: returned: 0
> [mschap] adding MS-CHAPv2 MPPE keys
> ++[mschap] returns ok
> MSCHAP Success
> ++[eap] returns handled
> } # server inner-tunnel
...
> ++[eap] returns handled
> Sending Access-Challenge of id 180 to ip_AP_cisco port 1645
>         EAP-Message =
> 0x0109005b190017030100502f79f75d930239412dc6c2abfbbed6c6930ef8ed21bedee2d972
> 9a2a1c987a285ddfd23ef4379fa1e6bf44ffa1eb1d08f8a24c50606ba462b9cbdf8c68923e52
> 72a032112af4c2f1af939b470d00b30b
>         Message-Authenticator = 0x00000000000000000000000000000000
>         State = 0xf9273f5cff2e268144e0f611590a6390
> Finished request 393.
> Going to the next request
> Waking up in 2.4 seconds.

...
repeat of last time.


The client has given up (that much is certain), so check EAP logs
on the client. If it's Windows, you probably don't stand much of a
chance of getting much useful (easy to read) logs. Check things
like certificates expiring (but it doesn't sound like this).

But first I'd restart winbind and see if it all works again. Then
check your domain join (net ads testjoin or similar). I've seen
similar before when everything individually worked OK, but the
clients didn't like something that was sent back. [0] I think
something has broken with the domain join, or winbind - it isn't
at all obvious, but the client doesn't like it. You could also try
re-joining the server to the domain.

Oh, and you want to upgrade FreeRADIUS to 2.2.0; there's a
security vulnerability in anything older.

Cheers

Matthew



[0] http://notes.asd.me.uk/2011/01/11/freeradius-and-ntlm_auth-reminder-from-a-silent-failure/


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>