Deciphering Authentication Events on Your Domain Controllers

Want more advice from Randall F Smith? Check out his seminar below:

Attend the only 2-day seminar devoted to the Windows security log

Beginning with Windows 2000, Microsoft introduced a new audit policy called “Audit account logon events” which solved one of the biggest shortcomings with the Windows security log. Until this new category it was impossible to track logon activity for domain accounts using your domain controllers’ security logs. (You can view and configure your domain controllers’ audit policy from the Default Domain Controllers Security Policy shortcut in Administrative Tools. Use Event Viewer to view your security log.)  Prior to Windows 2000 all you had was the “Audit logon events” category which didn’t work the way most people expected.  When you enable “audit logon events” on NT and later domain controllers, the only logon events you’ll see in the domain controllers’ security logs are users and computers logging on to the domain controller itself. With “audit logon events” enabled, domain controllers do not record any activity related to domain users logging on at their workstations or other servers. The reason is that the concept of a logon is different than authentication. When you logon at your workstation with a domain account – you are logging into the workstation – not the domain controller. The domain controller is simply performing the authentication check. Therefore the old “audit logon events” audit policy doesn’t do you much good for tracking domain user logon activity or failed logon attempts. You’d have to enable “audit logon events” on each workstation and server on your network and then monitor those logs and you still wouldn’t see failed logon attempts by attackers using their own workstation.  Thus, the need for the new audit policy introduced with Windows 2000 – “audit account logon events”. When you enable this policy on Windows 2000 or 2003 domain controller this policy records all domain account authentication that occurs on that domain controller in that domain controller’s security log. This activity is categorized as “Account Logon” in the security log as opposed to “Logon/Logoff” for the “audit logon events” policy. When you analyze the combined “Account Logon” activity of all your domain controllers you now how a complete picture of the logon activity of all domain accounts in your domain regardless of where the logon attempts are initiated from – computers of the local or trusted domain or even unknown computers completely outside your AD forest and external trusted domains.

Windows 2000 and 2003 domain controllers support Kerberos and NTLM authentication protocols. When a Windows 2000 or later computer needs to find out if a domain account is authentic the computer first tries to contact the DC via Kerberos. If it doesn’t receive a reply it falls back to NTLM. In an AD forest comprising computers running Windows 2000 and later all authentication between workstations and servers should be Kerberos. Windows 2000 and later domain controllers log different event IDs for Kerberos and NTLM authentication activity so it’s easy to distinguish them. In an AD forest of Windows 2000 or later computers, any NTLM authentication events you see on domain controllers can only have a few explanations. First, Windows will fall back to NTLM if routers for some reason block Kerberos traffic (UDP port 88). Second, if your domain trusts another domain outside your forest (defined in Active Directory Domains and Trusts) you’ll see NTLM events on you domain controllers since Kerberos doesn’t work for external trust relationships. (Note: Windows Server 2003 supports a new type of trust call cross forest trusts. A cross forest trust is a transitive, 2-way trust between 2 Windows Server 2003 domains. Cross forest trusts use Kerberos – not NTLM.) The third explanation for NTLM events on your domain controller’s security log are rogue computers. Contrary to popular misconception, Windows does not prevent a user at a computer from an un-trusted domain or stand-alone computer (Windows computer that doesn’t belong to any domain) from connecting to a server in your domain using a domain account.  To prove this just map a drive to a computer in an untrusting domain using the “net use” command. For instance in the below example I connect to a file server called NYC-FS-1 in the NYC domain using the domain Administrator account and a password of #dk32HE4. 

net use \\nyc-fs-1.nyc.acme.local\c$ #dk32HE4 /user:nyc\administrator

If you have an application such as an IIS web application that uses NTLM authentication you will see NTKM also. About the only other explanation for NTLM events on your domain controller security logs is more mundane – you just have some pre Win2k computers somewhere in your local domain or in the overall forest.

The bottom line is that if an outsider is attacking accounts in your domain you will most likely see them as NTLM authentication errors – not Kerberos. Windows 2000 logs just 2 event IDs for all types of NTLM authentication activity – 680 and 681. A successful NTLM authentication yields an event ID 680 and a failure produces event ID 681. Both events list the user name that failed authentication as well as the name of the computer from when the authentication attempt originated (usually the user’s workstation).  To determine why the authentication failed you need to look at the error code in event ID 681’s description. See figure 1 for a listing of NTLM error codes. NTLM yields an authentication event whenever a user logs on to a computer interactively or over the network. For instance, imagine a user logs on to his NT workstation with a domain account and then uses a share folder on server A and server B. On whichever domain controller(s) that handles those authentication requests you’ll see a total of 3 event ID 680s – one for the interactive workstation logon and 2 for the network logon at server A and server B. 

Things are a little different on Windows Server 2003 however. Annoyingly, in Windows Server 2003 Microsoft eliminated event ID 681 and instead uses event ID 681 for both successful and failed NTLM authentication attempts. So on Windows Server 2003 don’t look for event ID 681 and be sure to take into account the success/failure status of occurrences of event ID 680.

So turn on auditing for “audit account logon events” on your domain controllers and keep an eye out for event IDs 680 and 681 – they might reveal some computers that have missed being upgraded or worse an attack from an outsider. If you have multiple domain controllers and servers it helps to have a tool like this site’s sponsor – GFI’s LANGuard SELM – that can merge all that activity into one database and provide centralized alerts and reporting. While tracking NTLM authentication is important, don’t forget about Kerberos authentication which will likely be the bulk of authentication activity in your domain controller security logs. We’ll look at Kerberos security events in my next article.

Randy Franklin Smith, president of Monterey Technology Group, Inc. and a Systems Security Certified Professional, is the creator and exclusive instructor for the 5 day Ultimate Windows Security seminar at ultimatewindowssecurity.com.

Ultimate Windows Security: Information

Ultimate Windows Security is a 5 day hands-on, heads-down, technical course that covers each area of Windows security. The course focuses on Windows Server 2003 but Randy addresses each point relates to Windows 2000, XP and even NT. Ultimate Windows Security covers the Windows security foundation such as account policy, permissions, auditing and patch management on day one. On day 2 you focus on Active Directory and Group Policy security. Day 3 takes you on a highly technical tour of Certificate Services, Routing and Remote Access Services and Internet Authentication Services. On day 4 you learn how to put these 3 technologies together to solve real world security needs such as 2-factor VPN security, WiFi security with 802.1x and WPA, implementing Encrypting File System reliably and securely and using IPSec to handle a variety of network security issues. Day five takes you deep into the shrouded world of the Windows security log. Randy will unveil this woefully undocumented area of Windows and show you how to track authentication, policy changes, administrator activity, tampering, intrusion attempts and more. You can attend Ultimate Windows Security publicly at training centers across America or bring the course to you by scheduling an in-house/on-site event. To register or learn more browse to ultimatewindowssecurity.com.