Windows Security Logging and Other Esoterica : HowTo

Minimizing Directory Service Audit Event Noise

Eric Fitzgerald — Fri, 05 Sep 2008 00:51:00 GMT

I've written before on noise reduction in the Windows security event log. I've also written to describe how object access auditing works. But, I still get questions on how to reduce noise from object access events. The other day I got that question, specific to Directory Service objects, on an internal discussion list so I thought I'd clean up the answer a bit and share it with the world. In general the same is true for any type of object, although there are a few more knobs to control for DS objects.

Object access audit is generated when the system access control list (SACL) on the object matches the access that was performed on ALL of the following conditions:

Object - the object that was accessed must have either an explicit or inherited SACL. The access performed is compared against the ACEs in that SACL.
Success or failure of activity - every audit access control entry (ACE) in a SACL will be either of type AUDIT_SUCCESS or AUDIT_FAILURE. The access performed must match the access type of the ACE for the rest of the ACE to be considered.
User account - the accessing user's token is compared against each ACE matching the access type. If the user, or a group the user belongs to, matches the SID in the ACE, then an audit might be generated.
Access - the access being performed must match the audited accesses in the access mask in an otherwise matching ACE.

The specific auditing algorithm is discussed here.

So the way to reduce the number of audit events (566 on Windows Server 2003, 4662 on Windows Server 2008, or one of the new DS Change events on Windows Server 2008) is to cause one or more of those conditions to fail, except in the specific cases that you care about.

The SACL which will generate the most audit events is "Everyone:Success & Failure:All accesses" on the domain head with OI,CI (object inherit & container inherit flags) for all object types. This SACL matches all of the above conditions in all cases. (Incidentally I think that this is pretty close to the default SACL- with the exception of failures- for Windows 2000 Active Directory installations, and SACLs are not updated when DCs are upgraded from version to version. Windows Server 2003 has much more conservative SACLs for new installations of AD.)

To reduce noise, I offer the following suggestions, addressing each of the above conditions:

Audit only the objects that you care about. User accounts and groups already are well-audited with "Account Management" auditing, so don't audit them with DS access. Perhaps audit OUs, or other DS objects. Use the Object Type and attribute type restrictions that you have in DS Access auditing. Also, in Windows Server 2008, you can affect auditing on a per-object basis by adjusting the SearchFlags attribute in the AD schema for the object. SACLs are more easily reversed so are probably a more acceptable method of controlling audit for most organizations.
Audit successful accesses only. Failed accesses are common and are NOT indicative of any security problem; in fact many failures are not even explicit requests by the user but are just normal requests made by the OS, and the OS will re-try with less access if the operation fails. In my experience failure auditing is primarily useful for troubleshooting, not for security.
Audit the "Everyone" group. Although this matches any user, you will not accidentally miss any accesses that you care about due to failing to audit a user account who has access to the objects in question. The only time that you would NOT audit "Everyone" is if you had an application or service account which was very noisy; in that case you'd need to create a group with all accounts EXCEPT the noisy accounts, and audit that group.
Audit only the accesses that you care about. Specifically, read accesses occur much more often (in my experience, a conservative estimate is about a 100:1 ratio) than write accesses. If you restrict your auditing to "write" type accesses (including change, delete, change permissions, create, etc.) then you will end up generating far fewer events. Auditing for read access is very noisy. If you must audit for reads, consider auditing fewer objects, perhaps only auditing reads on the container object instead of the objects in the container, or on one "interesting" object in any given container as a "canary".

Tracking User Logon Activity Using Logon Events

Eric Fitzgerald — Thu, 21 Aug 2008 02:32:00 GMT

I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.

As I have written about previously, this method of user activity tracking is unreliable. It works in trivial cases (e.g. single machine where the user doesn't have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection. If the user has physical access to the machine-- for example, can pull out the network or power cables or push the reset button-- and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user's presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).

There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away. The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement. Yes, if you know the SS delay then you could just work that into your calculations. However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that’s because your machine isn’t locked while the screen saver is being displayed). And the events don't tell you whether the workstation was locked or auto-locked so you don't really know whether to add in the screen saver delay factor. Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.

So the bottom line is, I don't advocate or recommend this method for tracking the time a user spends at the keyboard. If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented. You have been warned, I've beaten that dead horse enough I guess.

Given that you are disregarding all my contrary advice, how are you going to accomplish this?

First, we need a general algorithm.

Use time (for a given logon session) = Logoff time - logon time

Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.? We can use the BEGIN_LOGOFF event to handle token leak cases. We can use the shutdown event in cases where the user does not log off. And in case of crashes, the only event we can use is the startup event. Note that each of these introduces increasing levels of uncertainty.

Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)

