Right... seems I've turned all the knobs and flipped all the switches I can for right now. I was just trying to squeeze as much fault-tolerance into it as humanly possible using what I have.
I think if I lose the backend DB (since it's AD) sources, and cannot access the ACS server, I've probably got a much larger issue on my hands anyway. Any more redundancy than what I have now is likely to require a separate appliance at another site of ours + DB servers at that site as well. Fortunately we're not doing any dial-up, etc. authentication so it's about as easy as it gets for this application. Network guys are a little more forgiving than users when things like this "don't work". :) Thanks for all the advice, folks. -Ryan On Mon, Mar 1, 2010 at 12:28 PM, Brian Turnbow <[email protected]> wrote: > > > > > >-----Original Message----- > >From: [email protected] [mailto: > [email protected]] On Behalf Of Ryan Lambert > >Sent: lunedì 1 marzo 2010 17.48 > >To: Saxon Jones > Cc: [email protected] > >Subject: Re: [c-nsp] SecureACS Appliance & AD Authentication > > >yeah, sorry, I might not have been as specific as I needed to be with > that. > > >I do fail back to local auth when TACACS fails, but of course if the > backend > >DB I'm configured for in the appliance fails, TACACS is still considered > >"up", so it will never revert to local auth unless I physically unplug the > >ACS appliance or stop services. That's what I was trying to avoid, but I > >didn't see any neat ways of doing it. > > Don't use ACS but I beleive the ACS solution involves two ACS servers and > database replication for this type of availabitlity. > With Radiator (and others) this is easily configurable, if the "first > source" fails you can ask a "second" and they can be db flat file etc. > > Brian > > > >On Mon, Mar 1, 2010 at 11:05 AM, Saxon Jones <[email protected]> > wrote: > > > 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/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
