[RADIATOR] eap + apple products - failed auth
Amândio Antunes Gomes Silva
amandio at scom.uminho.pt
Thu Mar 8 09:40:41 CST 2012
Hi, Heikki.
In fact, the Message-Authenticator attribute was in the last packet ( Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>) - that line was lost in the copy/paste process, sorry for that. See that last packet and Radiator version below.
If needed, I have packets captured both in the radius server and in the client side, as well as the radiator log for an attempt I made today.
This is Radiator 4.9 on roamer-b.scom.uminho.pt
Copyright Open System Consultants
http://www.open.com.au/radiator
The last packet (complete):
Thu Mar 1 15:13:01 2012: DEBUG: Access challenged for f1023 at scom.uminho.pt: EAP TTLS Inner authentication challenged
Thu Mar 1 15:13:01 2012: DEBUG: Packet dump:
*** Sending to 172.16.45.67 port 1645 ....
Code: Access-Challenge
Identifier: 204
Authentic: S<212><192><232> <142>#<185><215>-<226><186>$<236>Bq
Attributes:
EAP-Message = <1><9><1>o<21><128><0><0><1>e<23><3><1><1>`<215>&!x<29><188><169><205>'<190><137><196><166><233><244>\S<174><246>2<19><169><174><144>\A<240><1><159><135><214>5"<29><167><158>v<191><155>K<177><208><187><218><25><237><215><246><165><24
6><200><190>XC-z<186><135><165><162><167><232>.<255>z|<236>4<155>,<205>E<185><222><168><12><22><131>:Q<9><14><15>M<220>%<223>C<219>zG7n<203><134><153><233>S$<181><25><24><199><4><220>4<163>!<173><169><214>Nc<251><138>-<20><159><230><13>a<26>"<165>Ihp<194>
<237><158><228><241><239><151><22>i<253><145><150>9yz2\`<231><253>:<146><189><186>.'=k<179><184>_<163><135><255>sb<170><199><131><13>l[<17><150><162><4>p<159>c<146>y<230><253><209><28>-<181><22>8zneF<137>Z(B<167><209>O<16><0><178>tuV<3>T<13>O<176>I$<27><1
43>79<30>@<217>x@<132><182>g<194><255><151>p<232><243>U<233><169><162><168><248><236>=<3><247>
EAP-Message = '<241><193><201>'<249><232><177><242><239><142>;<181><205><178><207>L<154><240><211><189><158>t<25><249>y<240><218><192>F4<136><242>I<195><165><207>,<14><224>N:'<197><249>w<27>i<255>'<29>S<206><189><138>Sp<140><197><134>sD<193>\:<199
>mU<239>Q(<8><170>3LN<226><158><1>Jlz&J82<30><127>G7j<253><148>5u<135>S<213><178><237>lO<204><6>\<233>Yw"<218><218><198>B<155>
Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
Thanks,
Amândio
-----Mensagem original-----
De: Heikki Vatiainen [mailto:hvn at open.com.au]
Enviada: quarta-feira, 7 de Março de 2012 18:56
Para: Amândio Antunes Gomes Silva
Cc: radiator at open.com.au
Assunto: Re: [RADIATOR] eap + apple products - failed auth
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 <mailto:amandio at scom.uminho.pt> <sip:amandio at scom.uminho.pt <sip:amandio at scom.uminho.pt> >
>
> email: amandio at scom.uminho.pt <mailto:amandio at scom.uminho.pt> <mailto:amandio at scom.uminho.pt <mailto:amandio at scom.uminho.pt> > |
> http://www.scom.uminho.pt <http://www.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] <mailto:[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 <mailto: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 <mailto:amandio at scom.uminho.pt> <sip:amandio at scom.uminho.pt <sip:amandio at scom.uminho.pt> >
>
>>
>
>> email: amandio at scom.uminho.pt <mailto:amandio at scom.uminho.pt> <mailto:amandio at scom.uminho.pt <mailto:amandio at scom.uminho.pt> > |
>
>> http://www.scom.uminho.pt <http://www.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 <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20120308/1ad27480/attachment-0001.html
More information about the radiator
mailing list