This is good, but what about the time the workstation was locked?

Workstation lock time = unlock time - lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)

How about remote desktop & terminal server sessions, and fast user switching? You can connect and disconnect from logon sessions, during which time the user technically isn't using the computer.

Session idle time = session connect time - session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)

How about times when the machine was idle? We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.

Console idle time = (screen saver dismiss time - screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)

Putting all of this together and modifying our original formula, we get:

Use time (for a given logon session) =
   Logoff time - logon time
      - SUM(workstation lock time)
      - SUM(session idle time)
      - SUM(console idle time)

When we expand it, it is not quite so pretty:

Use time (for a given logon session) =
   ( (logoff time | begin_logoff time | shutdown time | startup time) - logon time )
      - SUM(unlock time - lock time)
      - SUM(session connect time - session disconnect time)
      - SUM(screen saver dismiss time - screen saver invoke time + screen saver delay)

You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session. The best correlation field is the Logon ID field, the next best are timestamp and user name. At various times you need to examine all of these fields.

Now, which event IDs correspond to all of these real-world events?

They are all found in the Security event log. The pre-Vista events (ID=5xx) all have event source=Security. The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.

512 / 4608 STARTUP
513 / 4609 SHUTDOWN
528 / 4624 LOGON
538 / 4634 LOGOFF
551 / 4647 BEGIN_LOGOFF
N/A / 4778 SESSION_RECONNECTED
N/A / 4779 SESSION_DISCONNECTED
N/A / 4800 WORKSTATION_LOCKED
* / 4801 WORKSTATION_UNLOCKED
N/A / 4802 SCREENSAVER_INVOKED
N/A / 4803 SCREENSAVER_DISMISSED

* prior to Windows Vista, there was no event for locking the workstation. Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7. These events had the same user name as the "original" logon session and were completely enclosed chronologically by the logon/logoff events for the "real" logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator. This makes correlation of these events difficult.

All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category. The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.

Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven't worked on a project that required this.

Eric

WEvtUtil Scripting

Eric Fitzgerald — Wed, 16 Jul 2008 19:13:00 GMT

If you haven't used wevtutil.exe to script event log tasks in Windows Vista or Windows Server 2008, you're missing out. The new tool makes getting events out of the log pretty easy, but the main thing is that it doesn't suffer from any of the drawbacks around getting field delimiting correct.

The tool's command to query events from a log is "qe", and takes a log name as a parameter.

If you want to specify a query expression, then you can use XPath with the /q switch. The easiest way to do this is to use Event Viewer to build a filter for just the events that you want, and then copy just the XPath expression out of the XML tab of the filter dialog in Event Viewer. Be careful to copy only the filter expression and not the XML that surrounds it.

Finally, the default output format of wevtutil is XML. However it dumps each event as XML, but does not include a root element- in other words it's not well-formed XML by default. To include a root element you need to include the /e switch and a root element name.

