[RADIATOR] eap + apple products - failed auth
Heikki Vatiainen
hvn at open.com.au
Wed Mar 7 12:55:48 CST 2012
On 03/07/2012 07:19 PM, Amândio Antunes Gomes Silva wrote:
> 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 rechecked the log you had previously sent to the list, one question
about the log: did you cut it short or was the last Access-Challenge (id
204) really missing Message-Authenticator attribute?
Are you using the latest Radiator?
Thanks!
Heikki
> 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
>
--
Heikki Vatiainen <hvn at open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
More information about the radiator
mailing list