Account Logon Event Auditing and Reporting Before the Security event log will keep a record of logon events, auditing must be configured. Auditing can be turned on thru the Local Security Settings console or done with a domain based Group Policy Object (GPO). The location for the auditing policies are: o Local Security Settings|Local Policies|Audit Policy o GPO| ... Audit logon events..........: Windows Console logon events Audit account logon events..: SMB and RPC logon events DC only: "Audit directory service access" lets you track changes to Active Directory (AD) objects (e.g., users) down to the property level. For example, you can use this category to distinguish password resets from phone-number changes. http://technet.microsoft.com/en-us/library/Bb742436.aspx The Audit account logon events category name is confusingly similar to the Audit logon events category name. Window 2000's Audit logon events is the same as Windows NT's familiar Logon and Logoff audit category. The problem with Audit logon events and Logon and Logoff is that Windows 2000 and NT record these events on the system on which the logon occurs. When a user logs on interactively at a workstation, Windows 2000 and NT record the logon event in the local workstation's Security log—if you've turned on audit policy at the workstation. When a user connects to a server over the network (e.g., by using a drive mapping), Windows 2000 and NT record the network logon on the server's Security log. As a result, logon and logoff activity events are scattered across every system in your network. Microsoft heard our complaints and added the "Audit account logon events" category, which tracks user authentication at centralized points: the DCs in your domain. Machine Specific Audit Logon Events Successful Logons Windows 2000 uses the Audit logon events category when a user logs on interactively (i.e., at the local keyboard and screen) or remotely (i.e., from over the network). The Logon Type field in the event's description contains a number that specifies the logon's nature: interactive (2), network (3), batch (4), service (5), unlocked workstation (7), network logon using a cleartext password (8), or impersonated logons (9). As in NT, event ID 528, which Figure 4 shows, describes a successful logon. However, whereas NT used event ID 528 for every type of logon, Windows 2000 uses a different event ID for network logons. When you map a drive to a server, connect to the server's registry, or otherwise perform a network logon, Windows 2000 logs the new event ID 540, which Figure 5 shows. This new event is useful because it lets you separate network logons from other logon types. (I'd like Microsoft to create a separate event for the other important logon type: interactive logons.) Windows 2000 logs a lot of irrelevant event ID 540 occurrences. To distinguish these events from relevant events, look at the event's User Name field, which will be either a normal user account, SYSTEM, or a computer name ending with the dollar sign ($) character. A normal user account notifies you that a user logged on to the system from over the network; you want to pay attention to these events. You can ignore events in which the User Name is SYSTEM, which indicates that one system service was connecting to another service on the same system. You can also discount events in which the User Name is a computer followed by the $ character, which means that the system services on a remote system are connected to the system services on this system. (For example, when a Windows 2000 Professional workstation starts up, it connects to the DC for AD information and other domain services. To access these domain services, the workstation must first authenticate itself to the DC.) The Domain field in event ID 528 and event ID 540 identifies the domain on which the user's account resides. This field uses the pre-Windows 2000 NetBIOS domain name rather than the DNS version of the domain name. If a user uses a local account in a system's local SAM to log on to that system, the event's Domain field will reflect the computer's NetBIOS name. You won't often see local user account logons in a domain environment; however, attackers like to target local SAM accounts—especially the Administrator account—so keep an eye out for event ID 528 or event ID 540 occurrences in which the Domain field matches the Computer field. Event ID 540's Logon Process and Authentication Package fields let you determine which authentication protocol Windows 2000 used when the user connected to the system. When a user connects to a Windows 2000 system from over the network, Windows 2000 negotiates the use of one of two possible authentication protocols: NT LAN Manager—NTLM—or Kerberos. Identifying systems that aren't using Kerberos is important: Those systems are more vulnerable to attack because NTLM is weaker than Kerberos. Windows 2000 prefers to use the stronger Internet-standard Kerberos but can do so only between two Windows 2000 systems that trust each other (e.g., systems in the same forest, systems in domains connected by explicitly defined one-way trusts). If set up correctly, non-Windows 2000 Massachusetts Institute of Technology (MIT) Kerberos 5.0 systems can also use Kerberos with Windows 2000 systems. In all other cases (e.g., when either computer is a Windows 2000 system that doesn't belong to a domain, when either computer is an NT system), Windows 2000 falls back to the older and weaker NTLM protocol, which attackers can sniff and crack with relative ease. (Although you can upgrade your systems to NTLMv2 to provide some protection against malicious activity, you'll have those risky NTLM packets on your network until you migrate all your systems to Windows 2000. To learn more about NTLMv2, see " Inside SP4 NTLMv2 Security Enhancements," September 1999.) When you've upgraded all the client computers that will connect to a given server, check the server's Security log for event ID 540 in which the Authentication Package field is NTLM instead of Kerberos. If you find some NTLM logons, you can look at the event's Workstation Name field to determine the client computer's NetBIOS name. (This field is blank when Windows 2000 uses Kerberos.) To link a successful logon event (i.e., event ID 528 or event ID 540) to its corresponding logoff event (Windows 2000 records successful logoffs with event ID 538, just as NT does), use the Logon ID number that appears in both events. For example, suppose you see a logon event for Administrator at 1:27 p.m., and you want to know when Administrator logged off. Note the Logon ID in event ID 528 (e.g., 0x0, 0xEC87 in Figure 4), then right-click the Security log in Event Viewer and click View/Find to search the event log for that number. I have a bit of bad news, though. Windows 2000 suffers from the same strange bug that NT suffers from: The OS occasionally neglects to log event ID 538. (So far, in Windows 2000, I've noticed this problem only for interactive logons.) In other words, you might see an event ID 528 that doesn't have a corresponding event ID 538. Failed Logons The events for failed logons in Windows 2000 haven't changed much from NT. When a user attempts to log on with an invalid username or password, Windows 2000 records event ID 529. When a user has a disabled account or is locked out, the system logs event ID 531 and event ID 539, respectively. When a user tries to log on outside the times or days permitted for that user account, Windows 2000 logs event ID 530. When an account has reached its account expiration date or when a user's password has expired, the system logs event ID 532 or event ID 535, respectively. When you limit a user to logging on at specific workstations and the user tries to violate this restriction, Windows 2000 records event ID 533. You can also use rights to restrict users to certain types of logons for specific systems. If a user doesn't have rights to access a computer from the network and the user tries to map a drive to that system or view that system's registry, the system logs event ID 534. This event also occurs when a user tries to log on at the console and doesn't have the right to log on locally. If a service that attempts to start using an account that doesn't have the Logon as a service right, it triggers event ID 534. Processes that try to log on as a batch job using an account that doesn't have the Logon as a batch job right also trigger event ID 534. If a logon fails for some other reason, you'll see event ID 537 with the following Logon Failure explanation: An unexpected error occurred during logon. All these failed logon events also provide Logon Type information, which lets you distinguish failed logons at the local console from someone trying to connect from over the network. http://technet.microsoft.com/en-us/library/bb742435.aspx Successful Kerberos Events Windows 2000 reports different account logon events depending on which authentication protocol the involved systems use for a given logon request. As I explained in my February 2001 article, Windows 2000 supports both Kerberos and Windows NT LAN Manager (NTLM). When a user logs on interactively at a Windows 2000 Professional workstation or uses a Windows 2000 domain account to connect from a Windows 2000 Pro workstation to a Windows 2000 server, the involved systems use Kerberos and the DC logs Kerberos events. However, when a user logs on interactively at an NT workstation or connects to or from an NT system, the systems use NTLM and the DC logs a different set of events. The Kerberos authentication protocol uses encrypted, time-stamped tickets to control the ability to log on to systems. To give you access to a system—even the workstation in front of you—Windows 2000 first requests a service ticket from the DC. This service ticket contains information that assures your authenticity to the system you're trying to access. However, before the DC will grant you service tickets, you must first authenticate yourself to the DC and thereby acquire a ticket-granting ticket (TGT). The only time the DC actually verifies your password is when you initially log on at your workstation and the workstation requests your TGT. After acquiring your TGT, your workstation includes your TGT with each new service ticket request as you connect to other network services (e.g., file servers, Microsoft SQL Server, Microsoft Exchange Server). Windows 2000 logs different event IDs for successful and failed TGT and service-ticket requests. (For information about Kerberos, see Jan De Clercq, " Kerberos in Windows 2000," October 1999.) Each morning when a user sits down at his or her workstation and enters his or her domain username and password, the workstation contacts a local DC and requests a TGT. If the username and password are correct and the user account passes status and restriction checks, the DC grants the TGT and logs event ID 672 (authentication ticket granted), which Figure 1 shows. The User field for this event (and all other events in the Audit account logon event category) doesn't help you determine who the user was; the field always reads SYSTEM. Instead, you need to look at the User Name and Supplied Realm Name fields, which identify the user who logged on and the user account's DNS suffix. (When you create a user account, you can use the domain's entire DNS name or the name of the tree's root domain in NT's domain\username format.) The User ID field provides the same information in NT style (i.e., the NetBIOS domain name followed by a backslash and the username). The Service Name field identifies which service the DC granted the user a ticket to. In the case of an initial workstation logon, the DC grants the user a ticket to the krbtgt (i.e., Kerberos ticket granting) service. The next field of interest is Client Address, which identifies the IP address of the workstation from which the user logged on. All Kerberos events, including failed logon attempts, include Client Address. This information is extremely valuable. In NT, you can track failed logon attempts for an individual system, but you have no idea where the attempts are coming from. In Windows 2000, you not only have centralized logon activity records on DCs but also can tell where the logon events originate. You'll see other instances of event ID 672 when a computer in the domain needs to authenticate to the DC—typically when a workstation boots up or a server restarts. (Before a computer can access Group Policy information or register its DNS name, the machine must authenticate to the DC.) In these instances, you'll find a computer name in the User Name and User ID fields, as Figure 2, shows. (You can always recognize computer-account names in account logon events by the dollar sign character—$—appended to the name.) Whereas event ID 672 lets you track initial logons through the granting of TGTs, event ID 673 (service ticket granted) lets you monitor the granting of service tickets. For example, when a user maps a drive to a file server or connects to some other system resource (e.g., the registry, event log, SAM) on a remote system, the resulting service ticket request generates event ID 673 on the DC. Windows 2000 also logs event ID 673 in several less-relevant situations. First, you'll see many system-to-system occurrences of this event, which you can recognize by looking for events in which the User Name is a computer account. (This situation occurs, for example, when a workstation connects to a DC to read Group Policy information.) You'll also see occasional instances of event ID 673 in which the User Name is a normal user account and the Service ID field is krbtgt. Be sure you understand event ID 672's relationship to event ID 673. Being granted a TGT (event ID 672) doesn't give a user access to any system; a TGT simply signifies that the user has proved his or her identity to the DC and can now ask the DC to vouch for the user's identity as he or she requests and receives service tickets (event ID 673) to log on to various systems. After a user's workstation requests a TGT, the workstation immediately requests a service ticket so that the user can use the workstation. For example, the Security log that Figure 3 shows reveals that an event ID 673 immediately followed an event ID 672. If you review the event ID 673, which Figure 4 shows, you can tell from the User Name, Service Name, and Service ID fields that Maggie logged on to a workstation named W2KPRO-LEFT. You know from the User Domain and Service ID fields that both the user and computer are in the MTG.LOCAL domain. Figure 5 shows the next event ID 673 in the example log. This event shows that Maggie logged on remotely to the TECRA system from the W2KPRO-LEFT workstation. We can tell from the Service Name and Service ID fields that Maggie logged on to TECRA, but how do we know the logon was a remote logon from W2KPRO-LEFT? Notice the Client Address: 10.0.0.81. The first event ID 673 following an event ID 672 always documents the granting of a service ticket to access the workstation on which the user is interactively logged on. Because Maggie initially requested a TGT from 10.0.0.81 and then immediately requested a service ticket to W2KPRO-LEFT, we can conclude that 10.0.0.81 is the IP address for W2KPRO-LEFT. Subsequent event IDs 673, such as the one that Figure 5 shows, reveal Maggie logging on to other systems from the same client address (i.e., 10.0.0.81) as she maps drives or uses other services. To prevent time-based attacks, Kerberos limits how long a ticket is valid. If a ticket expires when the user is still logged on, Windows 2000 automatically contacts the DC to renew the ticket. When the DC renews the ticket, it also logs event ID 674 (ticket granted renewed). Failed Kerberos Events Which events does Windows 2000 log when authentication fails? When a user attempts to log on at a Windows 2000 Pro workstation and uses a valid domain account name but enters a bad password, the DC records event ID 675 (pre-authentication failed) with Failure Code 24, as Figure 6 shows. This event is extremely valuable: By reviewing each of your DC Security logs for this event and failure code, you can track every domain logon attempt that failed as a result of a bad password. In addition to providing the username and domain name, the event provides the IP address of the system from which the logon attempt originated. This provision is a tremendous advance over NT's failed-logon tracking, which only logs the username and domain name. Windows 2000 also logs event ID 675 when a user attempts to use a different username (i.e., a username other than the one he or she used for the current workstation logon) to connect to a server. For example, a user might try to use the Connect using a different user name feature to use someone else's account to map a drive to a server. Sometimes a logon fails not because of a bad password but because the user mistyped the username or tried to guess someone else's username. If a logon fails because of an invalid username, Windows 2000 logs event ID 676 (authentication ticket request failed) with Failure Code 6. This event is another important logon auditing advance because in NT you can't distinguish logons that failed because of a bad password from logons that failed because of a bad username. Windows 2000 uses event ID 676 with other failure codes to identify several other types of failed-logon situations. Failure Code 12 indicates the logon failed because of time-of-day or workstation restrictions. Failure Code 23 means the user's password had expired. Failure Code 18 signifies that the account was locked out because of failed logons, disabled by the administrator, or expired. Failure Code 37 occurs when a workstation's clock was too far out of synchronization with the DC's clock. Sometimes an attempt to acquire a service ticket fails even though the DC successfully authenticated the user and granted a TGT. In this case, Windows 2000 logs event ID 677 (service ticket request failed) with a variety of failure codes depending on the situation. When users try to connect from Windows 2000 Pro workstations to NT servers on your network, you'll regularly encounter event ID 677 with Failure Code 7, which Figure 7 shows. In this example, the user was logged on at a Windows 2000 Pro workstation (i.e., Client Address 10.0.0.81) as Administrator and mapped a drive to an NT Server system (i.e., Kramer) in a Windows 2000 domain (i.e., MTG.LOCAL). The workstation first asked the DC to grant a Kerberos service ticket, but that request failed because the NT server doesn't support Kerberos. Thus, the DC logged event ID 677 with Failure Code 7. This type of error is transparent to the user because the workstation immediately falls back to using NTLM. NTLM Events When the DC uses NTLM to successfully authenticate a user, the DC logs event ID 680 (account used for logon), which Figure 8 shows. This event, which is similar to Kerberos's event ID 673, not only specifies which user account logged on but also identifies the client system from which the user initiated the logon. This additional detail is similar to event ID 673's Client Address field, but because NTLM can be carried over TCP/IP, NetBEUI, or IPX, Windows 2000 logs the system's name instead of its IP address. If an NTLM authentication request fails for any reason, the DC logs event ID 681, which Figure 9 shows. The event description's error code provides the reason for the failure. Table 1 lists the event's error codes and their meanings. Table 1 Error Codes for Event ID 681 Error Code Reason for Logon Failure 3221225572 The username doesn't exist. 3221225578 The username is correct, but the password is wrong. 3221226036 The user is currently locked out. 3221225586 The account is currently disabled. 3221225583 The user tried to log on outside the user's time-of-day restrictions. 3221225584 The user tried to log on outside the user's workstation restrictions. 3221225875 The user account has expired. 3221225585 The user tried to log on with an expired password. 3221226020 The user tried to log on with an account on which the administrator has selected the User must change password at next logon option. Windows 2000's new Audit account logon events category is exciting because it gives a much more centralized view of logon activity. You can distinguish between logons that failed because of bad usernames as opposed to bad passwords. You can track failed logons back to the offending workstation. However, don't stop reviewing your server Security logs for the Audit logon events category—attackers might try to enter a system by using a local SAM account, such as the built-in Administrator account, and DCs won't log attacks that use local accounts. Audit logon events and Audit account logon events combine to give you in-depth tracking of logons at workstations, servers, and DCs. ----------------------------------------------------------------------------- HOW TO: Configure Performance Counters and Logs to Monitor Unauthorized Attempts to Access Your Computer in Windows 2000 Server: http://support.microsoft.com/kb/300504 The above KB article has the following note: The counter does not monitor failed interactive logons at the console or through Remote Desktop Protocol (RDP). Instead, the counter only monitors server message block (SMB) communications logons (for example, when a user tries to open a file on the server but they lack permissions to the share). The Server object in Performance Monitor refers only to shares. ----------------------------------------------------------------------------- To be thorough, you must monitor each DC and member server. A DC's Security log is the only place in which you can find information about the logons that the DC handled. Check all DC Security logs for event ID 675 with failure code 24 and event ID 681 with error code 3221225578 to learn about all attempts to authenticate using a domain account and bad password. You must also monitor member servers because attackers can use local accounts on each server's SAM to try to gain access. On member servers, look for event ID 529. To receive a report of events automatically, you can download Jesper Lauritsen's free ELDump tool from: http://www.ibt.ku.dk/jesper/eldump/default.htm. ELDump is a flexible tool that lets you sort events according to your criteria. The following command produces a list of event ID 529 instances that occurred in the past 24 hours on server1: eldump.exe -l security -e 529 -O dts -m Security -A 24 —s \\server1 -M Note that ELDump's parameters are case sensitive. As Figure 1 shows, the output format I specified reports only the time and insertion string from the event's description. If you want to see the entire message text, run the same command without the —M parameter.