I put this all together in a batch file, with an example XPath filter that just gathers interactive logon events (event ID=4624, logon type=2). You can save this as a .cmd file and run it as an administrator on Vista or WS08 and it will pull up a list of your interactive logons in Internet Explorer (or your default XML handler application if you've changed the registration). It has to run as admin because it accesses the security event log.

If you're really good (better than me, which is not hard) you could write an XSL style sheet and put this into a report format.

Good luck!

@echo off

set outputfile=%temp%\interactive-logon-events.xml

if "%1" NEQ "" set outputfile=%1

REM The next command is all one line and has no carriage returns

REM The only spaces in the XPath are around the AND keywords

wevtutil qe Security /q:"*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Task=12544 and (EventID=4624)] and EventData[Data[@Name='LogonType']='2']]" /e:Events > %outputfile%

start %outputfile%

set outputfile=

Ned on Auditing

Eric Fitzgerald — Sun, 20 Apr 2008 06:14:00 GMT

I often talk about Ned, who is the current subject matter expert in Microsoft product support for the auditing feature in the US (Fadi is your guy in the Middle East and we have a couple of guys in Europe). Well, Ned has a blog and I thought I'd point you guys there. His recent posts on auditing include a description of how to deploy the special groups logon auditing feature with group policy.

ACS Event Transformation Demystified

Eric Fitzgerald — Thu, 28 Feb 2008 04:43:00 GMT

I've decided to start dumping my knowledge of ACS for posterity's sake. My first installment is here, and it's an excerpt from an external email I put together which describes how event transformation works on ACS.

Transformation is performed on the agent (using instructions provided at connect time by the collector) and on the collector. Transformation instructions are all stored on the collector in a file called EventSchema.xml which is in the AdtServer directory (%windir%\system32\security\adtserver). This file is pointed to in the collector’s registry and is read during startup of the collector service; failure to successfully read and parse this file at startup is a fatal error for the collector (the debug log will complain about parsing).

The collector reads EventSchema.xml and builds in-memory binary tables of event transformation instructions and event string types by OS version/event log/event source.

The collector (as explained elsewhere) also reads AcsConfig.xml to get its persistent state and configuration for all known agents, to know what logs/sources to collect for each agent/agent group, etc. This is all read into in-memory state for each agent.

At connect time, the agent sends version information- what the OS and agent version and service pack are, etc. The collector first looks in its in-memory agent state to see what configuration applies to the agent. Then it looks in its transformation tables and extracts the appropriate version-specific transformation instructions for the events that the collector is configured to collect from that agent. Then it packages these instructions and sends them to the agent.

The agent starts reading events, transforming them according to its instructions from the collector, and sending the transformed events to the collector. The collector finishes the transformation, services real-time subscriptions and loads the events into the database as appropriate.

If the agent encounters an event that is it configured to send (by log/source) but does not have transformation instructions for, then it simply builds a copy the event string for string and sends the copy of the event to the collector as an “unschematized” event. The collector will handle this event without problems but will not extract non-header user fields (no primary/client/target user fields) and will not add string type information.

I’ll take Windows Server 2003 (build 3790), Event Log: Security, Event Source: Security, Event ID: 644 as an example.

Here’s the WS03 schema for 644 (excerpt from %systemroot%\system32\security\adtserver\EventSchema.xml in the path “Schema\Log[@Name=’Security’\Source[@Name=’Security’]\Version[@MinBuild=’3790’]\Event[@SourceId=’644’]”).

</Event>

The instructions are all applied in order. “Call” instructions are executed agent-side; “Param” instructions are executed server-side.

These instructions can be translated as:

· Take string 1 from the original event and make it string 1 in the new event. It is of type “typeUserDn”.

· Take string 3 from the original event and make it string 2 in the new event. It is of type “typeComputerName”. Note that we are doing reordering here by appending original string #3 before original string #2. Nifty, eh?

· Take string 2 from the original event and make it string 3 in the new event. It is of type “typeTargetSid”.

· Take string 4 from the original event and make it string 4 in the new event. It is of type “typeClientUser”.

· Take string 5 from the original event and make it string 5 in the new event. It is of type “typeClientDomain”.

· Take string 6 from the original event and make it string 6 in the new event. It is of type “typeClientLogonId”.

· Take string 4 from the original event and treat is as a user name, and take string 5 from the original event and treat it as a domain name, look up the associated SID and make it string 7 in the new event. The new string is of type “typeClientSid”.

· Take string 3 from the new event, treat it as a SID, look up the user/domain name associated with it and append the user name as string 8 to the new event and the domain name as string 9 to the new event. String 8 is of type “typeTargetUser” and String 9 is of type “typeTargetDomain”.

See the reordering? Now here is an instance of the event with the original event data. If you’re not familiar with the XML, it’s the XML output of Crimson, the new eventlog service introduced in Vista/WS08, but this is a WS03 [pre-Crimson] machine; we're looking at a saved event log (evt) file.

<Channel>C:\Users\ericf\AppData\Local\Temp\SERVER34_SecEvts.evt</Channel>

<Computer>SERVER34</Computer>

</System>

<Data>user09</Data> // String 1 – user name

<Data>SERVER34</Data> // String 2 – looks like a machine name, confirmed by string 4

<Data>%{S-1-5-21-5998314728-109421381-169156293-611111}</Data> // String 3 – definitely a SID

<Data>SERVER34$</Data> // String 4 – definitely an account name (machine account)

<Data>CONTOSO</Data> // String 5 – looks like a domain name

<Data>(0x0,0x3E7)</Data> // String 6 – definitely a logon ID

<Data>-</Data> // String 7 – empty null string at the end of the event (ignored by ACS)

</EventData>

</Event>

When the event arrives at the collector, type information is applied, and then the user fields (typePrimary*, typeClient*, typeTarget*) are extracted from the string data section and the strings that are left are re-numbered starting at 1 (no reordering occurs).

Here’s a chart of what the event looks like at the various points in the system. The changes at each step are shown in red.

Original Event in Event Log		Client-Side Transformation at Agent		Server-Side Normalization (WMI/SQL output)
Field	Content Description (implicit)	Field	Content Description (implicit)	Field	Content Description (explicit)
		Client User		Client User	typeClientUser
		Client Domain		Client Domain	typeClientDomain
		Client Sid		Client Sid	typeClientSid
		Client Login Id		Client Login Id	typeClientLogonId
		Target User		Target User	typeTargetUser
		Target Domain		Target Domain	typeTargetDomain
		Target Sid		Target Sid	typeTargetSid
String01	typeUserDn	String01	typeUserDn	String01	typeUserDn
String02	typeTargetSid	String02	typeComputerName	String02	typeComputerName
String03	typeComputerName	String03	typeTargetSid	String03
String04	typeClientUser	String04	typeClientUser	String04
String05	typeClientDomain	String05	typeClientDomain	String05
String06	typeClientLogonId	String06	typeClientLogonId	String06
String07		String07	typeClientSid	String07
String08		String08	typeTargetUser	String08
String09		String09	typeTargetDomain	String09

To finish off a description of transformation, there are 7 transformation functions, each of which can optionally take 2 integers as parameters. Note that there is no “destination event” field specifier; all references are only to the original event. That’s because when constructing the destination event, any data added to the event is always appended- it is constructed from beginning to end- so the implicit destination field is “at the end of the event as it is now”.

Function	Parameter 1	Parameter 2	Description
AppendString	Reference to a string parameter in the source event in the event log	Unused	Appends the referenced string to the event which will be sent to the collector
AppendStringFromTable	Reference to a constant string in the statically defined <Strings> table (1-based) in the relevant Source\Version element in EventSchema.xml	Unused	Appends the referenced constant string to the event which will be sent to the collector
AppendProcessNameFromPid	Reference to a string parameter in the source event in the event log (source string is expected to be a numeric process ID)	Unused	Looks up the process image path name for the referenced PID and appends it to the event which will be sent to the collector
AppendTimeFromDatetime	Unused	Unused	Not Implemented/No Action
AppendSidFromNames	Reference to a string parameter in the source event in the event log (source string is expected to be a user name)	Reference to a string parameter in the source event in the event log (source string is expected to be a domain name)	Looks up the SID for the account represented by the specified user and domain names, and appends the SID to the event which will be sent to the collector
AppendNamesFromSid	Reference to a string parameter in the source event in the event log (source string is expected to be a security ID)	Unused	Looks up the user name and domain name for the account represented by the specified SID, and appends the user name and the domain name as separate strings to the event which will be sent to the collector
AppendNumber	Unused	Unused	Not Implemented/No Action

Out of range params cause the transformation instruction to be ignored and skipped. Non-integer params or other XML formatting/malformation problem (including non-UTF8 formatting) cause an EventSchema.xml parsing error at collector startup which in turn causes collector startup failure.

So that’s ACS transformation in a nutshell. I hope this helps you guys understand ACS functionality a little better.

Shortly I will finish my write-up on AcsConfig.xml but that is a simple file and not too hard to figure out if you are into experimentation.

Here are some cool things that you can try with the event schema file if you are adventurous:

1. Drop fields. We have modified eventschema.xml successfully to cause it not to collect certain fields (e.g. logon GUIDs) of certain events:

// try deleting a line here

// or, to preserve ordering of subsequent strings

// try replacing “AppendString” with “AppendStringFromTable (param1=1)”

2. Add an event source. Some caveats are:

· You must have a unique, well-formed GUID for the new source

· You have to get events of the new source into the log (try “AuthzReportSecurityEvent” from MSDN)

· You have to modify AcsConfig.xml to tell the agent(s) to collect the new source

NB I have used the C/C++ comment syntax throughout this post but note that ACS does not support either C/C++ nor XML style comments in the XML config files it uses

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

Auditing the Creation of Domain Controllers

Eric Fitzgerald — Thu, 03 May 2007 21:36:00 GMT

Special thanks to Raman in the Active Directory team for this one.

Ever want to audit the creation of new domain controllers in your environment? Yeah, me neither :-) However if you ever want to, here's how.

1. The default SACL on Active Directory should suffice. However, if you have changed the default SACL, here it is again, in SDDL:
S:(AU;SA;WDWOWP;;;WD)
(AU;SA;CR;;;BA)
(AU;SA;CR;;;DU) <-- this ACE is probably doing most of the work for you
(OU;CISA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
(OU;CISA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)

2. Enable DS Access audit policy for success events in the Default Domain Controllers policy.

3. Look for the following event 566 in your security event log (yours will differ slightly because this example comes from Longhorn Server):

An operation was performed on an object.

Subject :

Security ID: YOURDOMAIN\Administrator

Account Name: Administrator

Account Domain: YOURDOMAIN

Logon ID: 0x201d29

Object:

Object Server: DS

Object Type: domainDNS

Object Name: DC=yourdomain,DC=com

Handle ID: 0x0

Operation:

Operation Type: Object Access

Accesses: Control Access

Access Mask: 0x100

Properties: Control Access

{9923a32a-3607-11d2-b9be-0000f87a36b2} <-- this is the "DS-Install-Replica" control access right

domainDNS

Additional Information:

Parameter 1: -

Parameter 2:

Some notes:

1. There is no audit generated for the first domain controller in a new forest (there is no context within which to perform DS audting).

2. For the first domain controller in a new domain in an existing forest, you'll see a slightly different event:

DS Access: (here's the Longhorn version of the DS Access event, the Windows Server 2003 version [566] is very similar):

An operation was performed on an object.

Subject :

Security ID: MYDOMAIN\Administrator

Account Name: Administrator

Account Domain: MYDOMAIN

Logon ID: 0x3213d7

Object:

Object Server: DS

Object Type: crossRefContainer <-- when you see this

Object Name: CN=Partitions,CN=Configuration,DC=mydomain,DC=com

Handle ID: 0x0

Operation:

Operation Type: Object Access

Accesses: Create Child

Access Mask: 0x1

Properties: Create Child

{bf967a8d-0de6-11d0-a285-00aa003049e2}

Additional Information:

Parameter 1: CN=NEWDOMAIN,CN=Partitions,CN=Configuration,DC=mydomain,DC=com

^-- along with a new domain for the first time

Parameter 2: CN=NEWDOMAIN,CN=Partitions,CN=Configuration,DC=mydomain,DC=com

DS Change: (this is the new Longhorn-only DS Change event):

A directory service object was created.

Subject:

Security ID: MYDOMAIN\Administrator

Account Name: Administrator

Account Domain: MYDOMAIN

Logon ID: 0x3213d7

Directory Service:

Name: mydomain.nttest.microsoft.com

Type: Active Directory Domain Services

Object:

DN: CN=NEWDOMAIN,CN=Partitions,CN=Configuration,DC=mydomain,DC=com

GUID: CN=NEWDOMAIN,CN=Partitions,CN=Configuration,DC=mydomain, DC=com

Class: crossRef

Operation:

Correlation ID: {a991c256-d7f2-4654-bf68-76ef5ebe69b4}

Application Correlation ID: -

HTH

Determining Whether a User Logged on Using A Smart Card

Eric Fitzgerald — Tue, 06 Feb 2007 03:40:00 GMT

I get asked the question pretty regularly how to determine from the security log whether a user logged on using a smart card or not.

The short answer is, you can't be absolutely certain. The longer answer is, well, you can be pretty certain for the time being, especially if you're not running any non-Microsoft Kerberos code.

First you need to know that you can only log on using a smart card in Windows when you authenticate to a domain using the Kerberos protocol. There is a cached logon mechanism in Windows XP so you can log on using your smart card when a domain controller is unavailable but Windows will attempt to acquire domain credentials automatically for you, under the hood, when you log on this way, and you won't be able to touch any other machine on the network using domain authentication until you authenticate to the DC.

Now for you guys that are not Kerberos gurus, there are three phases to Kerberos authentication:

1. Authentication Service Request (AS-REQ) & Reply, where the client presents credentials to a KDC and obtains a ticket-granting ticket.

2. Ticket-Granting Service Request (TGS-REQ) & Reply, where the client presents a TGT to a KDC and obtains a service ticket.

3. Application Request (AP-REQ or just normal application traffic), where the client presents a service ticket to an application and requests service.

In Windows, #1 generates security event ID 672 on the DC (on Windows 2000 the failure event is 675 but in Windows Server 2003 the failure event is the same as the success event, 672). Event 672 records who requested the ticket, their IP address, etc., and also includes the kind of credentials they used, called the "patype" or "preauth type", short for "pre-authentication type". Preauth types are discussed in the Kerberos RFC, RFC 4120 in section 7.5.2.

In Windows, #2 generates security event ID 673 on the DC (on Windows 2000, the failure event is 676, in WS03, it's 673)

In Windows, #3 causes a logon event (528 or 540) on the machine that is accessed, if the "application" is the machine itself, that is to say that the "service" is "host\machinename".

OK, now that the background is out of the way, back to the question. How do I know if it was a smart card logon?

Well, as mentioned, the preauth type is listed in event 672. Smart cards use public keys for pre-authentication (patype = PKINIT, which is 14, 15, 16, or 17 we learn from RFC 4120). So if you see one of these preauth types in this event on the DC, you know that it was a smart card logon- WRONG! You know actually just that it was a PKINIT logon.

However, currently the only logons built into Windows that use PKINIT preauth type over Kerberos, are smart card logons. So for the time being you can make the assumption.

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!

Setting SACLs on Services

Eric Fitzgerald — Fri, 09 Dec 2005 20:46:00 GMT

Have you ever wanted a record of admin activity regarding service management? For example, who stopped one of your services?

Did you know that you can do this through auditing?

It's actually really easy. The "Security Templates" MMC snap-in allows you to author security templates which will set security descriptors (permissions and auditing) on service objects, as well as file system & registry objects.

The bad part is that if you only want to adjust auditing, and not permissions, you'll have to fine-tune the template file by hand. The good news is, it's easy.

Templates store security descriptors as SDDL. Service- and SCM-specific ACES are described here. The SDDL specific to service objects is described here.

Here's what a service security template looks like. I built this template by choosing Alerter in the list of services, adding it to my template, then I opened the template with notepad. The templates are stored in %windir%\security\templates.

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Service General Setting]
Alerter,4,"D:AR(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)S:AR(AU;SA;DCRPWPDTCRSDWDWO;;;WD)"

The DACL is shown in blue and the SACL is shown in Red. We'll make three changes. First, we'll make it apply to all services, not just alerter. Then, we'll remove the DACL so we can adjust the SACL without changing permissions. Finally, we'll adjust the accesses that are audited to only include accesses which actually change something. Here's the resulting template:

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Service General Setting]
*,4,"S:AR(AU;SA;DCRPWPDTCRSDWDWO;;;WD)"

After you finish your template, you can test it using secedit from the command line. If it gives you the results that you want you can import it into a group policy object using gpedit.msc.

As an added bonus, on Windows Server 2003 SP1 you can actually set the security descriptor on the Service Control Manager itself. As far as I know, you can only do this through script, not through security templates. Setting the SACL on the SCM would allow you to know, for instance, who is remotely managing services.

The command is:

sc sdset SCMANAGER <SDDL to assign>

You can display the security descriptor on the Service Control Manager with:

sd sdshow SCMANAGER

More detail is available here.

This won't work on Windows XP or Windows 2000, even if you copy the SC.EXE tool down.

Best regards,

Eric

2005-12-14 UPDATE: JBM pointed out that the ability to set the SACL on the Service Control Manager is an SP1 feature. Also note that most services have everyone:all accesses:failure SACLs by default since NT 4.0.

Multiple Events for Successful Account Creation

Eric Fitzgerald — Tue, 30 Aug 2005 02:49:00 GMT

Here is the pattern you should expect to see when creating a local account. For domain accounts, you may also see some DS Access events as the account is created and the various properties are set.

560 SAM_DOMAIN handle open for CreateUser access
632 Add user to global group "None" <--- see previous post for explanation
624 Create user account <--- this is the real thing
626 Enable account
642 Account change (password last set=now, UserAccountControl flags)
628 Password set
562 SAM_DOMAIN handle closed

560 SAM_USER handle open for write
642 Account change (set logon hours) <--- note that post-Windows-XP we have greatly enhanced the detail in this event.
562 SAM_USER handle close

560 SAM_USER handle open for write
642 Account change (User parameters flags, UserAccountControl flags)
562 SAM_USER handle close

560 SAM_USER handle open for write
642 Account change (set primary group id=513)
636 Account added to local group "Users"
562 SAM_USER handle close

Now the million-dollar question is, why so noisy?

The first answer is, because of the SAM events- almost 50% of these events are for the SAM itself. See my earlier post to find out how to disable those events. Of course the brute force way is to disable object access auditing ;-)

