On Tue, Nov 06, 2012 at 10:59:45PM -0000, dvmp wrote:OK, mschap seems to succeed.
> [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
...
> } # server inner-tunnel
> [peap] Got tunneled reply code 11
> [peap] Got tunneled Access-ChallengeClient is sent the access challenge for the user's device with the mschap success.
> ++[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.
User's device sends back an EAP Identity
> 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
Which is why this isn't picked up as part of the previous PEAP
> [eap] EAP packet type response id 2 length 25
> [eap] No EAP Start, assuming it's an on-going EAP conversation
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@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@le.ac.uk>