What happens if ACS can't communicate with Active Directory?

[jdean1]

If you were to have all network devices authenticate via tacacs to the ACS using windows AD accounts. What would happen if ACS could not reach AD for authentication, but the network devices could still access ACS? I cant seem to find this in the docs. I would think that since the router can talk to acs via tacacs, then you will not be able to log in and it wont go to the second AAA authentication type (local), since it can talk to ACS. That would be terrible, would it not?

Any help would be great. Thanks -j

[ahmed-bahgat]

Hi,

The function of ACS is to work as a proxy to the active directory. if acs cannot contact active diretory then authentication for users will fail.

[jdean1]

Thanks. I am still trying to define what "fail" actually means.

When a router administrator tries to login to the router that uses AAA/Tacacs for authentication that points to the ACS server, which points to AD for user credentials and everything is up except for AD, what exactly will happen:

1. The router administrator will get a username/password prompt from the router and it will just keep failing, because the ACS box can't get the auth from AD. Leaving ALL administrators locked out of all thier hardware.

or

2. Will the ACS server NOT respond with any auth info to the router causing the router to move to the NEXT configured AAA authentication type....i.e. local login, which would allow administrators to login to the device in the event of a AD problem.

I know aaa/tacacs can be very finiky and I dont want to have ALL network devices reliant on AD if it cannot handle AD service outages gracefully. Thanks a ton for any advice.

-j

[Vivek Santuka]

Hey,

Your number 1 option is the answer but it can be changed. The following are you options :-

1. On the device configure authentication/authorization method such that local is first option and tacacs is the second option. On IOS above 12.0 if the local method is first and the user does not exist in it then authentication failsover to tacacs. So if AD is down and ur ad user cannot login then use the local user

2. Keep 2 Remote Agents with Solution Engine for redundancy. With ACS for Windows, if the Primary DC is down the OS it self will try to contact the backups. So there is a redundancy there.

HTH.

Regards,

Vivek

[Richard Burts]

Justin

While I do not have experience with the exact scenario that you have, I have experience that is similar and may be helpful. I have configured routers to authenticate with tacacs which then went to an RSA server for authentication with one time passwords. So it is similar in that we go to tacacs which then goes to some other external mechanism for authentication. We have had several experiences where tacacs could not get to RSA for one reason or another. The normal behavior for tacacs in that situation is to return an response of "error" rather than a response of "failure". The error response does allow the router to then go to its backup authentication method.

So I believe that you will be ok to go ahead with authentication via tacacs.

HTH

Rick

[ktokashhh]

Awesome, this is the exact question I came here to look up and it's right on top. I'm dorking with the same scenario. We have 2 appliances with 2 agents installed on AD domain controllers. I've tested logging in with all the failure scenarios - backup appliance, backup agent, no appliance, no agent, yadda yadda.

I successfully fail back to enable if both appliances are offline, but if 1+ appliance is up, but both agents are inaccessible, I get the following:

me@jumpoff01:~$ ssh 10.40.0.125

me@10.40.0.125's password:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

WARNING: UNAUTHORIZED PERSONS ........ DO NOT PROCEED

This computer system is designated for PRIVATE use only and may be

...

% Authorization failed.

Connection to 10.40.0.125 closed.

To get around this I am trying to tinker with the authorization settings. My default (on a 2960) configuration is:

aaa new-model

tacacs-server host x.x.x.x

tacacs-server host x.x.x.y

tacacs-server key

aaa authentication enable default tacacs+ enable

aaa authentication login default tacacs+ enable

aaa authentication login privilege-mode group tacacs+ enable

aaa authorization commands 15 default tacacs+ none

aaa authorization exec default tacacs+ none

aaa accounting commands 1 default start-stop group tacacs+

aaa accounting commands 15 default start-stop tacacs+

I've tried taking out:

aaa authorization exec default tacacs+ none

aaa authentication enable default tacacs+ enable

aaa authorization commands 15 default tacacs+ none

on the switches that house each of appliances, and that allowed me to lower security somewhat but gain disaster recovery capabilities. HOWEVER, when I re-started the agents on the DCs I still ended up using the enable password, so I effectively disabled Tacacs+ on this switch. Um, yeah, not quite what I was shooting for. I'll keep tinkering and see what I can come up with.

[ktokashhh]

Ok I found the secret sauce. On the switches that house the Tacacs+ appliances I do:

aaa new-model

aaa authentication login default group tacacs+ enable

aaa authentication login privilege-mode group tacacs+ enable

aaa authentication enable default enable

aaa accounting commands 0 default start-stop group tacacs+

aaa accounting commands 1 default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

This allows me to authenticate to Tacacs+ until the agents and/or appliances aren't available (I tested both). So why not use this across all switches?

Well, this config sacrifices three things:

- I can't stop people from gaining privilege level 15 if they know the enable password. Normally I can (and do!) restrict this via Tac, and only if they DoS the appliances could they work around this.

- Command authorization is conspicuously absent. Yeah, necessary evil, but I can still see who gets enable since the Tacacs appliance logs all commands (assuming the Domain Controllers failed and not the appliances themselves). After that I they can disable logging, but it's something at least.

- I have to log in, then use enable to get to privilege level 15, whereas normally Tac drops me to 15 automagically.

So I'm going with this on the switches with the appliances so in case of emergency we can shut down the appliance interfaces and use enable everywhere. Just have to remember to describe the interface now ....

[jdean1]

Thanks all for the help..this is great. So if I understand everyone correctly we are saying that:

If ACS is NOT able to talk to AD for some reason (not available, network issue, etc) then the tacacs clients (Cisco Routers/Switches) will NOT allow you to login. Period. Since the ACS server is available, then the routers will not fail to the next configured AAA authentication method, correct?

If I am correct in the above statement, then is it possible to have the ACS setup to first query the AD database, but if unavailable query its own local internal database. That would be ideal for me. Is that possible? If so, how?

Thanks all,

-j

[Richard Burts]

Justin

What you state is not at all what I have observed. While not exactly the same situation my experience I believe is close enough to your to be useful. What I have observed is that the router sends an authentication request to ACS and if ACS is not able to communicate with the external authentication then ACS returns "error" to the router which allows the router to do local authentication.

HTH

Rick

[darpotter]

The original design of ACS is that an error during authentication should

for T+ return "error" rather than "failure"

for RADIUS.. not return anything

Both designed to allow the device to failover to another AAA server.

If you observe anything else.. its a bug and should be fixed.

Darran