Freigeben über

Deciphering Account Logon Events

  • Artikel

One of the most common questions that I get about Windows Auditing is, how come you guys were so @#%! stupid that you put in two logon categories?

The answer is actually pretty simple- we're bad at choosing names. "Account Logon" isn't really about logon, it's about credential validation.

Here's the low down on what is the difference between Logon/Logoff and Account Logon events, and how to decipher Account Logon events.

Audit Logon/Logoff generates events for the creation and destruction of logon sessions. These events occur on the machine which was accessed. In the case of an interactive logon, these would be generated on the machine which was logged on to. In the case of network logon, for example, accessing a share, these events would be generated on the machine hosting the resource that was accessed.

Audit Account Logon generates events for credential validation. These events occur on the machine which is authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local machine is authoritative. Since domain accounts are used much more frequently in enterprise environments than local accounts, most of the Account Logon events in a domain environment occur on the domain controllers which are authoriative for the domain accounts. However, these events can occur on any machine, and may occur in conjunction with or on separate machines from logon/logoff events.

Logging on interactively to a workstation, using a domain account, can cause more activity than you might expect on the DC. An interactive logon is pretty complex and involves multiple steps. Typically, from the time you turn on your workstation until the time you are viewing your desktop, the following things happen:

  • Machine establishes trust with domain: Kerberos AS request (Event 672 on the DC), Kerberos TGS request for AD (DC, 673)
  • Machine gets policy: Kerberos TGS request for access to Netlogon share on DC [group policy] (DC, 673) (DC, 540, 538, maybe more than once)
  • User logs on: Kerberos AS request (DC, 672), Kerberos TGS request for AD (DC, 673), Logon session created (workstation, 528, 576)
  • User gets policy: Kerberos TGS request for DC\Netlogon [logon scripts, group policy] (DC, 673), Network logon (DC, 540, 538, usually 2-3 rounds)

In Account Logon failures for Kerberos, the KDC has to generate an AS reply with an RFC 1510 error. Since RFC 1510 error codes don't contemplate Windows-specific errors, and we have to return Kerberos-specific errors in Kerberos AS request failure replies, we had to map Windows error conditions to kerberos error codes. The error code mappings are described in the Kerberos Troubleshooting document that is available on Microsoft.com: https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

Here are some questions that you might have about Account Logon events:

Q: Why do you only have the IP address in the Account Logon event, and not the computer name?
A: There are three reasons:

  1. There is no secure method for the KDC to get the remote machine's name at the current time. If the client provides the name (as in NTLM), then it's not trustworthy and can be spoofed. There are Unix-based hacking tools which spoof workstation name in NTLM auth requests.
  2. DNS and NetBIOS reverse lookup are not secure and are not reliable- if we tried this, we'd have a high incidence of incorrect or missing information, and hurt performance.
  3. Even if we chose to do add the name anyway, when we could, there's no field for us to use to carry it in Kerberos AS REQ & TGS REQ messages- we'd have to overload some other field, and run a high risk of loss of compatibility with MIT's reference implementation.

Q: How do I correlate the Account Logon event on a DC with the Logon/Logoff event on the machine which was accessed?
A: Easy! The Account Logon event and the Logon/Logoff event both contain a field called a Logon GUID, starting in Windows Server 2003. Just compare the GUIDs- if they match, it's the same Kerberos ticket. Unfortunately this only works for Kerberos; other Logon events contain a GUID that is all zeroes.

Q: Is there such a thing as an Account Logoff event?
A: No. The DC is only aware of logons, not logoffs (there's no possible way to force a machine to contact a DC when logging off- consider crashes, etc.)

Q: I just want to monitor my DC's logs. Is that good enough?
A: Well, the DC has a distorted view of logon as mentioned above. Also, the DC only knows where the logon request came from most recently. Consider using IIS- the logon request originates at a browser somewhere on the internet. IIS receives the request and then sends a logon request to the DC. From the DC's point of view, the source of the logon is IIS. If you only collect the DC's logs, you'll miss the detail of where the request came from. This is true for any network service- RPC, file sharing, remote desktop, etc. Also, the DC doesn't have enough information to answer "how long was the user logged on". However there is one really interesting piece of information in DC logs. In event 673 (Kerberos Service Ticket granted), the service name is listed. This is the most detail that the DC can provide, on what the user was logging on for.

Eric

Comments