How to troubleshoot account lockout issue

[Note] Event ID applicable to Windows 2003 DC only, but it shouldn't be too difficult to find related W2k8 event IDs.
[Edit Feb 14/2012] Full list of audit events in windows 2008 can be downloaded here, also KB947226
Please read the differences between "Account Logon/logoff" event and "Logon/Logoff" event first.

- First, using lockoutstatus to find out initial authenticating DC (more than often PDC is not the initial authenticating DC. It has same event IDs mentioned below merely because other DCs check with PDC for latest password.) and time of logon attempt

- Then go to authenticating DC, check security log. Pin-point the log entry using time identified by lockoutstatus

- We are looking for: event ID 675 (4771 in w2k8?), the client IP is the offending machine that sent bad pwds

- Failure code in event ID 675(This is corresponding kerberos error code, full list here)

• 0x18: original wrong password
• 0x12: this will be logged after the fact that account has already been locked

- Logon type in event ID 675 ( full list here)

• 2 being interactive
• 3 network
• 5 service
• 10 Remote interactive

Local Admin Account vs. account lockout

You can't really lock out an admin account - as long as you type in the correct password on *local console*, the system will unlock it automatically. This makes sense - legit users need a way to get into the system when all other credentials are failing - completely locking out all users surely won't make happy customers.

However this increases the risk of being cracked by brutalforce method. For companies who want to maximize the security and are willing to pay the cost of losing acceess due to lost passswords, there is a way to put admins under same lockout policy as ordinary users. MS has an old tool called passprop.exe that can enforce lockout policy, even against admins.

        passprop /adminlockout

This is no longer needed in Windows 2008. There are pre-define security polices in Windows 2008 will do the same.