(RADIATOR) authorizing dialup+wifi against single user database

[Dave Kitabjian]

Thanks for the reply...

Regarding WiFi processing logic, I should have clarified that we're
talking about using Chillispot's UAM approach. So it's not EAP at all. 

As far as Client Identifiers, I thought they needed to be unique; that's
an interesting option. But if we're not letting the NAS do the denial
via Service-Type (or something like that, as per the RFC), is the
Client-Identifier approach any better than simply:

<Handler NAS-Port-Type = Async>
	...
</Handler>

<Handler NAS-Port-Type = Wireless-802.11>
	...
</Handler>

But even then, isn't adding Check Items such as:

	NAS-Port-Type = Async|Wireless-802.11

into the user database even simpler?

But I really thought the whole "Authorization" piece of RADIUS' AAA
would have provided a Reply-Item based solution...

Dave


> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Wednesday, January 24, 2007 4:21 PM
> To: Dave Kitabjian
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) authorizing dialup+wifi against single user
> database
> 
> 
> 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.