[RADIATOR] How to configure Radiator to Support both PEAP/MSCHAPv2 and TTLS/PAP?
Amândio Antunes Gomes Silva
amandio at scom.uminho.pt
Tue Oct 21 11:50:33 CDT 2008
[a message similar to this one has been sent with the attachments solicited, but once the list server quarantined it, I decided to resend this version of it]
Hi Hugh!
Attached you can find the radius.cfg file (with no secrets nor passwords) and the entire log of an attempt to do an PEAP/MSCHAPV2 authentication. You can find, also, the log from the IAS server for this attempt, where, as you can see, the access was granted. This attempt was made using an Mac OS 10.5.4, using Internet Connect (this utility is a far better supplicant than the new method implemented in MacOS X 10.5).
In the radius.cfg file you can see where we had to put the NoEAP directive in order to Radiator function properly.
Best regards,
Amândio Silva (SCOM - UMinho)
-----Mensagem original-----
De: Hugh Irvine [mailto:hugh at open.com.au]
Enviada: terça-feira, 14 de Outubro de 2008 00:09
Para: Amândio Antunes Gomes Silva
Cc: radiator at open.com.au
Assunto: Re: [RADIATOR] How to configure Radiator to Support both PEAP/MSCHAPv2 and TTLS/PAP?
Hello Amandio -
Could you please send me a copy of the full configuration file you
are testing, together with the corresponding trace 4 debug?
I couldn't tell from the debug you sent previously what was
happening, as it looked to me like the commented lines were confusing
the Radiator parser.
There was a change in Radiator 4.3.1 to allow finer grained control
of combinations of EAP/non-EAP AuthBy clauses.
Can you show me exactly what used to work and what now does not work?
regards
Hugh
On 13 Oct 2008, at 22:19, Amândio Antunes Gomes Silva wrote:
> Hi Hugh,
>
> As you suggested, I removed all comments from config file, and
> configured the Radiator as you wrote in your message, but the
> results are still the same. The reason why I have so many comments
> is that I can quickly change from a config to another - I know
> that's easy to let some comments uncommented, and vice-versa, which
> can cause the problem, but I may say that I'm very used to this
> kind of operation and I don't think the problem resides here. Have
> you further analyzed the logs I sent in the original message? What
> conclusions have you reached?
>
> Another issue with the Radiator version we are running now (4.3.1)
> is that in order to EAP authentication (TTLS/PAP) we had to put
> 'NoEAP' in the auth clauses, otherwise the authentication fails
> with the message 'EAP authentication is not permitted.'. Any
> special reason why this happens?
>
> Thank you in advance,
>
> Amândio Silva (University of Minho, Braga, Portugal)
>
> -----Mensagem original-----
> De: Hugh Irvine [mailto:hugh at open.com.au]
> Enviada: quinta-feira, 9 de Outubro de 2008 03:54
> Para: Amândio Antunes Gomes Silva
> Cc: radiator at open.com.au
> Assunto: Re: [RADIATOR] How to configure Radiator to Support both
> PEAP/MSCHAPv2 and TTLS/PAP?
>
>
> Hello Amandio -
>
> It looks to me like at least part of your problem is due to typos in
> your configuration file, as you have commented out lines that
> shouldn't be.
>
> It is much easier to see what is going on without lots of commented
> lines:
>
> .....
>
> <AuthBy RADIUS>
> Host 192.168.62.100
> Secret **********
> AuthPort 1812
> AcctPort 1813
> EAPType PEAP,TTLS,TLS,MSCHAPV2,MSCHAP-V2,
> Description PEAP no SAPIA
> Identifier PEAPnoSAPIA
> Retries 5
> RetryTimeout 30
> AddToReply Tunnel-Type=VLAN, Tunnel-Medium-Type=Ether_802,
> Tunnel-Private-Group-ID=247, Class=funcionarios
> </AuthBy>
>
> <Handler ConvertedFromEAPMSCHAPV2=1>
>
> AuthLog peaplog
> StripFromRequest ConvertedFromEAPMSCHAPV2
>
> AuthBy PEAPnoSAPIA
>
> </Handler>
>
> <Handler TunnelledByPEAP=1>
>
> RewriteUsername s/^([^@]+).*/$1/
>
> <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>
>
> </Handler>
>
>
> hope that helps
>
> regards
>
> Hugh
>
>
> On 7 Oct 2008, at 22:28, Amândio Antunes Gomes Silva wrote:
>
>> Hi all!
>>
>>
>>
>> I've been trying to configure Radiator to both authenticate clients
>> with TTLS/PAP (which works fine for several years) and PEAP/
>> MSCHAPV2). The scenario we have here at University of Minho
>> (Portugal) is as follows:
>>
>>
>>
>> Server: Radiator 4.3.1 running on Linux (CentOS 5.2)
>>
>> TTLS Authentication (PAP) is done against an LDAP server (in fact,
>> it's an LDAP gateway to an ActiveDirectory).
>>
>> PEAP Authentication is configured to be proxied to an IAS server.
>>
>> All our AP's are configured to authenticate against this Radiator
>> server, but, for testing, I'm using an AP that authenticates
>> directly to an IAS server, which accesses directly the same Active
>> Directory that is used by the LDAP gateway.
>>
>> University of Minho is part of the eduroam project, which means
>> that it belongs to an hierarchy of RADIUS servers that is working
>> fine.
>>
>>
>>
>> The tests were made with a PC with Fedora Core 7, using
>> wpa_supplicant (this way I have absolute control on which AP the
>> PC associates to).
>>
>>
>>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/
> radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> Includes support for reliable RADIUS transport (RadSec),
> and DIAMETER translation agent.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
More information about the radiator
mailing list