(RADIATOR) authorizing dialup+wifi against single user database

Hugh Irvine hugh at open.com.au
Wed Jan 24 15:21:00 CST 2007


Hello Dave -

The usual way I do this is with Identifiers in the Client clauses and  
corresponding Handlers:


# define Client clauses with Identifiers

<Client 1.1.1.1>
	Identfier Dialup
	.....
</Client>

<Client 2.2.2.2>
	Identifier Dialup
	......
</Client>

......

<Client n.n.n.n>
	Identfier Wifi
	......
</Client>

<Client m.m.m.m>
	Identfier Wifi
	.....
</Client>

.....

<Handler Client-Identifier = Dialup>
	......
</Handler>

<Handler Client-Identifier = Wifi>
	......
</Handler>

......

The RADIUS processing for Wifi (802.1x) is significantly different to  
simple Dialup.

See the example configuration files in "goodies/eap_*.cfg".

regards

Hugh


On 25 Jan 2007, at 05:34, Dave Kitabjian wrote:

> Hello folks,
>
>
> We have a large dialup user base already managed via Radiator and  
> now we are preparing to implement wifi hotspot access. Naturally,  
> we would like to offer wifi access to selective, existing dialup  
> users, and vice versa. Although we haven’t played with this type of  
> functionality much, my understanding of RADIUS was that we would be  
> easily able to manage what types of access are authorized to which  
> users. But I can’t figure out how?
>
> I thought Service-Type might be the place to look since the RFC  
> says that the NAS “MUST treat unknown or unsupported Service-Types  
> as though an Access-Reject had been received instead”, but the RFC  
> says only one may be sent back to the NAS, making me uncertain how  
> to give a single user access to both dialup and wifi.
>
> Can someone kindly enlighten me?
>
> Thanks!
>
> Dave
>
> p.s. btw, I realize that we might be able to achieve this with  
> Radiator’s “alternation” feature using a NAS-Port-Type Check Item,  
> but that will require some development on our part, whereas support  
> for arbitrary Reply Items is something we already have in place…
>



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.



--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list