Archive

Archive for the ‘Tools’ Category

Security Compliance Manager 4.0 now available for download!

July 28th, 2016 No comments

The Security Compliance Manager (SCM) is a free tool from Microsoft that enables you to quickly configure, and manage the computers in your environment using Group Policy and Microsoft System Center Configuration Manager. This version of SCM supports Windows 10, and Windows Server 2016.

You can easily configure computers running Windows 10 and Windows Server 2016 based on Microsoft Recommended Security Baselines and industry best practices.

You can download SCM 4.0 here.

Updates include:

  • Support for existing Windows 10 version 1507, and Windows 10 version 1511 security baselines
  • Support for upcoming Windows 10 version 1607, and Windows Server 2016
  • Bug fixes for ‘Compare’ and ‘Simple View’ features in SCM

The latest version of SCM offers all the same great features as before, plus bug fixes, and added support for upcoming baselines. SCM 4.0 provides a single location for creating, managing, analyzing, and customizing baselines to secure your environment quicker and more efficiently. In addition to the latest software releases, you can also configure previous additions of Windows client, Server, and Microsoft Office.

SCM provides DCM 2007 configuration packs that allow you to manage configuration drifts using Microsoft System Center Configuration Manager. Microsoft’s Operations Management Suite also supports monitoring for Security Baselines in your Server environments.

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 Comments off

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented 🙂  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 No comments

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented 🙂  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 No comments

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented 🙂  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 No comments

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented :-)  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

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

June 11th, 2009 Comments off

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


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


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


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


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


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


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


Eric


 


 


 

Categories: Descriptions, Tips, Tools Tags:

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

June 11th, 2009 No comments

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


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


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


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


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


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


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


Eric


 


 


 

Categories: Descriptions, Tips, Tools Tags:

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

June 11th, 2009 No comments

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


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


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


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


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


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


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


Eric


 


 


 

Categories: Descriptions, Tips, Tools Tags:

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

June 10th, 2009 No comments

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


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


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


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


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


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


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


Eric


 


 


 

Categories: Descriptions, Tips, 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:

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:

Windows Server 2008 Security Events Posted

April 17th, 2008 No comments

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


Check it out in the Knowledge Base.


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


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


2010-04-01 UPDATE:  Here is the link to the updated spreadsheet for Windows 7 and Windows Server 2008 R2.

Categories: Descriptions, Tools Tags:

Windows Server 2008 Security Events Posted

April 17th, 2008 Comments off

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


Check it out in the Knowledge Base.


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


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


2010-04-01 UPDATE:  Here is the link to the updated spreadsheet for Windows 7 and Windows Server 2008 R2.

Categories: Descriptions, Tools Tags:

Windows Server 2008 Security Events Posted

April 17th, 2008 No comments

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


Check it out in the Knowledge Base.


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


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


2010-04-01 UPDATE:  Here is the link to the updated spreadsheet for Windows 7 and Windows Server 2008 R2.

Categories: Descriptions, Tools Tags:

Shameless Self-Promotion

March 5th, 2008 Comments off

There’s one topic that I know is on everyone’s mind- no, not American Idol– it’s “What’s new in Auditing in Windows Server 2008?”


Well, funny that you brought that up.  My friend Jesper Johanssen just wrote a new book, the Windows Server 2008 Security Resource Kit, and he invited me to write a chapter about auditing for it, which I did.  So you, dear reader, are getting information straight from the horse’s mouth, so to speak.


Anyway I think the book hits store shelves on March the 10th.  A number of distinguished individuals contributed to the book: Susan Bradley, Darren Canavor, Kurt Dillard, Roger Grimes, Brian Komar, Alun Jones and others.


I’d also like to send out special props to my auditing posse: Raghu (who was the primary developer for auditing for Vista & WS08) and Ned (who is the resident guru for auditing in Microsoft Customer Support Services), both of whom made significant contributions.  Raghu introduces the new “special group logon tracking” feature, and Ned contributed a spreadsheet mapping all the events (360-ish) to the policy category and subcategory and giving other key information about each event; this is included on the CD bundled with the book, along with an XML file defining the schema for all the events and event messages.  Ned’s also working on getting a version of the spreadsheet available for download from the Microsoft download site.


