I've long since deleted the OP's message, but figured I would share our experiences having been using TACACS+ with our Cisco hardware for a couple of years.
Originally deployed for the need and want of controlling multiple users across several devices, and to safely control 3rd party read, or reverse-telnet access to the very few nodes that may need it, without needing to mess around with parser views on every device.
To that end it's worked just fine without complaint.
Note: We're using shrubbery.net's tac_plus.
The per-command authorization does slow some nodes down slightly, but nothing as severe as a few seconds each It does work out to about 1 command per (1000ms / Node to AAA RTT) as you'd expect. Eg; The worst I've seen on a ~200ms link, copy/paste lump-of-config will work out to about the expected 4-5 commands/second. Devices running v15 seem to speed this up somehow, not sure if they multiplex commands under the hood, or if I'm just crazy. I've never looked into it that closely for lack of interest and time.
There is a stupid gotcha when dealing with the command authorization in the TACACS configuration. If you permit 'johndoe' a 'show ip bgp .*', and he is also a member of a group with subsequent show commands, the show commands in the 'group' config block are completely ignored. This makes some scenarios tricky.
We utilize a local root, unprivileged user with unique credentials across each device. It's possible to configure Cisco's AAA to prevent the local user login while AAA is up / reachable.
Generally, we are of the opinion that if our nodes cannot reach the AAA server, we have bigger problems that would necessitate a senior administrator with access to the local root user credentials anyway.
Otherwise, a TACACS server can be setup in literally minutes and the configuration required is minuscule and easy to backup safely.
A note on the local root user. By far and away, the worst possible scenario is not AAA going down / becoming entirely unreachable, but instead when experiencing network instability. Having experienced this scenario for a few very frustrating hours, the experience is along the lines of;
- Enter a pile of commands. Some fail (wile AAA is briefly up), some succeed (while AAA is down).
- Swear at your console, and repeat until the problem(s) are resolved.
Our workaround was;
Add your backup / root user with full privileges to your TACACS backend, with _no_ password. This denies them access when AAA is running as there is no password to authenticate against, but prevents "Authorization failed!" when the AAA server is briefly available in the middle of your diags / trying to resolve the connectivity problem.
For the Unix admins; The TACACS binary itself, is awful - It has no status exit codes. The process cannot be monitored or controlled safely by way of something like DJB's daemontools, even with the fg_helper hack - at least I've not managed to succeed to date and have given up. To that end, we have a hacked together script to assist with safely reloading configs and such that parses stdout and stderr to decide what to do. Eg; trying to gracefully restart TACACS with a broken config will cause the daemon to exit - not awesome.
All that said, I have heard a lot of praise from an enterprise in my neck of the woods who shelled out for Cisco's TACACS+ VM Appliance. If you have the money it's supposedly worth it especially for the AD hooks.
I hope this provides some insight to those that may need it.