Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

March 21, 2005 12:00 AM

Consolidated Security Event IDs in Windows 2003

Windows IT Pro
InstantDoc ID #45556
Rating: (0)

I'm having problems monitoring failed authentication events on my Windows Server 2003 domain controllers (DCs). Prior to upgrading our DCs, we set up rules in our log-monitoring solution to look for event ID 675 and event ID 676 for Kerberos authentication failures and event ID 681 for NT LAN Manager (NTLM) failures. However, after upgrading to Windows 2003, our log monitor immediately stopped reporting all domain-account authentication failures except for bad password attempts, which are logged by event ID 675. What happened?

Let's briefly review the events that prompt the event IDs you mention.

Windows 2000's Account Logon Security log category generates event ID 675 when Kerberos pre-authentication fails. In the real world, pre-authentication typically fails for only one reason: a bad password, which generates event ID 675 with failure code 24 in the event description. If a workstation's clock falls out of sync with the DC, you'll see event ID 675 with failure code 37. All other Kerberos failures are logged by event ID 676 on Win2K. The failure codes correspond to the error codes documented in the Kerberos Request for Comments (RFC) 1510 at http://www.ietf.org/rfc/rfc1510.txt.

Pre-Win2K computers generate different events because they require NTLM instead of Kerberos for authentication. When NTLM authentication fails for any reason on Win2K DCs, you'll see event ID 681.

In Windows 2003 and Windows XP, Microsoft eliminated event ID 675, event ID 676, and event ID 681 as part of a larger effort to reduce the number of event IDs and pack more information into fewer events. These three failure events were merged with their corresponding success events. Therefore, event ID 676 was replaced by failure-type event ID 672 and event ID 681 was replaced by failure-type event ID 680. When you change your alert rules to look for the new event IDs, don't forget to also configure the rule to trip only if the type is failure. I've created a chart that documents all these event IDs and codes, which you can download at http://www.ultimatewindowssecurity.com/getquickreference.asp.

Related Content:

ARTICLE TOOLS

Comments
    There are no comments to display. Be the first one!
You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.