(RADIATOR) authorizing dialup+wifi against single user database

[Hugh Irvine]

Hello Dave -

Thanks for the clarification.

Yes all of the alternatives you show below will work - it is simply a  
question of which "style" you prefer.

Keep in mind that the Radius protocol deals with individual pieces of  
NAS equipment and that any reply items are meant for that piece of  
NAS equipment. Different pieces of NAS equipment have no notion of  
what services may or may not be offered by other pieces of NAS  
equipment. The Service-Type as reported by the NAS equipment in an  
access request is an indication of what service the user is requesting.

You can use check items for your users, but if you have different  
conditions for the same users it gets quite messy and complicated.

I generally find it is simpler to understand and deal with using  
Client-Identifiers to group the NAS equipment into "service"  
categories and then have different Handlers for each "service". This  
makes the configuration file quite straightforward and keeps the user  
authentication fairly simple.

Of course different requirements will involve different approaches.

regards

Hugh


On 25 Jan 2007, at 09:39, Dave Kitabjian wrote:

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



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.