(RADIATOR) handling groups of TACACS+ clients

[Hugh Irvine]

Hello Andrew -

I think you will need to use a PreHandlerHook in the ServerTACACSPLUS  
clause to pull the Identifier out of the Client clause, and add it to  
the RADIUS request.

There is an OSC-Client-Identifier vendor specific defined for this  
sort of thing.

Then you can do this:


<Handler NAS-Identifier = TACACS, Service-Type = Administrative-User,  
OSC-Client-Identfier = Some-Tag>
	......


See the example hooks in "goodies/hooks.txt".

regards

Hugh


On 21 Feb 2008, at 08:07, Andrew D. Clark wrote:

> Is there any mechanism for conveniently grouping TACACS+ clients  
> with an
> identifier as there is for RADIUS clients?
>
> Unfortunately for this case, using RADIUS instead of TACACS+ isn't  
> an option.
>
> I have a large number of TACACS+ clients that need to be grouped  
> for different
> AAA behavior.  If they were RADIUS clients, I'd group them in a  
> <Client ....>
> clause and then give that group an Identifier, which I'd then match  
> on with a
> handler like
>
> <Handler Client-Identifier=blah>
> ...
> </Handler>
>
> For TACACS+ clients, it doesn't appear that an Identifier within a  
> TACACS+
> client clause does anything.  So I'm left with the rather unwieldly
>
> <Handler NAS-Identifier=TACACS, Service-Type=Administrative-User,
> NAS-IP-Address=/192.168.242.108|192.168.244.92|192.168.227.40| 
> 192.168.226.37|
> 192.168.243.83|192.168.237.154|192.168.238.90|192.168.238.81| 
> 192.168.228.60|
> 192.168.235.251|192.168.240.54|192.168.229.21|192.168.231.134| 
> 192.168.239.56|
> 192.168.225.28|192.168.233.108|192.168.224.20|192.168.241.20| 
> 192.168.251.250|
> 192.168.251.251|192.168.247.182|192.168.247.183/>
> ...
>
> The NAS-Identifier comes from my Server TACACSPLUS clause
>
> <ServerTACACSPLUS>
>         Key blah
>         AddToRequest NAS-Identifier=TACACS
>         GroupMemberAttr blahblah
>         # authorization configuration
>         Include %D/include/authorization.cfg
> </ServerTACACSPLUS>
>
> Hopefully I'm missing something obvious.
>
> -- 
> Andrew D. Clark, Network Operations Engineer 	
> University of Minnesota, Networking/Telecom Services 	
> 2218 University Ave SE
> Minneapolis, MN 55414-3029
> Phone: 612-626-4880
>
> --
> 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?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

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