The next answer is, that there are several auditable activities occurring here, and that the way that we create accounts calls them serially instead of atomically in a transaction. This is probably to maximize code re-use inside SAM, but I'm just guessing there.

I'm working with the SAM team to see if I can improve this in the future, but for now you have an explanation of all these events.

Best regards,

Eric

Monitoring Active Directory Schema Changes

Eric Fitzgerald — Tue, 09 Aug 2005 01:25:00 GMT

As a follow-on to my last post, I want to relate how to monitor for Active Directory schema changes.

First you need to put SACLs on the schema. Remember to replace any existing SACLs, disable propagaion of the SACL from the parent, and force propagation to the subtree.

Using ADSI Edit, create an auditing ACE in the SACL as follows:
- Object to set SACL on: Schema (ex: CN=Schema,CN=Configuration,DC=yourdomain,DC=com)
  - Principal: Everyone
    - Type: Success
    - Accesses: Modify Permissions, Modify Owner, Create All Child objects, Delete, Delete All Child Objects, Delete Subtree
    - Scope: This object only
  - Principal: Everyone
    - Type: Success
    - Accesses: Write All Properties
    - Scope: This container and all child objects
  - Principal: Everyone
    - Scope: This object only
  - Principal: Everyone
    - Type: Success
    - Accesses: Reanimate Tombstones
    - Scope: This object only
  - Principal: Administrators
    - Type: Success
    - Accesses: All Extended Rights
    - Scope: This object only
  - Principal: Domain Users
    - Type: Success
    - Accesses: All Extended Rights
    - Scope: This object only

