ACS 5.3 and Windows AD account lockout

Question

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.

Answer 1

Hi;
Well, we got it working. Not sure of the exact fix, but allow me to ramble, perhaps it will help someone else.
We think that a combinationof factors caused the problem. First, we had clock drift, and that resulted in clock skew messages in the logs like these:
Sep 20 18:06:03 ecb-acs1 adclient[8322]: INFO  base.adagent start: Problem connecting to domain controller (KDC refused skey: Clock skew too great), will try again later.
and
ecb-acs1 adclient[1163]: WARN  base.bind.cache LDAP fetch CN=bubba,OU=staff,OU=edcenter,OU=edcenterarea,OU=episd,DC=episd,DC=org threw unexpected exception: SASL bind to ldap/[email protected] - GSSAPI Mechanism with Kerberos error ": Clock skew too great"
Somehow the ACS lost the ntp config, very disturbing, because I know that one of the first things I did was setup NTP. So I re-did the ntp config, confirmed the time was accurate. Still failed. Then, because I was annoyed by the log entries comning out in UTC, I did a clock timezone to set it to local. That made the logs come out in local time, but might have caused other problems (I saw another forum entry for that) so I set it back to UTC.
This begs the question - how to leave the timezone at UTC but fix the timestamps for the logs? This is easy on Cisco switches.
Various reboots of the ACS after deleting the object in AD did not fix the problem. During these reboots I continued to use the original userid and password to authenticate. At all times, the "test connection" button showed that the credentials were OK.
Because we had recently added our first Win2008 domain controller to our world (all ther other DCs are Win2k3), we started worrying about this:
http://support.microsoft.com/kb/978055/en-us
But, after some checking, it seems as if we already had the fix applied.
Next, we created a dedicated user in AD for the ACS to use when authenticating. Deleted the ACS object, restarted the ACS, applied those new credentials. Still broken.
Our AD admin looked in various logs and found some things, here is his summary:
----------- from Danny --------
Checked the domain controller log under system.  Found the following:
While processing an AS request for target service krbtgt, the account ecb-acs1$ did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). 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.
and
While processing an AS request for target service krbtgt, the account stcrye did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 2). The requested etypes : 18. The accounts available etypes : 23  -133  -128  3  1. Changing or resetting the password of stcrye will generate a proper key.
This may be related to either clock scew between acs and the domain or introducing server 2008 domain controllers into an existing server 2003 domain. 
On a desperate hunch, after yet again deleting the ACS object in AD and reloading the ACS, I used the new dedicated ACS user account, but gave it a wrong password. Hit save, watched it fail. Then I put in the correct password, hit save, and it worked! Finall we have re-joined and are connected to the domain.
BUT ... I have now lost all confidence in ACS 5.3 . We are in the middle of a major rollout of WiFi clients using 802.1x authentitcation, replacing our previous pre-shared WPA setup. We are talking > 20,000 WiFi clients. If ACS <--> AD is not rock-solid, I need to try something else. Should we consider using LDAPS instead?
Steve