This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
We have a four-node ACS deployment and one node is experiencing problems when handling TACACS authentications.
ACS shows "24495 Active Directory Servers are not available"
The ACS log via SSH shows:
Feb 20 03:01:29 DRACS adclient: WARN <fd:29 CAPIAuthValidatePlainTextUser > audit User 'AHunt' not authenticated: AD was unavailable for Kerberos authentication, and validation against cached hash failed: No user hash in cache for [domain]\ahunt
We're running ACS 5.3 with patch 9
The two scenarios in http://www.cisco.com/c/en/us/support/docs/security/secure-access-control-system/113485-acs5x-tshoot.html#err24495 do not seem to be relevant in our case.
ACS shows it is joined to the domain and doing nslookup via SSH lists all the domain controllers. The other three nodes in the deployment don't have an issue and work correctly.
Any advice or suggestions appreciated.
Check the ACSADAgent.log file through the CLI of the ACS 5.x for messages such as:Mar 11 00:06:06 xlpacs01 adclient: INFO
(registered customers only) for more information.
Thanks for the post but this is not our issue. We don't see that output in the log. The output is:
Feb 25 02:46:02 DRACS adclient: WARN <25 capiauthvalidateplaintextuser=""> audit User 'AHunt' not authenticated: AD was unavailable for Kerberos authentication, and validation against cached hash failed: No user hash in cache for lw\ahunt25>
This seems awfully like our issue:
Any thoughts? Thanks!
Have you condigured NTP server in the ACS? It seems like there is synchronization problem between ntpd and the ntp server. Please try to reconfigure the NTP server ( if t is there) and test again.
Yes, NTP is fine. This is a four-node ACS deployment and everything was working fine until recently. However, the issue is actually now fixed.
I issued debug-adclient enable from which I was able to see that the ACS instance was connecting to a DC in Singapore (the ACS box is in California) which led me to assume that the subnet wasn't associated with the correct AD site. I added the subnet to AD Sites and Services, waited for replication, and then restarted ACS. It is now associated with the correct local DC and working correctly. I assume the problem was caused by high latency / timeouts.
Thanks for your help and suggestions.