Next, you'll need to enable DS Access auditing in the Default Domain Controllers Policy.

To find schema change events in the log, look for security event 565 or 566, with an object name that contains "CN=Schema".

It's that easy!

The definitive reference for how to set up auditing in Active Directory, written by my friend & co-worker Arun, is in the following white papers:

Windows 2000 paper: http://www.microsoft.com/windows2000/technologies/directory/AD/AD_SecurityPt1.asp

Windows 2003 paper: http://www.microsoft.com/windowsserver2003/techinfo/overview/adsecurity.mspx

The SACLs described in the 2003 white paper are the defaults for new AD installations (where your AD started on a Windows Server 2003 machine). They are much less noisy than the Windows 2000 SACLs, and are specifically targeted at recording Active Directory configuration changes.

Eric

Monitoring Group Policy Changes with Windows Auditing

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

I spent some time a while back analyzing logs, figuring out what you can do with group policy auditing on Windows Server 2003. I did not test Windows 2000; I suspect that much of this applies but YMMV.

GP editing does leave an auditable trail of directory accesses and file accesses. Here is how to enable auditing for Group Policy, and how to interpret the results.

To get the audit trail from AD, you must do the following:
- Using AD Users and Computers, create an auditing ACE in the SACL as follows:
  - Object to set SACL on: domain (ex: contoso.com)
  - Principal: everyone
  - Type: success
  - Accesses: Create groupPolicyContainer Object, Delete groupPolicyContainer Object
  - Scope: This container and all sub-containers and objects