In other news, the Windows Server 2008 Security Guide is also out, and yes, yours truly contributed in small part to the auditing guidance in there too, although I seem to have been overlooked in the credits (in all fairness my work delta from the Vista Security Guide was really small so maybe it did not meet their “credits bar”).


Anyway, download the security guide and buy a copy of the book.  Buy more than one copy of the book, and give copies to your friends and loved ones.  Nothing says “Happy Anniversary, Honey” quite like a book or white paper about computer security.  OK, so maybe I should stick to computer security and stay away from relationship advice.  Flowers work well in my experience.

Categories: News, Tools Tags:

Shameless Self-Promotion

March 5th, 2008 No comments

There’s one topic that I know is on everyone’s mind- no, not American Idol– it’s “What’s new in Auditing in Windows Server 2008?”


Well, funny that you brought that up.  My friend Jesper Johanssen just wrote a new book, the Windows Server 2008 Security Resource Kit, and he invited me to write a chapter about auditing for it, which I did.  So you, dear reader, are getting information straight from the horse’s mouth, so to speak.


Anyway I think the book hits store shelves on March the 10th.  A number of distinguished individuals contributed to the book: Susan Bradley, Darren Canavor, Kurt Dillard, Roger Grimes, Brian Komar, Alun Jones and others.


I’d also like to send out special props to my auditing posse: Raghu (who was the primary developer for auditing for Vista & WS08) and Ned (who is the resident guru for auditing in Microsoft Customer Support Services), both of whom made significant contributions.  Raghu introduces the new “special group logon tracking” feature, and Ned contributed a spreadsheet mapping all the events (360-ish) to the policy category and subcategory and giving other key information about each event; this is included on the CD bundled with the book, along with an XML file defining the schema for all the events and event messages.  Ned’s also working on getting a version of the spreadsheet available for download from the Microsoft download site.


In other news, the Windows Server 2008 Security Guide is also out, and yes, yours truly contributed in small part to the auditing guidance in there too, although I seem to have been overlooked in the credits (in all fairness my work delta from the Vista Security Guide was really small so maybe it did not meet their “credits bar”).


Anyway, download the security guide and buy a copy of the book.  Buy more than one copy of the book, and give copies to your friends and loved ones.  Nothing says “Happy Anniversary, Honey” quite like a book or white paper about computer security.  OK, so maybe I should stick to computer security and stay away from relationship advice.  Flowers work well in my experience.

Categories: News, Tools Tags:

Shameless Self-Promotion

March 5th, 2008 No comments

There’s one topic that I know is on everyone’s mind- no, not American Idol– it’s “What’s new in Auditing in Windows Server 2008?”


Well, funny that you brought that up.  My friend Jesper Johanssen just wrote a new book, the Windows Server 2008 Security Resource Kit, and he invited me to write a chapter about auditing for it, which I did.  So you, dear reader, are getting information straight from the horse’s mouth, so to speak.


Anyway I think the book hits store shelves on March the 10th.  A number of distinguished individuals contributed to the book: Susan Bradley, Darren Canavor, Kurt Dillard, Roger Grimes, Brian Komar, Alun Jones and others.


I’d also like to send out special props to my auditing posse: Raghu (who was the primary developer for auditing for Vista & WS08) and Ned (who is the resident guru for auditing in Microsoft Customer Support Services), both of whom made significant contributions.  Raghu introduces the new “special group logon tracking” feature, and Ned contributed a spreadsheet mapping all the events (360-ish) to the policy category and subcategory and giving other key information about each event; this is included on the CD bundled with the book, along with an XML file defining the schema for all the events and event messages.  Ned’s also working on getting a version of the spreadsheet available for download from the Microsoft download site.


In other news, the Windows Server 2008 Security Guide is also out, and yes, yours truly contributed in small part to the auditing guidance in there too, although I seem to have been overlooked in the credits (in all fairness my work delta from the Vista Security Guide was really small so maybe it did not meet their “credits bar”).


Anyway, download the security guide and buy a copy of the book.  Buy more than one copy of the book, and give copies to your friends and loved ones.  Nothing says “Happy Anniversary, Honey” quite like a book or white paper about computer security.  OK, so maybe I should stick to computer security and stay away from relationship advice.  Flowers work well in my experience.

Categories: News, Tools Tags:

ACS Event Transformation Demystified

