[RADIATOR] eap + apple products - failed auth

Amândio Antunes Gomes Silva amandio at scom.uminho.pt
Wed Mar 7 11:19:14 CST 2012


Hi, Heikki!

Hi, list!

 

I followed Heikki's  instructions, but with no success. I made some further investigation and realized that the Access-Accept received by Radiator from the IAS server isn't forwarded to the client. I 'sniffed' the Ethernet traffic using tcpdump in the radiator server, and the Access-Accept packet isn't sent to the client. I sniffed a PEAP-MSCHAPV2 (which works) and a TTLS/MSCHAPV2 and compared the packets. In the TTLS/MSCHAPV2, the process ends with a Challenge issued by Radiator, and sent to the NAS, but it seemed that the NAS doesn't send it back to the client. I then investigate further and discovered that the AP tries to send packets to the client, but it reports an error (see below). After this, I suppose that it's a problem related to the Mac OS Supplicant.  Any hint on how to solve this?

 

Best regards,

 

Amândio

 

Additional Info:

 

TCPDUMP (between NAS and radiator radius server):

 

reading from file MacOS-TTLS-MSCHAPV2-7.pcap, link-type EN10MB (Ethernet)

16:47:16.536506 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x2b length: 217

16:47:16.560307 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x2b length: 46

16:47:16.570428 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x2c length: 356

16:47:16.628723 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x2c length: 1082

16:47:16.710643 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x2d length: 198

16:47:16.738682 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x2d length: 1078

16:47:16.895393 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x2e length: 198

16:47:16.931681 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x2e length: 1078

16:47:17.027529 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x2f length: 198

16:47:17.053752 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x2f length: 1078

16:47:17.208341 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x30 length: 198

16:47:17.230283 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x30 length: 659

16:47:17.243674 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x31 length: 530

16:47:17.309004 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x31 length: 109

16:47:17.552920 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x32 length: 351

16:47:17.637727 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x32 length: 263

16:47:19.932943 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x33 length: 217

16:47:19.956708 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x33 length: 46

16:47:19.963244 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x34 length: 388

16:47:19.991490 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x34 length: 1082

16:47:20.022300 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x35 length: 198

16:47:20.052285 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x35 length: 1078

16:47:20.181138 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x36 length: 198

16:47:20.216984 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x36 length: 1078

16:47:20.339282 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x37 length: 198

16:47:20.360917 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x37 length: 1078

16:47:20.372684 IP 172.16.45.66.datametrics > radius-server.radius: RADIUS, Access Request (1), id: 0x38 length: 198

16:47:20.403901 IP radius-server.radius > 172.16.45.66.datametrics: RADIUS, Access Challenge (11), id: 0x38 length: 659

 

MacOS syslog (via console):

 

Mar  7 16:47:16 macbookproscom eapolclient[4092]: en1 START

Mar  7 16:47:17 macbookproscom eapolclient[4092]: TTLS: authentication failed with status 1

 

Access Point:

 

Mar  7 16:47:20 apb-scom-0b-glt 45: Mar  7 16:47:19.444 WET: %DOT11-4-MAXRETRIES: Packet to client f0b4.7916.ce7b reached max retries, removing the client

 

Note: The IP address of apb-scom-0b-glt is 172.16.45.66.

 

TIA,

 

Best regards,

Amândio Antunes Gomes da Silva

-----------------------------------------------------------------------------------------------------------------------------------

Serviços de Comunicações da Universidade do Minho

Campus de Gualtar, 4710-057 Braga - Portugal

Tel.: + 351 253 60 40 20, Fax: +351 253 60 40 21

VoIP: amandio at scom.uminho.pt <sip:amandio at scom.uminho.pt> 

email: amandio at scom.uminho.pt <mailto:amandio at scom.uminho.pt>  | http://www.scom.uminho.pt <http://www.scom.uminho.pt/> 

-----------------------------------------------------------------------------------------------------------------------------------

This email is confidential. If you are not the intended recipient, 

you must not disclose or use the information contained in it.

If you have received this mail in error, please tell us immediately 

by return email and delete the document.

 

 

-----Mensagem original-----

De: Heikki Vatiainen [mailto:hvn at open.com.au] 

