Showing results for 
Search instead for 
Did you mean: 

ACS 5.3 and Windows AD account lockout

Andy Johnson

Currently on when a invalid password is attempted via TACACS or RADIUS to the AD identity store is locks the account out on the first failed attempt. The AD policy is lockout after three attempts. Is there a way to fix this issue so the account is not locked out with only one failed attempt? I see options for local password policys in ACS but nothing for the identity store. For what its worth this happened also with ACS 4.X deployment before we moved to ACS 5.3.

Just wanted to see if this is the expected behavior or if I should open a TAC case to see what is causing this.


19 Replies 19

Travis, I've been afraid to set the TZ back local, mostly because of the post by Anterov    in this thread:

Oct 10, 2011 5:25 PM                             (in response to Vincent Fortrat)

Re: ACS Appliance "ADClient"

Please check if clock and time zone are correct as the Domain controller, had the same problem and that was the issue.

hope this help


Our DCs use UTC, and the AD team is not going to set them to localtime. The

"service timestamps log datetime localtime "

used by IOS in Cisco switches does not modify the internal timezone, it just stamps the logs with localtime.



Did you add the ntp server after the initial installation script ran? Also did you issue a "wr me" in order to save the cli, it could be that this was added but the changes werent saved, and if the ACS ever rebooted then that could have left the config.

Let me know if this sounds like a symptom or not. Also since you are still testing please save the config and reboot the ACS and see if still connects.

Also with regards to the message:

The requested etypes : 17. The accounts available etypes : 23  -133   -128  3  1. Changing or resetting the password of ecb-acs1$ will  generate a proper key.

I have seen this error before and have seen that this could be ignored and that the kerberos ticket type fixes itself on the backend but doesnt get logged. In order to confirm this did you still see the same error prior to the ACS connecting successfully?

Tarik Admani
*Please rate helpful posts*

Hi Tarik;

Yeah, I do wr mem obsessivley. Who knows how it lost the ntp config ... might be one of those things we never figure out.

I don't have access to the AD logs, that is a different group of people. I'll try to check on Monday.

This timezone thing is really driving us CraZY. We have a new DateTime policy element called MWTThF-Daytime, that we want to use to restrict Students to login only during normal school hours. But, with the ACS using UTC, everything is shifted by 7 hours. I wasted about 1/2 hour before I realized the system was rejecting logins right now because it thought it was 10:00pm!

I'm afraid to set the ACS to use UTC-7 , because our AD system is on UTC. (BTW, all the AD log timestamps are off by 7 hours too grrr). The AD group does not want to change all the DCs to use local time.

Am I doomed? Is there any way to set the ACS to local time without breaking the ability to connect to the domain? Any help would be great.

Be sure your AD account password is not too complex.  In (at least) a password may pass the "test" and then fail to "Save".  There are special characters (suspecting ! at this point) that cause failure.


Be sure your AD account password is not too complex.  In (at least) a password may pass the "test" and then fail to "Save".  There are special characters (suspecting ! at this point) that cause failure.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: