Windows Security Logging and Other Esoterica : Descriptions

Mapping pre-Vista Security Event IDs to Security Event IDs in Vista+

Eric Fitzgerald — Thu, 11 Jun 2009 02:09:00 GMT

I've written twice (here and here) about the relationship between the "old" event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the "new" security event IDs (4xxx-5xxx) in Vista and beyond.

In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.

The exceptions are the logon events. The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096). The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).

Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change). These are all new instrumentation and there is no “mapping” possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can’t say that the old event xxx = the new event yyy because they aren’t equivalent. The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.

Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is "+4096" instead of something more human-friendly like "+1000". The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn't know the version of Windows that produced the event. We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.

So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4. You can do this in your head.

However if you're trying to implement some automation, you should avoid trying to make a chart with "<Vista" and ">=Vista" columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you'll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).

Eric

Windows Server 2008 Security Events Posted

Eric Fitzgerald — Thu, 17 Apr 2008 09:09:00 GMT

Fadi, Ned and Brian of the auditing team have documented all the auditing events by audit policy category and subcategory for your reference.

Check it out in the Knowledge Base.

Even better, they documented all the events in spreadsheet format, and that's propagating to the Microsoft Download Center. I'll publish the link when it's online.

2008-04-17 UPDATE: Brian just sent me the link: here is the spreadsheet.

You learn something new every day- Logon Type 0

Eric Fitzgerald — Tue, 26 Feb 2008 23:49:00 GMT

Today I encountered something new in the logon event- I thought that was old hat and I knew all there was to know about that but I guess I was wrong.

The logon event (528/540 prior to Windows Vista, 4624 in Vista and Windows Server 2008) has a field called a Logon Type. This is a code that is passed into the logon API that tells the authentication system in Windows which policy to check the logon against. Windows has separate policy checks for network logons, interactive logons, etc., so that you can allow users to access a system in some ways but not in others.

The logon type code is, in C/C++ parlance, an enumerated value- it's an ordered list of numeric values, each with an associated name, and these are defined in a publicly available file in the source code (ntsecapi.h). In the source code, the values are always referenced by name.

Today on one of the internal aliases someone actually found a logon event with a logon type of 0- I have never personally seen one of these before and 0 is not defined in the SECURITY_LOGON_TYPE enumeration, so I would have assumed that it was a bug- but it turns out that we are aware of this case and use it occasionally for system logons.

So there you are.

I always wondered who Björn was...

Eric Fitzgerald — Fri, 18 Jan 2008 01:47:00 GMT

OK here's something I just remembered today. I may be the last person who remembers this so it's important that I record this somewhere.

In the RTM bits of Windows NT 4.0, for the German language release only, someone snuck in a string resource into the auditing message file. I'm guessing that it was one of our localization engineers, but I don't know- I was over in the support side of things at the time. I stumbled across the message one day while looking at source code.

Here's Björn's momentous message: "Björn grüßt den rest der welt". Basically Björn says hi to everyone. He's a friendly guy.

This is string resource zero in the message table resource- it's not a code resource, it's properly formed and it's not used by the code anywhere. You would not know it exists unless you slog through source code (like me) or use a hex editor or string dumper to analyze binaries AND happen to be so bored that you pull out an NT 4.0 RTM German CD and examine msaudite.dll. NT4 RTM CD's are pretty rare, btw, because we replaced them with slipstream SP1 CD's very shortly after release.

If I remember correctly somebody else came along in a later service pack and changed Björn's name to their own (maybe it was Ulli? I can't remember and I'm too lazy to find the source- it requires a lot of effort to dig that far back). I do remember that shortly thereafter there was a huge Easter Egg crackdown here at Microsoft probably brought to a head by the Excel 97 Flight Simulator. Björn's message of goodwill to mankind was erased forever.

I did a search using the Officially Santioned Search Engine and the other one too; evidently the internet has forgotten Björn's message. But I still remember, Björn.

Anyway I thought you might like this bit of arcana. If you are bored, have a hex editor and a German NT4 CD, knock yourself out...

Why does Windows XP generate so many logon failure events?

Eric Fitzgerald — Sat, 10 Nov 2007 02:23:00 GMT

I got the question last week, why there are so many logon failure events on Windows XP when it is not domain joined.

The short answer is, by design. (Yes, bad design.)

The longer answer is that the shell team is working around the fact that there is no "tell me if this user account has a blank password" API.

When in a workgroup (not domain joined), Windows XP displays a welcome screen that has little pictures (called "tiles") for each user who is permitted to log on to the computer.

The shell team wanted the experience that when you click on a tile, that you will immediately be logged on if your password is blank (we have good data that a large percentage of home users have blank passwords). They only want you to be prompted for a password if you actually have a password. Fair enough, and it also helps with accessibility for people for whom typing is challenging.

The XP Welcome Screen, when it is initialized each time it is to be displayed, attempts to log on each user for which a tile will be displayed, using a blank password. Users with non-blank passwords will cause failures in this case (other users will cause logon success events followed by logoff success events). [2007-11-21 correction]

The Welcome Screen uses the result of these logon attempts to decide whether to display a password box when you select a user's tile. If the user has a blank password, they will be logged on instead of being prompted for a password.

Why are they logging on the account? Well it turns out to be the easiest way to tell if your password is blank. We don't have a "is your password blank" API- that would be a security disaster- and we would prefer that the shell team not go mucking about in the SAM, retrieving hashes and computing the blank password hash for each account so that it could compare them.

I asked for this behavior to be changed prior to XP's release. Specifically I asked that the blank password check be moved from Welcome screen initialization to tile selection- this would still cause logon failures but many fewer of them. I was declined. I asked for fixes to it in SP1 and SP2 and was declined. At this point we will not be revisiting this "feature"; the Welcome Screen was redesigned to eliminate this problem.

The shell team who designed the Welcome Screen did not feel that auditing was a common scenario for workgroup machines, and I didn't (and still don't) have any business case to dispute that.

List of Windows Server 2003 Events

Eric Fitzgerald — Fri, 12 Oct 2007 21:45:00 GMT

So a long time ago, back in my days of providing technical support for Windows NT 4.0, I published "Security Event Descriptions". This article was the "schema" so to speak, for the Windows NT 4.0 security event log events.

Technically Windows events are not schematized until Windows Vista; or put another way the schema is implicit based on the instrumentation in the code- since the event is raised by some function in the code, the "schema" could be interpreted as the parameter order in the call to that function.

Anyway security monitoring types love that article, but I hate it. It's just better than nothing. It doesn't state which events map to which audit policy categories. It does tell you whether the event is a succss or failure event but it doesn't alert you to the cases where the same event is used for success and failure (e.g. event 560).

When Windows 2000 came around and we added two new audit policy categories (DS Access and Account Logon [which was a huge naming blunder]), I wrote an article for the Windows 2000 security events. However it was so large I broke it into two articles.

I didn't write an article for Windows Server 2003. At first I didn't think it was necessary because we propagated all the WS03 events to the Technet Events & Errors Message Center web site. I wrote custom content for the top 30 or so events by volume of searches

(On a side note, did you ever wonder what happens when you click the "More Information" link at the bottom of the Event Viewer event description? We send the event source, event ID, OS version and so forth to the Technet E&E site and display the content that is returned. We count the number of hits for each OS Version/Source/Event ID combination and then our writing teams pester the component owners to populate that content.)

Anyway, I was making excu^h^h er, explaining why I didn't write the KB articles for Windows Server 2003 security events. So I thought the E&E message center would be all that anyone needed. It didn't strike me as that important that you had to have seen the event (or at least know it exists) before you could use the site. However since then I have received a large number of requests for the event definitions, mainly from people who were creating security event management solutions.

So here's what I have for you, courtesy of Ned, one of the audit log posse here at Microsoft. If you want a complete list of WS03 security events, then I suggest you look at chapter 4 of the Windows Server 2003 Security Guide. This documents the event IDs of all the security events on Windows Server 2003. Plus, it groups them by policy category, in case you ever wanted to know what you are in for if you enable one of the categories for audit. If you want the layout of the event (what data is in the description field, and in what order) then just look for that specific event on the Technet E&E site or click the link in the bottom of the event description in Event Viewer.

I've already described how the Vista and Windows Server 2008 (and subsequent releases) event systems are self-documenting, so I won't go into that further here.

One last tip: If you own Microsoft System Center Operations Manager 2007, then you can search for a file called EventSchema.xml on the media. It is an XML document that describes one possible normalization all the security events from Windows 2000 forward, and the semantic content of the normalized events.

2007-10-31 UPDATE: There is also an event-id-to-audit-policy-category map here.

Documentation on the Windows Vista and Windows Server 2008 Security Events

Eric Fitzgerald — Wed, 01 Aug 2007 00:36:00 GMT