Enviada: segunda-feira, 5 de Março de 2012 22:59

Para: Amândio Antunes Gomes Silva

Cc: radiator at open.com.au

Assunto: Re: [RADIATOR] eap + apple products - failed auth

 

On 03/01/2012 06:35 PM, Amândio Antunes Gomes Silva wrote:

 

> I'm struggling to solve a problem similar to this one for a while, but

> the scenario is a little bit different: in our wireless network (eduroam

> with WPA/Enterprise) we support TTLS/PAP, TTLS/MSCHAPv2 and PEAP

> authentication methods, which works fine for all kind of devices, but

> Apple one's, which work fine with all of this, but TTLS/MSCHAPv2. The

> Apple clients get authenticated, the connections last for 5 to 10

> seconds and then it drops, never getting the IP address. Analyzing the

> logs, I see an Access-Accept just followed by a Challenge which, I

> think, makes the connection to not succeed.

 

Yes, the client would need to reply so that Access-Accept could be sent

back to the NAS.

 

The problem here might with the attributes that get tunnlled back to the

client. If you search the log for "Returned TTLS tunnelled", there are

e.g. Framed-IP-Address, MS-MPPE-* and Tunnel-* attributes that are sent

to the client.

 

I would try changing this by adding StripFromRequest to the inner

Handler to strip Framed-IP-Address and MS-MPPE-* attributes. The

MS-MPPE-* attributes will be added by the outer Handler for

Access-Accept. If they are received over the tunnelled request, they

could just confuse the client.

 

Thanks!

Heikki

 

 

> Once TTLS/MSCHAPv2 is the default authentication method in Apple

> devices, it's impossible for our new users to connect to the eduroam

> for the first time (by simply enter their username/password when

> prompted) without edit the connection properties, what can be tricky,

> especially now that Mac OSX Lion don't let you do this manually,

> unless you have a mobile.config configuration file with the proper

> parameters. Anyone have some idea on how to solve this?

 

 

 

> 

>  

> 

> Some important notes:

> 

> 1.       The PEAP and TTLS/MSCHAPV2 requests, as you can see, are

> proxied to an ISA server, which I don't have admin rights on.

> 

> 2.       The TTLS/PAP requests are handled by an <AuthBy LDAP>, with the

> ServerChecksPassword enabled (that's why it doesn't handle MSCHAPV2).

> 

> 3.       There is a ReplyHook used to correct some attributes that are

> sent by the ISA server, mainly the Tunnel-Private-Group-ID, used to put

> each user in his VLAN, according to his type.

> 

> 4.       Mac OSX 10.6.8 (Snow Leopard) with TTLS/MSCHAP, PEAP and

> TTLS/PAP works fine.

> 

> 5.       Mac OSX 10.6.8 doesn't work with TTLS/MSCHAPV2 (mac syslog

> reports "TTLS: authentication failed with status 1").

> 

>  

> 

>  

> 

> Our config is:

> 

>  

> 

> The authenticator for PEAP/MSCHAPV2:

> 

>  

> 

> <AuthBy RADIUS>

> 

>   NoEAP

> 

> # RewriteUsername s/^([^@]+).*/$1\@%{W}/

> 

>   Identifier      PEAPnoSAPIA

> 

>   Host            ***.***.***.***

> 

>   Secret          ********

> 

>   AuthPort        1812

> 

>   AcctPort        1813

> 

>   EAPType         PEAP,TTLS,TLS,MSCHAP-V2,MSCHAPV2

> 

>   Description     PEAP no SAPIA

> 

>   Retries         5

> 

>   RetryTimeout    30 

> 

>   ReplyHook       file:"/etc/radiator/rh-postauth.pl"

> 

>   EAPTLS_PEAPVersion  0

> 

> </AuthBy>

> 

>  

> 

> The Handlers

> 

> ...

> 

> <Handler ConvertedFromEAPMSCHAPV2=1>

> 

>   AuthByPolicy  ContinueUntilAcceptOrChallenge

> 

>   AuthLog peaplog

> 

>   StripFromRequest ConvertedFromEAPMSCHAPV2

> 

>   AuthBy  PEAPnoSAPIA

> 

> </Handler>

> 

>  

> 

