[c-nsp] SecureACS Appliance & AD Authentication

[Ryan Lambert]

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.

On Mon, Mar 1, 2010 at 11:05 AM, Saxon Jones <saxon.jones at 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.jones at 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.nsp at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>