3com wx - peap-mschapv2 - freeradius - mysql

[Stefan Winter]

Hello,

> Hi Stefan,
> please to meet you, I'm following your discussion on "mobility" list. I am
> very interesting to EDUROAM here in Florence.

Ah, very good news indeed! You'll get Gold support from now on ;-)

> However, now I have checked "users" file; there was some DEFAULT row. Now I
> have correct it.
> I have tried to modify the "Auth-Type" in radcheck table to: EAP (was
> Local), but the result is similar. Have you any idea what is wrong now?

First, editing "users" made the "Local" go away, which is good. But as Phil 
said, setting Auth-Type manually is usually not necessary. Just leave the 
request alone. The server can find out by itself that it is an EAP message by 
the presence of the "EAP-Message" attribute. So, it will set Auth-Type = EAP 
itself. Since you also set it manually, it's there twice and a similar 
warning as before is spit out:

>    rad_check_password:  Found Auth-Type EAP
>    rad_check_password:  Found Auth-Type EAP
> Warning:  Found 2 auth-types on request for user 'agostini'

But that doesn't disturb the auth process in the initial phase. It might get 
in the way for the tunneled MS-CHAPv2 request later, so I suggest to take 
away the manual setting anyway.

As for the question why authentication doesn't work: Phil is right in saying 
that the client doesn't want to talk to the server after he received its 
certificate (it's not actually the NAS - the EAP conversation is almost 
completely transparent to the NAS).
The client doesn't like the server certificate, which may have a variety 
(non-FreeRADIUS caused) reasons:
- certificate has expired
- signed by a CA the client didn't expect or like
- the CN field configured in the client doesn't correspond to the one in the 
certificate
- the server certificate doesn't contain the Windows TLS Server Extension OID

Of all these reasons (there may be more), my guess is that the last one is 
true (as also suggested by Phil): if you use the native Windows XP 
supplicant, the server must have a specific OID in the certificate in order 
for authentication to work. You may want to search the mailing list archive 
for this OID and how to include it in a certificate. There are also a few 
HOWTOs out there.
The more proper solution though would be to _not_ use this incredibe freak of 
nature that calls itself the Windows XP supplicant, but instead use a nicer 
supplicant like the (free, open source) one at www.securew2.com (which speaks 
EAP-TTLS, which is more open and easier to handle than the built-in 
PEAP-MS-CHAPv2).

You can find out that the problem is more on the client side by looking 
towards the end of the logs:

> Sending Access-Challenge of id 36 to xxx.xxx.xxx.xxx:20002
>          Service-Type := Framed-User
>          Tunnel-Type:0 := VLAN
>          Tunnel-Private-Group-Id:0 := "ifac"
>          EAP-Message = 0x010c00061900
>          Message-Authenticator = 0x00000000000000000000000000000000
>          State = 0xfbbcc6567f4091f2cbd3633228aec4bc
> Finished request 9
> Going to the next request
> Waking up in 6 seconds...
> --- Walking the entire request list ---
> Cleaning up request 5 ID 32 with timestamp 44898894
> Cleaning up request 6 ID 33 with timestamp 44898894
> Cleaning up request 7 ID 34 with timestamp 44898894
> Cleaning up request 8 ID 35 with timestamp 44898894
> Cleaning up request 9 ID 36 with timestamp 44898894
> Nothing to do.  Sleeping until we see a request.

You sent something to the client, but it doesn't answer any more. It doesn't 
like your server. You can be fairly sure that there is no network problem 
underneath because the earlier Access-Challenge packets were answered by the 
client.

HTH,

Stefan Winter

-- 
Stefan WINTER

Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche - Ingénieur de recherche

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg