ACS 5.3 and Windows AD account lockout

[Andy Johnson]

Currently on 5.3.0.40.2 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.

Thanks.

[scrye]

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

https://supportforums.cisco.com/message/3462703#3462703

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

Anterov

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.

Steve

[Tarik Admani]

Steve,

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*

[scrye]

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.

[hoyleanderson]

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

[hoyleanderson]

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