>-----Original Message-----
>From: cisco-nsp-boun...@puck.nether.net
>[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ryan Lambert
>Sent: lunedì 1 marzo 2010 17.48
>To: Saxon Jones
Cc: cisco-nsp@puck.nether.net
>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 <saxon.jo...@gmail.com> 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: saxon.jo...@gmail.com
> Telephone: (780) 669-0899
> Toll-free: (866) 701-8022 x2
> United Kingdom: 0(1315)168664
>
>
>
> On 1 March 2010 08:17, Ryan Lambert <thirdfrl....@gmail.com> 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 cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
