Something like: aaa authentication login default group tacacs+ *enable* aaa authentication enable default group tacacs+ *enable*
And set your enable secret; if TACACS+ is unavailable then you can login with whatever username you like but using the enable secret as your password and enable password. As long as your TACACS+ server is reachable you can't use the enable secret for auth so if just your AD connector fails then disconnect the TACACS+ server and you can then login with that secret. -saxon ______________________________ Saxon Jones Email: [email protected] Telephone: (780) 669-0899 Toll-free: (866) 701-8022 x2 United Kingdom: 0(1315)168664 On 1 March 2010 08:17, Ryan Lambert <[email protected]> wrote: > We've only got a handful of folks accessing certain devices, and the > permissions are relatively static. Nothing fancy going on here. > > After some tinkering I've been able to get them talking with ACS. The only > issue I'm running up against is that if the external DB fails out, I'm > unable to authenticate with no local rollback. I guess part of this is > because my unknown user policy is to fail the attempt (security reasons > obv.). > > Unless anyone has any creative ideas, I guess I'll just need to rely on > primary & secondary DBs. Alternatively I suppose if it's a dire emergency I > can log in via ACS Admin and reconfigure the username for local... although > that's not really ideal for our environment. > > TIA, > Ryan > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