I'm hearing lots of complaints that we don't have KB articles on these yet. Doriansoft has a blog post complaining that the "add 4096" rule doesn't work because we collapsed the logon events into a single success event and failure event (from 2 success events [528, 540] and 10 failure events [529-537, 539]).

Well, In Vista and beyond the event log is self-documenting. From an elevated command prompt (one with admin privileges), type the following:

wevtutil gp Microsoft-Windows-Security-Auditing /ge /gm:true

This example dumps only the 360 or so unique security event messages (publisher=Microsoft-Windows-Security-Auditing); other publishers can be enumerated with the ep switch of wevtutil.

Event messages can be formatted as XML using the /f switch, see the command-line help.

As a side note, this is, in slightly different format, the same information we publish in the KB, and a KB article is in the works.

Why did we renumber the events? As explained in my earlier post, we changed the internal detail of each event so much (to improve understandability, readability, consistency, etc.) that we would have broken essentially all existing automation anyway. By renumbering the events we made the automation break in as obvious a way as possible, and also made it as clear as possible that THESE ARE DIFFERENT EVENTS.

The "add 4096" rule is not meant to imply that the events are the same, but rather allows you to find the new equivalent event, if you have knowledge of the old event. Simply renumbering your automation will not make it work. It's a mental aid for you, the Windows security professional.

[2007-10-12 Update: changed tags]

The Trouble With Logoff Events

Eric Fitzgerald — Tue, 08 May 2007 23:37:00 GMT

A lot of you guys probably are using your SEM/SEIM systems to record logon and logoff activity without much of a second thought.

I just thought I'd bring one problem to your attention.

Logoff events are not strictly reliable.

From an engineering sense they are deterministic. However like many audit events, if you don't really think about how they work you might make assumptions that aren't correct. And you know what they say about assumptions...

Anyway, here's the problem. There is nothing that requires a client to notify you when the client decides to stop using your services. So for network logon sessions, the "logoff" event often just means "I got tired of waiting with reserved resources allocated for the client, so I reclaimed the resources. I'll give the client more resources if they come back (and can authenticate)". In other words- timeout.

You cannot, with protocols, force a client to notify you that they're done. Nice clients will if they can. Sometimes they physically can't notify you (this could be what we used to call the "backhoe and a beer" problem in my years in product support that is completely beyond the client's control). Sometimes they just choose not to notify you. I myself have designed software which just tore down the network connection when done or at the first sign of trouble, and started over again from scratch, rather than go through sophisticated "goodbye" or "fault" semantics. A robust server can handle the situation and will notice fairly quickly, reclaiming any reserved resources and generating any necessary audit trail. However I have seen software that has such expensive connection set-up that they hang on to connections for dear life long after everyone else would have turned out the lights and gone home. The funny thing is that half the time they don't realize that their client crashed, lost its state (that they were depending on for reconnection) and rebooted, and has reconnected with a new session. But I digress.

For interactive logon sessions, there is no guarantee of a logoff event either. There is no law of physics that forces a logoff audit if I pull the power cord out while I'm plugged in.

Plus, I've talked about token leaks before haven't I? Maybe not?

Windows logon events technically mean that we have created a data structure called a logon session. Associated with a logon session are one or more data structures called tokens. Each token has a number associated with it called a reference count, which is just a count of how many processes are using it at any given time. The reference count starts at 1 and goes up whenever a new process starts and down when the process terminates. It also goes up when a process specifically asks for a reference to a token and goes down when the process releases that reference. When the last process (your shell program, Explorer) releases its reference to your token, the token's reference count drops to zero. When the reference count drops to zero we destroy the token and the logon session associated with the token; the logoff event means the logon session was destroyed. For network logons we use a thread token that is given back to the service that asked to log you on; that token is usually assigned to a thread that does work on your behalf. It's all a little more complex than this in real life but this is basically how it works.

Anyway many applications, particularly server applications, request references to tokens, and then forget to release the references. This causes the reference counts to never drop to zero, and prevents us from generating the logoff event as a result.

To work around this we added the "Begin logoff" event (551) in Windows Server 2003, which can be interpreted as a logoff event, but this doesn't cover all cases. There are still some cases where logoff events are not generated due to poorly behaving applications. We fix all known instances of this in the operating system before we release Windows, and we test it rather thoroughly, but we can't promise that your applications will not leak tokens. If you encounter this you can troubleshoot by isolating each application until the token leak goes away, and then working with that application vendor.

Eric

How are object access events generated?

Eric Fitzgerald — Thu, 26 Oct 2006 20:21:00 GMT

I wrote this as an answer for Tom, who emailed me, but I thought I'd share it with everyone.

There are 7 events associated with object access auditing in Windows:

560 is the "open handle" event. It is logged when an app asks for access to an object (via a call like CreateFile). An access check is performed against the DACL (discretionary access control list == permissions) and an audit check is performed against the SACL (system access control list == audit settings). If the result of the access check matches the result of the audit check, an audit is generated- for successful accesses, the audit records the accesses that were granted, and for failures, the audit records the accesses that were requested. If the access check was successful, then a handle is returned to the calling program.

There is no event 561. I don't know why, maybe we'll use it in the future for something cool we haven't thought of yet.

562 is the "close handle" event. It is logged when an app disposes of an existing handle (how it got the handle is described above).

563 is the "open handle for delete" event. It works EXACTLY like event 560, and is logged only for files and only when the CreateFile API is called with a special flag that says "This is going to be a temporary file, delete it when I close the handle".

564 is the "delete" event. It works EXACTLY like event 562, but it is logged in conjunction with event 563 rather than event 560. Note that depending on how the object was deleted, you might get a 560-562 pair or a 563-564 pair. The former are much more common.

565 and 566 are application and AD access audit events. They record the actual accesses that were performed on the application-specific object or on the AD object. There are no handle semantics for these events.

567 is the "operation audit" event. It first exists on Windows XP. Once a handle to an object is opened (event 560 or 563), 567 is generated the first time an audited access is performed on an object.

Now let's put this together.

Scenario 1: Notepad is used to open an existing text file.

Notepad calls createfile("filename.txt"). Access check is performed, not opening for delete--> generate event 560 and list the accesses notepad was given (== what it asked for). Notepad is a well-behaved app and only asks for what it intends to use: GENERIC_READ (==read_control + read_data + read_attributes). Notepad reads the file (event 567 for "read_data") and closes the handle (event 562).

Scenario 2: Word is used to open an existing Word document.

Word has funny file i/o semantics. You've probably noticed that it generates files with silly names like "~ocument1.doc" and "~wrdf7.tmp". If you were to watch it very carefully with a program like FileMon from SysInternals, you'd notice that what Word does is:

1) Copy the file with a new name