> <Handler TunnelledByPEAP=1>

> 

>   AuthByPolicy ContinueUntilAcceptOrChallenge

> 

>   <AuthBy FILE>

> 

>     # Dont really need this

> 

>     Filename %D/users

> 

>  

> 

>     # This tells the PEAP client what types of inner EAP requests

> 

>     # we will honour

> 

>     EAPType MSCHAP-V2

> 

>  

> 

>     # This flag tells EAPType MSCHAP-V2 to convert the inner

> EAP-MSCHAPV2 request into

> 

>     # an ordinary Radius-MSCHAPV2 request and redespatch to to a Handler

> 

>     # that matches ConvertedFromEAPMSCHAPV2=1 (see above)

> 

>     EAP_PEAP_MSCHAP_Convert 1

> 

>   </AuthBy>

> 

>   PostProcessingHook file:"/etc/radiator/eap_acct_username_orig.pl"

> 

> </Handler>

> 

>  

> 

> <Handler TunnelledByTTLS=1, MS-CHAP-Challenge =/.+$/>

> 

>   AcctLogFileName /var/log/radius/radacct/%Y%m

> 

>   AuthByPolicy  ContinueUntilAcceptOrChallenge

> 

>   AuthBy  PEAPnoSAPIA

> 

>   PostProcessingHook file:"/etc/radiator/eap_acct_username_orig.pl"

> 

> </Handler>

> 

>  

> 

> <Handler TunnelledByTTLS=1>

> 

>   AcctLogFileName /var/log/radius/radacct/%Y%m

> 

>   AuthByPolicy  ContinueUntilAcceptOrChallenge

> 

>   AuthBy  Auth-SAPIA

> 

>   PostProcessingHook file:"/etc/radiator/eap_acct_username_orig.pl"

> 

> </Handler>

> 

>  

> 

> <Handler Realm=/uminho.pt$/ >

> 

>   AcctLogFileName /var/log/radius/radacct/%Y%m

> 

>   AuthBy SQLAccounting

> 

>   Description SSID eduroam para utilizadores uminho.pt

> 

>   Identifier  REALM-UMINHO

> 

>   RejectHasReason

> 

>   <AuthBy FILE>

> 

>     # the %D/users file can be empty, its there for normal PAP

> 

>     # authentication. This can however be used for the WEB captive

> 

>     # portals.

> 

>     Filename %D/users

> 

>     EAPTLS_CAFile /etc/radiator/certs/8675909-usertrust.ca-bundle

> 

>     EAPTLS_CertificateFile /etc/radiator/certs/server.crt

> 

>     EAPTLS_CertificateType PEM

> 

>     EAPTLS_MaxFragmentSize 1024

> 

>     EAPTLS_PrivateKeyFile /etc/radiator/certs/server.key

> 

>     EAPType TTLS, PEAP

> 

>     AutoMPPEKeys

> 

>   </AuthBy FILE>

> 

>   PreProcessingHook file:"/etc/radiator/radius.rewriteMAC.pl"

> 

> </Handler>

> 

>  

> 

> The Logs:

> 

> See attached file.

> 

>  

> 

>  

> 

> Best regards,

> 

>  

> 

> *Amândio Antunes Gomes da Silva*

> 

> -----------------------------------------------------------------------------------------------------------------------------------

> 

> Serviços de Comunicações da Universidade do Minho

> 

> Campus de Gualtar, 4710-057 Braga - Portugal

> 

> Tel.: + 351 253 60 40 20, Fax: +351 253 60 40 21

> 

> VoIP: amandio at scom.uminho.pt <sip:amandio at scom.uminho.pt>

> 

> email: amandio at scom.uminho.pt <mailto:amandio at scom.uminho.pt> |

> http://www.scom.uminho.pt <http://www.scom.uminho.pt/>

> 

> -----------------------------------------------------------------------------------------------------------------------------------

> 

> This email is confidential. If you are not the intended recipient,

> 

> you must not disclose or use the information contained in it.

> 

> If you have received this mail in error, please tell us immediately

> 

> by return email and delete the document.

> 

>  

> 

>  

> 

CUT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20120307/f64b09f7/attachment-0001.html 


More information about the radiator mailing list