Fallback option if ACS server is down

[cdrobey]

Does anyone know the proper config to use for fallback, if the ACS server is unresponsive?

Here's a copy of my AAA config:

aaa new-model

tacacs-server host ******

tacacs-server key *******

aaa authentication login default group tacacs+ enable

aaa authorization config-commands

aaa authorization exec default group tacacs+ if-authenticated

aaa authorization commands 1 default group tacacs+ if-authenticated

aaa authorization commands 15 default group tacacs+ if-authenticated

aaa accounting exec default start-stop group tacacs+

aaa accounting commands 0 default stop-only group tacacs+

aaa accounting commands 1 default stop-only group tacacs+

aaa accounting commands 15 default stop-only group tacacs+

Thanks

[Richard Burts]

I typically configure routers with:

aaa authentication login default group tacacs+ line

what this does is to use tacacs as the primary source of authentication. If the router attempts to contact the tacacs server and gets no response it will then use the line (either console or vty depending on where the user is attempting access) as a backup.

I find that this works quite well.

[cdrobey]

Thanks. It worked great

[tepatel]

You can enter a "local" keyword at the end of commad to fallback everything to local database which is in the router.

So command will look like

aaa authentication login default group tacacs+ local

aaa authorization exec default group tacacs+ if-authenticated local

[chrisallen]

Does the if-authenticated option = yes when the user had to login via the local database??

[Richard Burts]

While I have not tested this specifically and my answer is therefore not authoritative, my understanding of the functionality and my experience with it would indicate that "if-authenticated" checks only that the user has previously successfully authenticated. I believe that it does not know or care which authentication path was used.

HTH

Rick

[robertcrabbe]

I would do this:

aaa authentication login default group tacacs+ line

aaa authentication enable default group tacacs+ enable

aaa authorization exec default group tacacs+ if-authenticated

**However, if AAA is down and no line or enable passwords/secrets are configured, you will not be able to get in.

To address this, you can:

aaa authentication login default group tacacs+ line none

aaa authentication enable default group tacacs+ enable none

aaa authorization exec default group tacacs+ if-authenticated none

...or this:

aaa authentication login default group tacacs+ line local

aaa authentication enable default group tacacs+ enable local

aaa authorization exec default group tacacs+ if-authenticated local

...or whatever combination of fallback authentication that suits your needs.

**If you put local, then you must have a local username and password configured for priv level 15.

My feeling is, if all your AAA servers are down, you don't have a line or enable password, and no local user configured, then at this point someone logging into your router or switch without a password isn't your primary concern. If my network is down, I want some way to get into my router to fix the problem or maintenance that I was doing without having to go through password recovery or restoring communication between the router and the ACS.

As always, you should test different scenarios for various platforms and versions on both *console* and telnet for fallback authentication before settling on a final config and deploying it.

[s.uslay]

I would not agree with this comment, your AAA server might be down but your network still could be up, allowing anyone to logon to any router/switch without authentication. You still need last line line of defence in the router/switch if in case someone intentionally brings down your AAA server as a first stage of attack.

Serhat

[robertcrabbe]

If you read my post very carefully, then you'll see that I recommend using a fallback option, or several fallback options.

I would also recommend using multiple AAA servers in case one should go down.

I would also recommend using access-class or ip permit statements on all my routers and switches.

I would also recommend controlling who can get to your routers and switches, not to mention, AAA server, by using out-of-band management or carefully placed access lists and/or firewalls.

I would recommend using ssh wherever and whenever possible on your routers/switches that have code that supports SSH.

So, you're point is well taken. I was only trying to hammer home the point that you shouldn't forget these few lines of configuration.

However, I will say that the last thing you want happening at 2am when you are doing a network upgrade or redesign is to not be able to telnet/ssh/console into your router or switch.

So, my point is, if you configure tacacs, then line or enable as your first fallback, then local as your second fallback, then none as your third, if you forget to configure the passwords for your first and second fallback options, then were you really concerned about securing that router in the first place, or is it something that you were using in a lab enviroment for testing?

The bottom line is, don't forget to configure all the parameters for fallback, and test before you deploy.

[s.uslay]

Now,I agree all the things that you said. I just did not want people getting the missed information.

The best is multiple AAAs combined with out-of-band SSH access to console server and keep emergency local passwords.

Serhat