We've played around with the account lockout policy but it did not turn out to be a great idea. We have one account that's being used by 100+ computers and every now and then it gets locked. We weren't able to find out yet why it's being blocked or who's causing it but it happens every 30-90 minutes. This causes our render farm (computer farm) to lose access to the server.

We've changed the values affecting account lockout on the 'default domain policy' about 24h+ ago but it still seems to be active.

Any idea how I can permanently disable it?

  • Unless you have a good reason to disable account lockouts domain-wide, you might want to consider disabling it only for the OU that contains the service account that you mentioned. As for the problem of who or what is causing it, using something like Splunk to index your domain controller security logs might help if you're having trouble browsing/filtering them due to event volume. Look for Event ID 4740 and the preceding 4625 events. See also: Account Locked Out Troubleshooting – Skyhawk Apr 21 '12 at 5:55
  • @MilesErickson Setting fine-grained password policies at the OU level kinda sucks though. I'd stay away from it until and unless you can do it without ADSI edit in the future. – Wesley Apr 21 '12 at 6:00
  • @WesleyDavid I'd use PowerShell. But, I clearly don't mess with FGPP very often, because I didn't remember that they're applied to users/groups and not OUs. – Skyhawk Apr 21 '12 at 6:11

You can disable account lockout policy by changing the "Account Lockout Threshhold" option to 0. However, if it's not working... it's not working, so that won't help you.

First, check your Group Policy Refresh Interval for both computers and users. They are in Computer Configuration\Administrative Templates\System\Group Policy and User Configuration\Administrative Templates\System\Group Policy. The default is 90 minutes. Perhaps it's set for some absurdly high value.

Next, run gpupdate /force at an elevated command prompt on some of the PCs in your domain and see if the policy is applied to them.

Then, test other policies in the Default Domain Policy to make sure that they're being applied and that it's not a larger issue with Active Directory replication and application. If that's the case, you are well and truly hosed. =)

Finally, look into enabling debug logging for the Net Logon service. Once that's turned on, sift through the logs for bad password events. You should be able to see which computer is generating the event and track down the errant login process from there.

  • Hey Wesley David. Setting it to 0 seems to have fixed it. I'll keep watching it this weekend. – Felix Apr 21 '12 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.