Does Windows 2000's Audit account logon events audit category have any value on systems that aren't domain controllers (DCs)? I can find information only about how to use this policy on DCs as a centralized way to track domain logons. Can I enable the policy on member servers or workstations to collect more data than the Audit logon events audit category provides?
The Audit account logon events audit policy records Account Logon events, whereas the Audit logon events audit policy records Logon/Logoff events. Audit account logon events is intended primarily for use on DCs but also provides useful information about member servers and workstations.
When someone tries to log on to a computer through a domain account, Win2K records only Logon/Logoff events. However, when someone tries to log on to a computer—at the console or over the network—through a local account in that computer's SAM, Win2K records both the Account Logon and the Logon/Logoff events. Both types of events record the time and success or failure of logon attempts, but each type provides details that the other doesn't. The most important information that Account Logon events provide about a member server or workstation is that someone tried to use a local account to log on. In a domain environment, local-account logons are suspicious because they defeat the purpose of domains (i.e., centralized account management and monitoring) and users seldom have any legitimate need to log on through a local account.
When you enable the Audit account logon events audit policy on a system, the computer begins recording authentication events involving the user accounts stored on that computer. Therefore, when you enable the policy on a member server or workstation, Win2K records authentication events involving any of the local user accounts in the computer's SAM. For example, suppose someone walks up to a member server and tries to use the local Administrator account to log on. Or suppose someone tries to use that account and the Connect using a different user name logon option to map a drive to the server from across the network. In such situations, Win2K records the appropriate Account Logon events.
Account Logon events also specify the computer name in the case of remote logon attempts—useful information for tracking down the origins of such attempts. Logon/Logoff events are useful in these types of situations because the events' descriptions usually include the Logon Type field, which specifies how the person tried to log on (i.e., at the console or from over the network).
A DC stores domain accounts, so when you enable Audit account logon events on a DC, the system records all authentication events involving domain accounts. (You can monitor Account Logon events on all your DCs to establish a complete record of all instances in which someone tried to use a domain account to log on to any computer on the network.) On a DC, Win2K records both Account Logon and Logon/Logoff events when someone tries to log on at the console or from over the network. Such logon attempts are the only times when Win2K records Logon/Logoff events on a DC, although Win2K also records Account Logon events whenever another computer on the network uses the DC to authenticate a user. (That scenario makes up a majority of the events in the Security log.)
The bottom line, then, is that on workstations and member servers, Account Logon events give you a quick way to identify instances of local accounts being used for logons—typically a no-no. Look for NT LAN Manager (NTLM) authentication event IDs 680 (successful authentication) and 681 (failed authentication). You don't need to look for Kerberos events because local-account logons never use Kerberos.
On DCs, Account Logon events help you monitor logon activity for all domain accounts through the relatively few DC Security logs. You can use Logon/Logoff events on DCs to discover users attempting to access the DC at the console. To do so, look for event ID 528 (successful logon) and event ID 529 (failed logon) with a Logon Type 2, which indicates an interactive logon. For more information about both event categories, see my Windows & .NET Magazine articles "Tracking Logon and Logoff Activity in Win2K" (http://www.winnetmag.com, InstantDoc ID 16430) and "Audit Account Logon Events" (http://www.winnetmag.com, InstantDoc ID 19677).
