Swedish Windows Security User Group

Hello,

We get quite a few calls from administrators who ask if they can manually update their Forefront Protection 2010 for Exchange Server (FPE) and Forefront Protection 2010 for SharePoint scan engines.

 Well, the short answer is yes, but the long answer is a bit longer, so in order to provide guidance to those of you who wish to manually update the FPE/FPSP scan engines and definitions as part of your Forefront Protection defense strategies, Microsoft has provided a comprehensive set of instructions via the following Knowledge Base article:

 http://support.microsoft.com/kb/2292741

 So, whatever your reason for not using automatic updating, you can follow the steps outlined in the KB to manually update Forefront Protection’s scan engines.

 Included in the KB is a sample PowerShell script that you can customize to synch with your specific network parameters and adjust to your environmental needs.

 Regards,

Robert McCarthy

Support Engineer – Microsoft Security

Problem was that an event ID 1040 was logged which says, a server based rule
(configured in Outlook) was stopped, but without mentioning the reason or more details.

Event ID: 1040
Level:    Error
Provider: MSExchangeIS Mailbox Store
Message:  The rule “rulename”” with the sequence number 20 was disabled due to the error -2147467259 that was encountered  while applying the rule.

The problem was absolute sporadic.

So the plan was to configure diagnostic logging and to create an extra trace.
This extra trace can be sent in to Microsoft for further analysis.
The extra trace should run all the time and should be stopped after the problem happens.
The challenge here was how to stop the trace, at the time the problem happens, so that the
log file, would not get overwritten.

Here is what you can do if the operating system on which Exchange 2007 runs on is windows 2008:
The steps are:

1.
Set diagnostic logging (in this case diagnostic logging for private rules)

On the Exchange server open the powershell:
Set-EventLogLevel “MSExchangeIS\9000 Private\Rules” -level high

2.
a) Start tracing:

Go to c:\program files\microsoft\Exchangeserver\bin
From there start the extra.exe

Select a task
Trace control; OK
Select trace file location: Enter the path where the file should be saved
Select trace file name: Enter the file name
Enter max trace file size (MB): Enter 250
Select trace file behavior: Circular logging

Select manual trace tags:
– Trace Types: Select all except performance
– Components to Trace: On the left site click on: Store
– Trace Tags: On the right site select:

tagDisableRules
tagPrivateRulesErrors
tagrulelocks
tagRulesMiscellaneous
tagRulesSync
tagRulesTable
tagTriggerRules
tagvrules

Then check the checkbox “show only enabled components” and the checkbox: “Show only enabled tags”.
If other components or tags are enabled then the ones we selected please uncheck them

Click on start tracing. Then let the GUI stay as it is.

b) Configure to stop the tracing based on event 1040:

Attach to the event 1040 in event viewer:
Go to start, run: eventvwr.exe
In event viewer go to Windows Logs, Application, right click on the event 1040 and click on
“attach task to this event”
Give it a name and a description, click on the next button 2 times

Select “Start a program” 
program: c:\windows\system32\logman.exe
Arguments: stop -ets -n ExchangeDebugTraces
click on next and click on finish

c) check if the trace is running:

Start perfmon.exe and check if the session is running:
Go to start, run: perfmon
Data Collector Sets
Event Trace Sessions
There you should see a session called “ExchangeDebugTraces”
It should be shown as running.

d) After the log file is created

After the event occurred in the event log the trace should be stopped.
In perfmon you should no longer see the “ExchangeDebugTraces” session .
The you can close the GUI from extra.exe

To clear the task from the task scheduler:
Start, Programs, Administrative Tools, Task Scheduler
In the Task Scheduler, go to Task Scheduler Library, Event Viewer Tasks and delete the tasks you created earlier.

You can set the diagnostic logging back to none:
Set-EventLogLevel “MSExchangeIS\9000 Private\Rules” -level lowest

This week we made some significant changes to the Antigen documentation that is available in the TechNet Library. We did this in order to improve your ability to find the information that is most relevant when using a search engine to find answers to your questions. Rest assured that the information isn’t gone forever, it’s merely moved to a new format on a different site.

Here’s what happened: We moved the Antigen release notes, getting started, and deployment information out of the TechNet Library and into downloadable Microsoft® Word documents on the Microsoft Download Center. When we archive 50 topics this way, these now resolve as one search hit instead of 50. That takes 49 items you probably didn’t even need out of your way.

We’ve left the Antigen user guides and best practices information right where you’re used to finding it in the TechNet Library. Additionally, the Evaluation Guide and Quick Start Guide information is all still available in the Antigen for Exchange, Antigen for SMTP Gateways, and Antigen Enterprise Manager user guides.

Once again, here is what moved and where to find it:

John Andrilla
Technical Editor, BPSG iX

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 2 for Microsoft Forefront Security for SharePoint Service Pack 3!

On July 20th 2010 Microsoft shipped Hotfix Rollup 2 for Microsoft Forefront Security for SharePoint Service Pack 3.

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:

·         Description of Hotfix Rollup 2 for Microsoft Forefront Security for SharePoint Service Pack 3:  http://support.microsoft.com/kb/2270645

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

Regards,

Robert McCarthy
Microsoft Security

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 2 for Microsoft Forefront Security for Exchange Service Pack 2!

On July 20th, 2010 Microsoft shipped Hotfix Rollup 2 for Microsoft Forefront Security for Exchange Service Pack 2.

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:

·         Description of Hotfix Rollup 2 for Microsoft Forefront Security for Exchange Service Pack 2:  http://support.microsoft.com/kb/2270641

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

Regards,

Robert McCarthy
Microsoft Security

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.

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.

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.

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.

Three months ago we posted about the open beta for the Asset Inventory Service (AIS) 2.0. To all of you who signed up, we want to say thanks for your help and participation. It was great to see to people interested in the improved user interface, the…(read more)

Revision Note: V2.0 (July 13, 2010): Advisory updated to reflect publication of security bulletin.
Summary: Microsoft has completed the investigation into a public report of this vulnerability. We have issued MS10-043 to address this issue. For more information about this issue, including download links for an available security update, please review MS10-043. The vulnerability addressed is the Canonical Display Driver Integer Overflow Vulnerability – CVE-2009-3678.

Revision Note: V2.0 (July 13, 2010): Advisory updated to reflect publication of security bulletin.
Summary: Microsoft has completed the investigation into a public report of this vulnerability. We have issued MS10-042 to address this issue. For more information about this issue, including download links for an available security update, please review MS10-042. The vulnerability addressed is the Help Center URL Validation Vulnerability – CVE-2010-1885.

Revision Note: V2.0 (July 13, 2010): Advisory updated to reflect publication of security bulletin. Advisory Summary:Microsoft has completed the investigation into a public report of this vulnerability. We have issued MS10-043 to address this issue. For more information about this issue, including download links for an available security update, please review MS10-043. The vulnerability addressed is the Canonical Display Driver Integer Overflow Vulnerability – CVE-2009-3678.

Revision Note: V2.0 (July 13, 2010): Advisory updated to reflect publication of security bulletin. Advisory Summary:Microsoft has completed the investigation into a public report of this vulnerability. We have issued MS10-042 to address this issue. For more information about this issue, including download links for an available security update, please review MS10-042. The vulnerability addressed is the Help Center URL Validation Vulnerability – CVE-2010-1885.