[tac_plus] Per Device Command Authorization

[Ben Wiechman]

> 
> The problem is that the list of commands allowed for a user (or group)
> is
> applied universally. What you and I want is to be able to create groups
> of
> *devices* and then tie that to the allow/deny command list for the
> user. 

Exactly.

This
> will instantly explode the length and complexity of your config
> 
> > I don't see any way to do this with the stock configuration, but I
> may be
> > missing something.
> >
> > It looks like it might be possible with the multiple groups patch
> here
> > (http://bakacsin.ki.iif.hu/~kissg/pd/tac_plus/), but I'm not entirely
> clear
> > on that either.
> 
> I doubt that will work out well. The idea of multiple groups will work
> if each
> group has a config that does not conflict in any way with any other
> group,
> i.e. no two groups attempt to configure the same directive. Then the
> total
> config for a user is the union of all the groups. In real life, what
> you get
> is conflicts, and lots of them. How do you resolve that? Mathematics
> tells us
> it must involve some arbitrary priority process, and that is very hard
> to
> define. If you know C++ it's exactly the same thing as multiple
> inheritance
> and you know how insane that can get.

heh

 There's more info on this in the
> list
> archives accessible through the web front-end - the question comes up a
> lot.

That was more or less the conclusion I was reaching. I saw at one point as
well that Gabor had posted a comment about possibly adding some kind of
conditional group membership enhancements that would probably work as well.
However it does not appear that anything like that ever materialized. 

> 
> The workaround is to use separate tacacs servers for each class of
> device you
> have, and configure each one separately with the access you want for
> each
> user/group on those devices. Configure your devices to use the
> appropriate
> server and port.
> 
> You can run multiple tac_plus daemons on one host using different ports
> and
> devices can be configured as to the port to use. So there's no need to
> arrange
> for more machines to do this.
> 
> 

I hadn't arrived at that, but that would be another choice. It sounds about
as exciting as maintaining separate user names for different devices/device
groups and providing different access based on the unique usernames. I just
wanted to make sure I wasn't missing anything. Neither of the two solutions
is entirely palatable, but your suggestion has the benefit of being
transparent to the end user, if a bit more troublesome to maintain and
configure. 


Thanks.

Ben