[RADIATOR] PEAP(MSCHAPv2), AD and Radiator on Linux

[Amândio Antunes Gomes Silva]

Hi all!

I've implemented a Radiator configuration that supports both EAP/TTLS (that uses LDAP) and EAP/PEAP (MSCHAPv2), but de PEAP requests are forwarded to an MS IAS server which handles them. It has some limitations, once I'm not the AD administrator, so I can't do dynamic VLAN allocation based on users profile and things alike. By the way, I'm wondering if there's a post-processing hook the can do a LDAP query to the AD and retrieve that data (the LDAP that we're using is, in fact, a gateway to the same AD that IAS uses). If you are interested in more details, you can contact me directly (Hugh, this is an issue that we've discussed one and a half year ago - or 2, I don't remember - and I managed get it to work, although I didn't let you know.)

Best regards,

Cumprimentos,
Amândio Antunes Gomes da Silva
-----------------------------------------------------------------------------------------------------------------------------------
Serviço 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
email: amandio at 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: Hugh Irvine [mailto:hugh at open.com.au] 
Enviada: quarta-feira, 19 de Maio de 2010 22:41
Para: Caporossi, Stephen G.
Cc: radiator; Pascal Beauregard
Assunto: Re: [RADIATOR] PEAP(MSCHAPv2), AD and Radiator on Linux


Hello Steve, Hello Pascal -

Note that in both cases (indeed any direct interaction with an external resource) Radiator waits for the response.

The difference between NTLM and LDAP is that NTLM spawns an external process, while LDAP is an interprocess call using sockets.

You always need to be careful with any solution to make sure that the external process is fast enough to keep up with the number of RADIUS requests you have to process.

We have many customers using both NTLM and LDAP (sometimes both together) very successfully.

Your alternative to using NTLM is to run an instance of Radiator on Windows and use the AuthBy LSA clause (but thats a whole other issue).

regards

Hugh


On 20 May 2010, at 06:00, Caporossi, Stephen G. wrote:

> Pascal,
> 
> I stayed away from this option for a long time because of the same "Caution"...about a month ago we decided to give it a try and have had no issues...~2000 wireless clients at any given time..
> 
> Steve
> 
> On 5/19/10 3:51 PM, "Pascal Beauregard" <Pascal.Beauregard at USherbrooke.ca> wrote:
> 
>> Hi,
>>  
>> What are my options if we want to authenticate wireless users with PEAP (MSCHAPV2) against an AD and my Radiator is running on Linux ?
>>  
>> Am I forced to use AuthBy NTLM ? If it's the only option, there is a caution in the goodies/ntlm_eap_peap.cfg : Caution: AuthBy NTLM blocks while waiting for the result output of ntlm_auth. Can this affect the capacity of Radiator to handle high level of authentications ?
>>  
>> Is AuthBy LDAP2 will work with AD and PEAP and MSCHAPv2 ?
>>  
>>  
>> Pascal Beauregard
>> Analyste en télécommunications
>> Université de Sherbrooke
>> (819)821-7770
>> www.usherbrooke.ca <http://www.usherbrooke.ca> 
>> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



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?

-- 
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.