- Using AD Users and Computers, create an auditing ACE in a SACL as follows:
  - Object to set SACL on: domain (ex: contoso.com)
  - Principal: everyone
  - Type: success
  - Accesses: all "write" type accesses including deletes, but no "read" type accesses
  - Scope: groupPolicyContainer objects
- Enable Directory Service Access Success auditing in the Default Domain Controllers Policy.
To get the audit trail from the file system, you must do the following:
- Using Explorer, navigate to: \\<domainname>\sysvol\<domainfqdn>
  (ex: \\contoso\sysvol\contoso.com)
- Set the following SACL on the \policies directory in that location
  - Directory to set SACL on: \\<domainname>\sysvol\<domainfqdn>\policies
  - Principal: everyone
  - Type: success
  - Accesses: all "Write" accessess, but no "Read" accesses.
    Note: Do not audit Write Attributes or Write Extended Attributes
  - Scope: This container and all sub-containers and objects
- Enable Object Access Success auditing in the Default Domain Controllers Policy.

Here are the Audit records that are generated if you do this. The fields to pay special attention to are underlined. My comments are in red.

DS Access audit records.
  Whenever GPEdit.msc is opened when targeted at an existing group policy object,
  an audit record similar to the following will be generated. I have added notes in red,
  these don't appear in the log.