2) Creates one or more temporary files for doing some operations (I don't know exactly what for)

3) Update the metadata in the original file to indicate it's locked for editing

4) Operate on the copy

And at save it:

5) Deletes the original file

6) Renames the working copy with the original name

7) Deletes the temporary working file(s)

The audit trail looks much more unusual:

You'll see 560 for the original file (open handle with all accesses), 560 for the copy (if there's an object-inherit SACL on the directory), 560 for the temp file, 567 (read data + write data) for the original file (reading the contents to write to the temporary file, writing metadata to the original file), 567 for the copy (write data), 567 for the temp file (???), and possibly more 567 events as it accesses the files. At the end when you save you see a similar mess as it cleans up. It can vary a little depending on what you do in Word.

You might ask, “Well, Eric, why don’t you just get rid of all that junk and just log an event that says what Word did?”.

Good question. As I mentioned in my post on “Trustworthiness in Audit Records”, the only practical way to do that would be to instrument Word for audit, and then the audit trail would be exactly as reliable as the user using Word, because if Word can write to the audit trail, and Word is running in the user’s context, then the user can write to the audit trail.

Now, we CAN improve things. In fact we did for Vista. Most people other than developers and Common Criteria evaluators don’t care about handle open/close audit events. So we made those harder to turn on in Vista, and we improved the “operation” audit event (was id 567, now it’s 4663 in Vista) so that it can stand alone. So by default when you turn on object auditing, you don’t see who requested access to objects, you see who performed access on objects. This is a huge step in the right direction, IMO.

There's a good technical discussion of access check & audit here. It’s a little dated- it pre-dates event 567 in XP- but it is still accurate.

I suggest that you read the whole "access control" section, but at the very least, read the 2 pages in this section on "access check" and "audit generation".

Eric

[2008-09-04 Updated link]

Quick Overview of Object Access Auditing in Windows

Eric Fitzgerald — Wed, 08 Mar 2006 01:16:00 GMT

A lot of people are unhappy with object access auditing on Windows, because what they want to know is "who touched the object and what did that person do", but what Windows auditing tells you is actually "who touched the object and what did they ask for permission to do". The distinction is subtle, but if you are interpreting object access events as recording what changes were made to objects, then you're probably misunderstanding what the log is saying.

