[RADIATOR] Best Practice Question

[Hugh Irvine]

Hello Ryan -

As a general rule we discourage overlapping Client definitions.

I tend to prefer listing all client devices individually using either "include" files, or an SQL or LDAP database.

regards

Hugh


On 22 May 2010, at 06:40, Ryan Harden wrote:

> What is the best practice when a device might match two <Client> sections?
> 
> Example:
> Backbone Loopbacks: 172.20.19.0/24
> Edge Loopbacks: 172.20.21.0/24
> Device Blah: 172.20.19.114/32
> 
> I would like devices matching either /24 to run respective Handlers, but
> the specific device "blah" to run a completely separate Handler. I
> suppose I could do the following, but I'm not sure what the best
> practice would be.
> 
> <Client 172.20.19.114>
>        Secret xxxxxx
>        DupInterval 0
>        Identifier Blah
> </Client>
> <Client 172.20.19.0/24>
>        Secret xxxxxx
>        DupInterval 0
>        Identifier Backbone
> </Client>
> <Client 172.20.21.0/24>
>        Secret xxxxxx
>        DupInterval 0
>        Identifier Edge
> </Client>
> 
> I assume the specific device "Blah" would match the first Client section
> and skip over the next two. Am I correct in this assumption?
> 
> In the grand scheme of things I'm going to have several of these /32
> hosts that I'll need to call out specifically while letting the rest in
> the respective /24s fall to more 'default' handlers. The purpose is to
> apply different AuthZ rights to users based on what device they are
> accessing.
> 
> Thanks
> 
> /Ryan
> -- 
> Ryan M. Harden, BS, KC9IHX		Office: 217-265-5192
> CITES - Network Engineering		Cell:  	217-689-1363
> 2130 Digital Computer Lab		Fax:    217-244-7089
> 1304 W. Springfield	 		email:  hardenrm at illinois.edu
> Urbana, IL  61801 			
> 
>      University of Illinois at Urbana/Champaign - AS38
> 	   University of Illinois - ICCN - AS40387
> 
> _______________________________________________
> 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.