[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