Security is at the top of every systems administrator's priority list. A good security strategy involves combining a variety of methods to keep malicious intruders and processes (e.g., viruses, worms) at bay—all while remaining transparent to authenticated users. Aside from implementing an arsenal of technology to secure your networks, you also need to diligently monitor your security event logs for unauthorized-access attempts. Windows Server 2003 and Windows 2000 domain controllers (DCs) have made significant improvements in security-event auditing. Specifically, DCs add new event IDs to distinguish various security events that are, in Windows NT, simply categorized into one or two generic security-event entries.
How often have you taken calls from users asking why their account has become locked and claiming that they haven't yet tried to log on? If you follow sound security procedures, you determine where and how the user's account became locked before you unlock it because that locked account could be a sign of malicious activity on your network. I've found that the accounts of many desktop technicians get locked because they persistently use their own credentials at a user's desk to map a drive letter onto network shares and forget to disconnect afterward. If quickly determining the origin of the locked account were simple, the technician could correct the problem to prevent future lockups. I needed a way to quickly obtain all the failed logon attempts on my DCs without having to go to each one individually. . . .
