Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
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
add comment

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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