Type:  Audit Success
Event ID: 566
Time:  4/3/2005 7:39:13 PM
Source:  Security
Computer: ACSDEMO-COLL
Category: Directory Service Access
User:  CONTOSO\Administrator
Description:
Object Operation:
  Object Server: DS
  Operation Type: Object Access
  Object Type: %{f30e3bc2-9ff0-11d1-b603-0000f80367c1} (this GUID means that the object is of type groupPolicyObject)
  Object Name: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com
      (policy objects are always have GUIDs for common names- use GPMC to find the friendly name)
      (the Default Domain policy and Default Domain Controllers policy have well-known GUIDs; all others are random)
  Handle ID: -
  Primary User Name: ACSDEMO-COLL$ (primary user is always the machine, since DS runs as localsystem)
  Primary Domain: CONTOSO
  Primary Logon ID: (0x0,0x3E7)
  Client User Name: Administrator (client user is the user who made the change, being impersonated by DS)
  Client Domain: CONTOSO
  Client Logon ID: (0x0,0x2F6C8)
  Accesses: Write Property
  Properties: Write Property
     %{771727b1-31b8-4cdf-ae62-4fe39fadf89e}
     %{bf967a76-0de6-11d0-a285-00aa003049e2}
     %{f30e3bc2-9ff0-11d1-b603-0000f80367c1}
  Additional Info:
  Additional Info2:
  Access Mask: 0x20

Variations on DS Access Events
- For creation of group policy objects, event 566 is logged for the parent object, indicating the "Create Child" access, and one or more 566 events are generated for the new group policy container object as the objects' properties are initialized.
- For deletion of group policy objects, event 566 is logged for the policy object, indicating the "Delete" access.
File Access Audit Records
- When group policy objects are edited, there will be telltale traces in the file system audit trail on sysvol. The typical event will look like:

Type:  Audit Success
Event ID: 560
Time:  4/3/2005 7:39:14 PM
Source:  Security
Computer: ACSDEMO-COLL
Category: Object Access
User:  CONTOSO\Administrator
Description:
Object Open:
Object Server:  Security
Object Type:  File
Object Name:  C:\WINDOWS\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\GPT.INI

What file name you see here depends on which settings were edited. Note that for security policy GPEdit works on a temp file and then writes the original:
C:\WINDOWS\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.tmp
C:\WINDOWS\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
I've described most of the file names you're likely to see, further down in this post.

Handle ID:   2600
Operation ID:  {0,1741006}
Process ID:   4
Image File Name:
Primary User Name: ACSDEMO-COLL$
Primary Domain: CONTOSO
Primary Logon ID: (0x0,0x3E7)
Client User Name: Administrator
Client Domain:  CONTOSO
Client Logon ID:  (0x0,0x1A8F5C)
Accesses:   READ_CONTROL
      SYNCHRONIZE
      ReadData (or ListDirectory)
      WriteData (or AddFile)
        AppendData (or AddSubdirectory or CreatePipeInstance)
        ReadEA
        WriteEA
        ReadAttributes
        WriteAttributes
Privileges:   -
Restricted Sid Count: 0
Access Mask:  0x12019F

We cannot audit exactly which setting changed. I have bugged the group policy team any number of times about this but I think due to resource issues this won't improve much in the forseeable future. The bottom line is that GPEDIT.MSC edits the policy file directly; there's no intervening trusted service to instrument for audit. In a future release of Windows I hope to fix this.

However, you can narrow changes down to settings groups [security vs. non-security] depending on the file that was touched on sysvol. If security policy is touched, then GptTmpl.inf will change. If the list of adms used to construct the policy changes, admfiles.ini will change. If the registry-based settings outside security policy change, then registry.pol will change.

Here's my brief key of which directory\file names refer to which settings group. Given the directory structure for a single policy (\\domain\sysvol\domain.fqdn\policies\{policyguid}\):

In the root of the policy directory is a GPT.INI file containing the version number of the associated GPO. Every time GPEdit is used to edit this object, GPT.INI can be expected to change.
- \Machine - This directory includes a Registry.pol file that contains the registry settings to be applied to computers. When a computer boots up and establishes its secure channel to a domain controller, this Registry.pol file is downloaded and applied to the HKEY_LOCAL_MACHINE portion of the registry. The Machine folder can contain the following subfolders (depending on the contents of the GPO):
  - \Scripts\Startup - Contains the scripts that are to run when the computer starts up.
  - \Scripts\Shutdown - Contains the scripts that are to run when the computer shuts down.
  - \Applications - Contains the application advertisement files (.aas files) used by the Windows installer.
  - \Microsoft\Windows NT\Secedit - Contains the Gpttmpl.inf file, which includes the default security configuration settings for a Windows Server 2003 domain controller.
  - \Adm - Contains all of the .adm files for the GPO. The adm files are the files which control the Group Policy editor user interface.
- \User - This directory includes a registry.pol file that contains the registry settings to be applied to users. When a user logs on to a computer, this registry.pol file is downloaded and applied to the HKEY_CURRENT_USER portion of the registry. The User folder can contain the following subfolders (depending on the contents of the GPO):
  - \Applications - Contains the advertisement files (.aas files) used by the Windows installer. These are applied to users.
  - \Documents and Settings - Contains the Fdeploy.ini file, which includes status information about the Folder Redirection options for the current user's special folders.
  - \Microsoft\RemoteInstall - Contains the OSCfilter.ini file, which holds user options for operating system installation through Remote Installation Services.
  - \Microsoft\IEAK - Contains settings for the Internet Explorer Maintenance snap-in.
  - \Scripts\Logon - Contains all the user logon scripts and related files for this GPO.
  - \Scripts\Logoff - Contains all the user logoff scripts and related files for this GPO.

The User and Machine folders are created at install time, and the other folders are created as needed when policy is set.

Here is some additional information on the structure of group policy: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/eb0042e3-699b-4c49-abcc-e3526dbecc0e.mspx

I can't solve all your group policy monitoring woes, I just wanted to document what you'll see in the logs. There are at least three products on the market that can monitor which specific settings changed that you can buy if you need more functionality than what I've described here.

Best regards,
Eric