To that end, here's a brief overview of Windows Object Access auditing.

On all OS's since Windows NT 3.1 up to and including Windows Server 2003:

Event 560 is recorded when an attempt is made to open a handle an object, and the object has a System Access Control List (SACL) which matches the access attempt.

For successful accesses, the granted access mask is compared to the SACL for Access Control Entries (ACEs) which match the token used to request access, and if there is a match, the granted access mask is recorded.
For failed accesses, the requested access mask is compared to the SACL for ACE entries which match the token used to request access, and if there is a match, the requested access mask is recorded.
For more detail on access check and audit generation, read this:

Event 562 is recorded when a previously opened handle is closed.
Event 563 is recorded in the same manner as event 560, but when the object is a file opened with the FILE_FLAG_DELETE_ON_CLOSE flag.
Event 564 is recorded when a file handle opened for delete, is closed, and therefore the file is deleted.

Note that event 560 does not record what was done to the object, only what accesses were requested to the object. This is an important distinction.

On Windows XP and Windows Server 2003 a new feature "Operation-Based Auditing" was added:

Event 567 is recorded for the first instance of a specific access being performed against an open handle. The event records the access(es) that were performed against the handle.

Event 567 is only recorded for the first instance of any access against a given handle- if an application opens a file and writes to it a hundred times, only one WRITE_DATA event will be generated. If the same handle is used for a different access, then a new event will be generated with the new access. If more than one access is performed against a handle at the same time, the operation audit will include all accesses that were performed at that time.
Event 567 does not record the object name; it's necessary to correlate event 567 with the most recent event 560 (where 567.handle_id==560.handle_id) to determine the object name.
Event 567 does not record the results of changes to objects; that is, it doesn't record before & after values.
Due to a bug, remote accesses to files (via shares) do not cause event 567 until Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1.

On Windows Vista:

The event id numbers of all these events change by +4096. That is, 560 becomes 4656, 567 becomes 4663, etc.
Event 4663 (previously 567) records the object name; handle id correlation is no longer required.
For registry and DS objects, the old and new values of changed objects are recorded when practical.
Audit policy allows auditing to be enabled on a per-object-type (file, registry, etc.) basis vs. all-or-nothing.
Audit policy allows handle-based auditing to be disabled and only operation audits (event 4663) to be generated.

That's all for now! As always, comments are welcome!

Privilege Use- what do we audit, and when?

Eric Fitzgerald — Tue, 06 Dec 2005 03:06:00 GMT

Odd thing today- I got two questions about the obscure "FullPrivilegeAuditing" registry setting- so I thought I'd post my answer. Some of this is not new, I posted on the Windows Server 2003 SP1 changes to auditing a while back.

Events ID 577 and 578 are governed by the Privilege Use audit category. All privileges except the following are audited by these events:

ChangeNotifyPrivilege
AuditPrivilege
CreateTokenPrivilege
AssignPrimaryTokenPrivilege
DebugPrivilege
SystemtimePrivilege (only suppressed for services, and only on Windows Server 2003)
BackupPrivilege
RestorePrivilege

With FullPrivilegeAuditing enabled audit will only be suppressed for these privileges:

ChangeNotifyPrivilege
AuditPrivilege
CreateTokenPrivilege
AssignPrimaryTokenPrivilege
DebugPrivilege
SystemtimePrivilege (only suppressed for services, and only on Windows Server 2003)

