Archive

Archive for the ‘HowTo’ Category

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Auditing Changes to Audit Policy

July 16th, 2010 No comments

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

Auditing Changes to Audit Policy

July 16th, 2010 No comments

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

Auditing Changes to Audit Policy

July 16th, 2010 Comments off

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

Auditing Changes to Audit Policy

July 16th, 2010 No comments

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

Minimizing Directory Service Audit Event Noise

September 5th, 2008 No comments

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:



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

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

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

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



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

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

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

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

 

Categories: HowTo, Tips Tags:

Minimizing Directory Service Audit Event Noise

September 5th, 2008 No comments

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:



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

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

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

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



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

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

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

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

 

Categories: HowTo, Tips Tags:

Minimizing Directory Service Audit Event Noise

September 5th, 2008 Comments off

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:



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

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

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

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



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

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

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

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

 

Categories: HowTo, Tips Tags:

Minimizing Directory Service Audit Event Noise

September 4th, 2008 No comments

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:



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

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

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

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



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

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

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

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

 

Categories: HowTo, Tips Tags:

Tracking User Logon Activity Using Logon Events

August 21st, 2008 No comments

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

Categories: HowTo, Rants, Tips Tags:

Tracking User Logon Activity Using Logon Events

August 21st, 2008 Comments off

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

Categories: HowTo, Rants, Tips Tags:

Tracking User Logon Activity Using Logon Events

August 21st, 2008 No comments

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

Categories: HowTo, Rants, Tips Tags:

Tracking User Logon Activity Using Logon Events

August 20th, 2008 No comments

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

Categories: HowTo, Rants, Tips Tags:

WEvtUtil Scripting

July 16th, 2008 No comments

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


 


REM (C) 2008 Microsoft Corporation


REM All Rights Reserved



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=



 

Categories: HowTo, Tools Tags:

WEvtUtil Scripting

July 16th, 2008 No comments

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


 


REM (C) 2008 Microsoft Corporation


REM All Rights Reserved



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=



 

Categories: HowTo, Tools Tags:

WEvtUtil Scripting

July 16th, 2008 Comments off

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


 


REM (C) 2008 Microsoft Corporation


REM All Rights Reserved



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=



 

Categories: HowTo, Tools Tags:

Ned on Auditing

April 20th, 2008 No comments

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.


 

Categories: HowTo, Tips Tags: