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-s... -- 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>