Prior to Windows Server 2003 SP1, Windows generated audit event 576 at logon if the account held any of these privileges (notice that it's the same list that is used for FullPrivilegeAuditing, by default- no coincidence- same data structure). The theory of operation was that event ID 576 recorded privileges held at logon which did not cause the generation of privilege use audits under normal usage circumstances.

ChangeNotifyPrivilege
AuditPrivilege
CreateTokenPrivilege
AssignPrimaryTokenPrivilege
BackupPrivilege
RestorePrivilege
DebugPrivilege

Starting with Windows Server 2003 SP1, these privileges cause event 576. The new theory of operation is that event ID 576 records privileges which are "administrator-equivalent"- privileges which can either be used to elevate to administrator, or to compromise the audit trail. In other words, we re-purposed an event that no one cared about.

AssignPrimaryTokenPrivilege
AuditPrivilege
BackupPrivilege
CreateTokenPrivilege
DebugPrivilege
EnableDelegationPrivilege
ImpersonatePrivilege
LoadDriverPrivilege
RestorePrivilege
SecurityPrivilege
SystemEnvironmentPrivilege
TakeOwnershipPrivilege
TcbPrivilege

In Windows Server 2003 RTM, Windows generates event ID 576 if either the Logon/Logoff category or the Privilege Use category is enabled. In Windows Vista, it's a Logon event only (in the "Special Logon" subcategory), and no longer associated with the Privilege Use category.

Why don't I see the workstation name in logon events?

Eric Fitzgerald — Tue, 09 Aug 2005 23:19:00 GMT

Top reasons:

1. In NTLM logons, it's subject to spoofing. There exist hacking tools which improperly populate the workstation field of the logon request. I don't know if this is intentional or not.

2. There is no way to carry this information in LDAP requests; AD logon events will never have the workstation name.

3. As discussed in a previous post about account logon events, there's not a standard way for us to carry this information in a Kerberos ticket request. There's no place for us to put it in the Kerberos ticket without breaking compatibility.

4. Reverse lookup (DNS or NetBIOS) is unreliable and insecure, and not configured in many locations.

Eric

Deciphering Account Logon Events

Eric Fitzgerald — Fri, 05 Aug 2005 04:03:00 GMT

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: http://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:

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.
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.
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

Events 528 and 540

Eric Fitzgerald — Fri, 10 Dec 2004 04:59:00 GMT

Logon events.

Event 528 and Event 540 are the Logon events. Event 528 is for all logons except "network" logons. "Network" logons are SMB/Microsoft-DS logons (i.e. connecting to a share). RDP, IIS, FTP logons, etc., are event 528 even though credentials may have come from over the network. All event 540's are logon type 3.

For Kerberos logons, the workstation field might not be filled out- the Kerberos ticket request messages don't have a field where we can carry this information and authentication of the user account is not based on the machine's TGT, so to the KDC, the workstation just looks like an IP address.

Not every code path in Windows Server 2003 is instrumented for IP address, so it's not always filled out.

"Transited services" is part of our S4U delegation mechanism.

Here's the description from http://www.microsoft.com/technet/support/ee/result.aspx?EvtSrc=Security&EvtID=528&ProdName=Windows+Operating+System&LCID=1033&ProdVer=5.2

Message:

Successful Logon:
User Name: %1
Domain: %2
Logon ID: %3
Logon Type: %4
Logon Process: %5
Authentication Package: %6
Workstation Name: %7
Logon GUID: %8
Caller User Name: %9
Caller Domain: %10
Caller Logon ID: %11
Caller Process ID: %12
Transited Services: %13
Source Network Address: %14
Source Port: %15

Explanation

A logon session was successfully created for the user. The message contains the Logon ID, a number that is generated when a user logs on to a computer. The Logon ID is unique to that logon session until the computer is restarted, at which point the Logon ID may be reused. The Logon ID can be used to correlate a logon message with other messages, such as object access messages.

For logons that use Kerberos, the logon GUID can be used to associate a logon event on this computer with an account logon message on an authenticating computer, such as a domain controller.

This message includes the user name and the domain information for the user account that logged on, the name of the logon process that logged the user on, the type of authentication credentials that were presented, and a logon GUID (globally unique identifier).

This message also includes a logon type code. The logon type code indicates the manner in which the user logged on. The following table explains the logon type code:

Logon type	Logon title	Description
2	Interactive	A user logged on to this computer at the console.
3	Network	A user or computer logged on to this computer from the network.
4	Batch	Batch logon type is used by batch servers, where processes might run on behalf of a user without the user's direct intervention.
5	Service	A service was started by the Service Control Manager.
7	Unlock	This workstation was unlocked.
8	NetworkCleartext	A user logged on to a network and the user password was passed to the authentication package in its unhashed (plain text) form. It is possible that the unhashed password was passed across the network, for example, when IIS performed basic authentication.
9	NewCredentials	A caller (process, thread, or program) cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but it uses different credentials for other network connections.
10	RemoteInteractive	A user logged on to this computer remotely using Terminal Services or a Remote Desktop connection.
11	CachedInteractive	A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.

The Workstation name field specifies the NetBIOS name of the remote computer that originated the logon request. If no information is displayed in this field, either a Kerberos logon attempt failed because the ticket could not be decrypted, or a non-Windows NetBIOS implementation or utility did not supply the remote computer name in the logon request.

User Action

No user action is required.