_consAllow Orion NPM to query local Tacacs server for Username and password authentication. This will allow network administrators the ability to use their network support credentials to access Orion rather than maintaining a seperate local account.
+1
+ 20, if that will help
So, I sort of agree and sort of don't. Orion can be configured to use AD, you just point it to an AD group for network admins (or in my case 3 grps, associates, admins, and engineers). Then you can build individual views for each group or give them all the same views. And your TACACS server should also be using AD for authentication. So, why not just use AD? I only use Orion individual accounts for special uses (like Admin).
They'd be better off adding support for RADIUS. It will still allow the use of TACACS, but will also be supported by other similar systems.
TACACS and centralized AD
Agree with cunhalg above. We are responsible for a large Cisco network environment that uses TACACS authentication and passes the auth requests to AD. We are in an environment where changes to user accounts within AD do not get processed quickly enough by other departments and so we would be in a better position to control over the user's access to the SolarWinds system by denying access within the Cisco ACS.
Wonder how this would work in the event that TACACS is not available for whatever reason...
lets say TACACS Servers "melt" or just go off line for any reason... OR a network event in which tacacs is unreachable..
would this integration with tacacs render the ability to log into Solarwinds null, since SW wont be able to communicate with tacacs ?