February 28th, 2008 Comments off

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 SourceId=644 SourceName=SE_AUDITID_ACCOUNT_AUTO_LOCKED>


                              <Call Name=AppendString Param1=1 Param2=0 />


                              <Call Name=AppendString Param1=3 Param2=0 />


                              <Call Name=AppendString Param1=2 Param2=0 />


                              <Call Name=AppendString Param1=4 Param2=0 />


                              <Call Name=AppendString Param1=5 Param2=0 />


                              <Call Name=AppendString Param1=6 Param2=0 />


                              <Call Name=AppendSidFromNames Param1=4 Param2=5 />


                              <Call Name=AppendNamesFromSid Param1=3 Param2=0 />


                              <Param TypeName=typeUserDn />


                              <Param TypeName=typeComputerName />


                              <Param TypeName=typeTargetSid />


                              <Param TypeName=typeClientUser />


                              <Param TypeName=typeClientDomain />


                              <Param TypeName=typeClientLogonId />


                              <Param TypeName=typeClientSid />


                              <Param TypeName=typeTargetUser />


                              <Param TypeName=typeTargetDomain />


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


 


<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event“>


  <System>


    <Provider Name=”Security” />


    <EventID Qualifiers=”0″>644</EventID>


    <Level>0</Level>


    <Task>7</Task>


    <Keywords>0xa0000000000000</Keywords>


    <TimeCreated SystemTime=”2007-12-17T15:50:14.000Z” />


    <EventRecordID>28003981</EventRecordID>


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


    <Computer>SERVER34</Computer>


    <Security UserID=”S-1-5-18″ />


  </System>


  <EventData>


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


                              <Call Name=AppendString Param1=1 Param2=0 />


                              <Call Name=AppendString Param1=2 Param2=0 />


                              <Call Name=AppendString Param1=3 Param2=0 />









// try deleting a line here


// or, to preserve ordering of subsequent strings


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


                              <Call Name=AppendString Param1=4 Param2=0 />


                              <Call Name=AppendString Param1=5 Param2=0 />


                              <Call Name=AppendString Param1=6 Param2=0 />




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

Categories: ACS, HowTo, SEM, Tools Tags:

ACS Event Transformation Demystified

February 28th, 2008 No comments

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 SourceId=644 SourceName=SE_AUDITID_ACCOUNT_AUTO_LOCKED>


                              <Call Name=AppendString Param1=1 Param2=0 />


                              <Call Name=AppendString Param1=3 Param2=0 />


                              <Call Name=AppendString Param1=2 Param2=0 />


                              <Call Name=AppendString Param1=4 Param2=0 />


                              <Call Name=AppendString Param1=5 Param2=0 />


                              <Call Name=AppendString Param1=6 Param2=0 />


                              <Call Name=AppendSidFromNames Param1=4 Param2=5 />


                              <Call Name=AppendNamesFromSid Param1=3 Param2=0 />


                              <Param TypeName=typeUserDn />


                              <Param TypeName=typeComputerName />


                              <Param TypeName=typeTargetSid />


                              <Param TypeName=typeClientUser />


                              <Param TypeName=typeClientDomain />


                              <Param TypeName=typeClientLogonId />


                              <Param TypeName=typeClientSid />


                              <Param TypeName=typeTargetUser />


                              <Param TypeName=typeTargetDomain />


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


 


<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event“>


  <System>


    <Provider Name=”Security” />


    <EventID Qualifiers=”0″>644</EventID>


    <Level>0</Level>


    <Task>7</Task>


    <Keywords>0xa0000000000000</Keywords>


    <TimeCreated SystemTime=”2007-12-17T15:50:14.000Z” />


    <EventRecordID>28003981</EventRecordID>


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


    <Computer>SERVER34</Computer>


    <Security UserID=”S-1-5-18″ />


  </System>


  <EventData>


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


                              <Call Name=AppendString Param1=1 Param2=0 />


                              <Call Name=AppendString Param1=2 Param2=0 />


                              <Call Name=AppendString Param1=3 Param2=0 />









// try deleting a line here


// or, to preserve ordering of subsequent strings


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


                              <Call Name=AppendString Param1=4 Param2=0 />


                              <Call Name=AppendString Param1=5 Param2=0 />


                              <Call Name=AppendString Param1=6 Param2=0 />




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

Categories: ACS, HowTo, SEM, Tools Tags: