Win2K prefers to use the stronger Internet-standard Kerberos but can do so only between two Win2K 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-Win2K Massachusetts Institute of Technology (MIT) Kerberos 5.0 systems can also use Kerberos with Win2K systems. In all other cases (e.g., when either computer is a Win2K system that doesn't belong to a domain, when either computer is an NT system), Win2K 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 Win2K. 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 Win2K uses Kerberos.)
To link a successful logon event (i.e., event ID 528 or event ID 540) to its corresponding logoff event (Win2K 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. Win2K suffers from the same strange bug that NT suffers from: The OS occasionally neglects to log event ID 538. (So far, in Win2K, 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 Win2K haven't changed much from NT. When a user attempts to log on with an invalid username or password, Win2K 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, Win2K 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, Win2K 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.
Stay Tuned ...
The Audit logon events category can provide plenty of useful information. However, remember that Win2K records all the events in this category in the local system's log. Thus, you must view logon and logoff activity and track suspicious failed logons one workstation and server at a time—an impractical practice on a large network. Thankfully, we can turn to Win2K's new Audit account logon events audit category. I'll delve into that category in the next installment of this series.
Register
tom baumgratz August 08, 2002