[tac_plus] Per Device Command Authorization

[Alan McKinnon]

Apparently, though unproven, at 19:23 on Thursday 18 November 2010, Ben 
Wiechman did opine thusly:

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


Last I heard, Gabor ran into configuration conflicts, and John wanted to fix 
the config parser before looking further into it. It's not an easy problem to 
solve - I have a team of devs and mathematicians (real ones with Masters) who 
haven't come up with a good config resolver yet.

I use a modified version of multiple servers - each division has it's won 
Tacacs server(s) and all share the same authentication credentials. 
Authorization rules are done per-division. Sometimes I need different rules 
within a division like firewall people don't get access to core routers. I 
can't solve this, so I use the BOFH rule:

If I can't trust the firewall people to keep their paws off the core, then 
they get no access at all to anything. Thus far, no-one has done anything to 
endanger that trust relationship - they know their access depends on it.

Sometimes the best solution is not found in technology :-)

-- 
alan dot mckinnon at gmail dot com