ACS 3.2 failing when rdbms not available.

[wes]

Has anyone experienced a problem logging into equipment that auths to ACS 3.2 if their ACS (ODBC) logging connection is down?

I haven't verified this bug yet but we took down our ODBC logging computer(postgresql), it was being moved to another building. All weekend long the computer was down and I couldn't log into any of my ACS controlled devices (Switches, AS5200). As soon as the computer was brought back online logins began to work again.

I didn't see this listed in the notes, but I may have missed it. Anyway I'm checking if anyone else has seen this behavior and wondering how to fix this problem (at least it was a nasty suprise, luckly I hadn't started wireless auth to the ACS unit)

Thanks

wes

[gfullage · Accepted solution]

This is expected, although probably not documented anywhere.

At the current time ACS works as follows :

When ODBC logging is configured, ACS blocks the authentication till the

ODBC logging is done or failed due to timeout. The ODBC timeout failure

occurs when the external database is unreachable. In this case, the

authentication will fail if this timeout is longer than the

device's timeout.

Workaround for enabling authentication despite of the logging failure is to increase the tacacs-server timeout on the device/NAS (for example

from 5 to 10 seconds). It can be done by using the next CLI command:

"tacacs-server timeout 10". You may need to increase this even more depending on how long the timeout is on your ODBC database.

There's an enhancement request in to have the ACS behaviour changed, you can see it here (http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCeb21974&Submit=Search). Because it's considered an enhancement request, don't hold your breath waiting for it, play around with the timeouts so that you don't get hit by it again.