Access Denied: Auditing Account Logon Events Centrally

Two security events new to Windows 2000—event ID 680 and event ID 681—seem to mirror event ID 528 (user logon) and event ID 529 (failed logon: bad username or password), which have existed since Windows NT. How do these two sets of events differ?

The difference lies in distinguishing local logon activity from domain controller (DC) authentication. One problem with NT has been that the OS records logon activity on the local computer only—not centrally at the DC. Whenever you log on at your NT workstation or connect to a server—or, more important, fail to log on or fail to connect—NT logs the event on the workstation and server, respectively. Thus, although NT captures logon events, it scatters them across several computers in the domain.

In Win2K, Microsoft added a new audit category, Audit account logon events, which lets you track logon activity centrally. If you enable Audit account logon events on a computer, whenever you attempt to log on with a domain account, Win2K logs the event at the local computer. If you enable Audit account logon events enabled on the DC, Win2K logs an event there, too.

Audit account logon events logs one set of event IDs when you use Kerberos authentication and a different set of event IDs when you use NT LAN Manager (NTLM). Event ID 680 (successful authentication) and event ID 681 (failed authentication) are NTLM authentication events. When you see event IDs 680 and 528 in proximity for the same user, a user has logged on to the DC itself rather than on to a workstation or server. When you see event IDs 681 and 529 in proximity for the same user, it means that someone tried to log on to the DC itself with a bad password. For more information about these events, including the meaning of codes you find in the events' descriptions, see "Audit Account Logon Events" (http:// www.win2000mag.com, InstantDoc ID 19677) and "Tracking Logon and Logoff Activity in Win2K" (http:// www.win2000mag.com, InstantDoc ID 16430).