We are happy to announce the availability of Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). TMG SP2 Rollup 5 is available for download here: Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2

 

Please see KB Article ID: 2954173 for details of the fixes included in this rollup. The Build Number for this update is: 7.0.9193.644

 

To install this update, you must be running Forefront Threat Management Gateway 2010 Service Pack 2.

For more information about Forefront Threat Management Gateway 2010 SP2, please see the following
Microsoft website: Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Download information for Forefront TMG 2010 SP2

 

Thank you,

Forefront TMG Team

We are happy to announce the availability of Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). TMG SP2 Rollup 5 is available for download here: Rollup 5 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2

 

Please see KB Article ID: 2954173 for details of the fixes included in this rollup. The Build Number for this update is: 7.0.9193.644

 

To install this update, you must be running Forefront Threat Management Gateway 2010 Service Pack 2.

For more information about Forefront Threat Management Gateway 2010 SP2, please see the following
Microsoft website: Microsoft Forefront Threat Management Gateway 2010 Service Pack 2

Download information for Forefront TMG 2010 SP2

 

Thank you,

Forefront TMG Team

On August 14, 2012, Microsoft will issue a critical non-security update (KB 2661254) for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The update will block the use of cryptographic keys that are less than 1024 bits. This update was first announced in the blog titled RSA keys under 1024 bits are blocked. This blog post is a reminder that the update is coming and provides a bit more information on how to control the update when deployed.

Note: The modification (opt-out settings) discussed in this article will apply throughout the operating system. You cannot configure these modifications to be applicable to a specific application, custom certificate, or scenario. You can configure these modifications before the update is applied and when the update is applied, they will take effect. The update will require a restart.

You can modify a registry setting using the certutil command to modify the size of the keys that are blocked. For example, if you wanted to allow 512 bit keys, but block all keys less than 512 bits, you could run the following command:

Certutil -setreg chain\minRSAPubKeyBitLength 512

Note: All certutil commands shown in this article require local Administrator privileges because they are modifiying the registry. You can disregard the message that reads “The CertSvc service may need to be restarted for changes to take effect.” That is not required for these commands as they do not affect the certificate service (CertSvc).

If only the root certificate in a chain is 512 bits, but all the rest of the keys below are 1024 bits or higher, you could run the following command to indicate that you will allow a 512 bit root certificate, but want to block all keys less than 1024 bits below the root certificate.

Certutil -setreg chain\EnableWeakSignatureFlags 2

Note: The above command also works with self-signed certificates with RSA keys less than 1024.

The certutil commands shown in this posting will not work on Windows XP, Windows Server 2003, or Windows Server 2003 R2. You will have to modify the registry directly using regedit.exe or reg command. Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config. The following table and figure illustrate registry the settings shown in the previous two examples:

Name	Type	Decimal data
EnableWeakSignatureFlags	REG_DWORD	2
minRSAPubKeyBitLength	REG_DWORD	512

If you have Authenticode signatures that were signed with keys less than 1024 bits prior to January 1, 2010, 12:00:00 AM UTC/GMT, they will not be blocked by default. If necessary, you can use the WeakRsaPubKeyTime setting to allow for the configuration of the date and time for which to consider older signatures valid. If you have reason to set a different date and time for the WeakRsaPubKeyTime, you can use certutil to set a different date and time. For example, if you wanted to set the date to August 29, 2010, you could use the following command:

certutil -setreg chain\WeakRsaPubKeyTime @08/29/2010

If you have a need to set a specific time, such as 6:00 PM UTC/GMT on July 4, 2011, then add the number of days and hours in the format +[dd:hh] to the command. Since 6:00 PM is 18 hours after midnight on July 4, 2011, you would run the following command:

certutil -setreg chain\WeakRsaPubKeyTime @07/04/2011+00:18

To enter WeakRsaPubKeyTime and date on Windows XP, Windows Server 2003, or Windows Server 2003 R2, use a REG_BINARY value for WeakRsaPubKeyTime. You can figure out the hex value using certutil on Windows Vista, Windows Server 2008, or more recent Windows operating system and then view the value in the registry or export the value to a REG file for viewing. The following table shows REG_BINARY hex value equivalents for WeakRsaPubKeyTime

Date/Time	Hex value
August 29, 2010 at midnight UTC\GMT	00 d8 f0 cb 47 47 cb 01
July 4, 2011 at 6 PM UTC\GMT	00 e8 64 dd ae 3a cc 01

Additional resources

Security advisory http://technet.microsoft.com/security/advisory/2661254.

KB 2661254: http://support.microsoft.com/kb/2661254

Additional blog posts:

RSA keys under 1024 bits are blocked

http://blogs.technet.com/b/pki/archive/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3.aspx

On August 14, 2012, Microsoft will issue a critical non-security update (KB 2661254) for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The update will block the use of cryptographic keys that are less than 1024 bits. This update was first announced in the blog titled RSA keys under 1024 bits are blocked. This blog post is a reminder that the update is coming and provides a bit more information on how to control the update when deployed.

Note: The modification (opt-out settings) discussed in this article will apply throughout the operating system. You cannot configure these modifications to be applicable to a specific application, custom certificate, or scenario. You can configure these modifications before the update is applied and when the update is applied, they will take effect. The update will require a restart.

You can modify a registry setting using the certutil command to modify the size of the keys that are blocked. For example, if you wanted to allow 512 bit keys, but block all keys less than 512 bits, you could run the following command:

Certutil -setreg chain\minRSAPubKeyBitLength 512

Note: All certutil commands shown in this article require local Administrator privileges because they are modifiying the registry. You can disregard the message that reads “The CertSvc service may need to be restarted for changes to take effect.” That is not required for these commands as they do not affect the certificate service (CertSvc).

If only the root certificate in a chain is 512 bits, but all the rest of the keys below are 1024 bits or higher, you could run the following command to indicate that you will allow a 512 bit root certificate, but want to block all keys less than 1024 bits below the root certificate.

Certutil -setreg chain\EnableWeakSignatureFlags 2

Note: The above command also works with self-signed certificates with RSA keys less than 1024.

The certutil commands shown in this posting will not work on Windows XP, Windows Server 2003, or Windows Server 2003 R2. You will have to modify the registry directly using regedit.exe or reg command. Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config. The following table and figure illustrate registry the settings shown in the previous two examples:

Name	Type	Decimal data
EnableWeakSignatureFlags	REG_DWORD	2
minRSAPubKeyBitLength	REG_DWORD	512

If you have Authenticode signatures that were signed with keys less than 1024 bits prior to January 1, 2010, 12:00:00 AM UTC/GMT, they will not be blocked by default. If necessary, you can use the WeakRsaPubKeyTime setting to allow for the configuration of the date and time for which to consider older signatures valid. If you have reason to set a different date and time for the WeakRsaPubKeyTime, you can use certutil to set a different date and time. For example, if you wanted to set the date to August 29, 2010, you could use the following command:

certutil -setreg chain\WeakRsaPubKeyTime @08/29/2010

If you have a need to set a specific time, such as 6:00 PM UTC/GMT on July 4, 2011, then add the number of days and hours in the format +[dd:hh] to the command. Since 6:00 PM is 18 hours after midnight on July 4, 2011, you would run the following command:

certutil -setreg chain\WeakRsaPubKeyTime @07/04/2011+00:18

To enter WeakRsaPubKeyTime and date on Windows XP, Windows Server 2003, or Windows Server 2003 R2, use a REG_BINARY value for WeakRsaPubKeyTime. You can figure out the hex value using certutil on Windows Vista, Windows Server 2008, or more recent Windows operating system and then view the value in the registry or export the value to a REG file for viewing. The following table shows REG_BINARY hex value equivalents for WeakRsaPubKeyTime

Date/Time	Hex value
August 29, 2010 at midnight UTC\GMT	00 d8 f0 cb 47 47 cb 01
July 4, 2011 at 6 PM UTC\GMT	00 e8 64 dd ae 3a cc 01

Additional resources

Security advisory http://technet.microsoft.com/security/advisory/2661254.

KB 2661254: http://support.microsoft.com/kb/2661254

Additional blog posts:

RSA keys under 1024 bits are blocked

http://blogs.technet.com/b/pki/archive/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3.aspx

On August 14, 2012, Microsoft will issue a critical non-security update (KB 2661254) for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The update will block the use of cryptographic keys that are less than 1024 bits. This update was first announced in the blog titled RSA keys under 1024 bits are blocked. This blog post is a reminder that the update is coming and provides a bit more information on how to control the update when deployed.

Note: The modification (opt-out settings) discussed in this article will apply throughout the operating system. You cannot configure these modifications to be applicable to a specific application, custom certificate, or scenario. You can configure these modifications before the update is applied and when the update is applied, they will take effect. The update will require a restart.

You can modify a registry setting using the certutil command to modify the size of the keys that are blocked. For example, if you wanted to allow 512 bit keys, but block all keys less than 512 bits, you could run the following command:

Certutil -setreg chainminRSAPubKeyBitLength 512

Note: All certutil commands shown in this article require local Administrator privileges because they are modifiying the registry. You can disregard the message that reads “The CertSvc service may need to be restarted for changes to take effect.” That is not required for these commands as they do not affect the certificate service (CertSvc).

If only the root certificate in a chain is 512 bits, but all the rest of the keys below are 1024 bits or higher, you could run the following command to indicate that you will allow a 512 bit root certificate, but want to block all keys less than 1024 bits below the root certificate.

Certutil -setreg chainEnableWeakSignatureFlags 2

Note: The above command also works with self-signed certificates with RSA keys less than 1024.

The certutil commands shown in this posting will not work on Windows XP, Windows Server 2003, or Windows Server 2003 R2. You will have to modify the registry directly using regedit.exe or reg command. Registry path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CertDllCreateCertificateChainEngineConfig. The following table and figure illustrate registry the settings shown in the previous two examples:

Name	Type	Decimal data
EnableWeakSignatureFlags	REG_DWORD	2
minRSAPubKeyBitLength	REG_DWORD	512

If you have Authenticode signatures that were signed with keys less than 1024 bits prior to January 1, 2010, 12:00:00 AM UTC/GMT, they will not be blocked by default. If necessary, you can use the WeakRsaPubKeyTime setting to allow for the configuration of the date and time for which to consider older signatures valid. If you have reason to set a different date and time for the WeakRsaPubKeyTime, you can use certutil to set a different date and time. For example, if you wanted to set the date to August 29, 2010, you could use the following command:

certutil -setreg chainWeakRsaPubKeyTime @08/29/2010

If you have a need to set a specific time, such as 6:00 PM UTC/GMT on July 4, 2011, then add the number of days and hours in the format +[dd:hh] to the command. Since 6:00 PM is 18 hours after midnight on July 4, 2011, you would run the following command:

certutil -setreg chainWeakRsaPubKeyTime @07/04/2011+00:18

To enter WeakRsaPubKeyTime and date on Windows XP, Windows Server 2003, or Windows Server 2003 R2, use a REG_BINARY value for WeakRsaPubKeyTime. You can figure out the hex value using certutil on Windows Vista, Windows Server 2008, or more recent Windows operating system and then view the value in the registry or export the value to a REG file for viewing. The following table shows REG_BINARY hex value equivalents for WeakRsaPubKeyTime

Date/Time	Hex value
August 29, 2010 at midnight UTCGMT	00 d8 f0 cb 47 47 cb 01
July 4, 2011 at 6 PM UTCGMT	00 e8 64 dd ae 3a cc 01

Additional resources

Security advisory http://technet.microsoft.com/security/advisory/2661254.

KB 2661254: http://support.microsoft.com/kb/2661254

Additional blog posts:

RSA keys under 1024 bits are blocked

http://blogs.technet.com/b/pki/archive/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3.aspx

We’d like to advise that Rollup 2 for TMG SP2 is now available.

TMG SP2 Rollup 2 can be downloaded here: http://support.microsoft.com/kb/2689195

Please see KB  for details of the fixes included in this rollup.

The Build Number is: 7.0.9193.540

Thank you

We are happy to announce the availability of Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). The service pack is available for download from the Microsoft Download Center.

Here are some of the improvements we are introducing in Forefront TMG SP2:

• Site activity report – Forefront TMG SP2 includes a new site activity report that enables you to generate a report showing the data transfer between users and specific websites. This report displays the amount of data transferred to and from different websites, for any
  period that you specify, per user. In addition, you can also display the total data transfer to and from a specific website, per user. 

• Improved error pages – Forefront TMG SP2 improves the look and feel of web browser error pages and makes it easier to customize the pages.

• Kerberos authentication for NLB arrays – Forefront TMG SP2 enables you to allow users to authenticate to a Forefront TMG array with Network Load Balancing (NLB) enabled using the Kerberos version 5 protocol.

Visit our TechNet Library for more information.

– The Forefront TMG Team

by Michael Cureton

We’ve become aware of two issues when using the Definition Update Automation Tool. This blog article presents workarounds for the issues.

Definition Update Automation Tool fails to add new definition updates to the deployment package

 

Symptoms

The FEP 2010 Definition Update Automation Tool may fail to add new definition updates to your deployment package. Reviewing the %ProgramData%\SoftwareUpdateAutomation.log file shows the following exception:

SmsAdminUISnapIn Error: 1 : Unexpected exception: System.ArgumentException: An item with the same key has already been added.
  at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
  at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
  at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
  at Microsoft.Forefront.EndpointProtection.SoftwareUpdateAutomation.SccmUtilities.CalculateCleanupDelta(ConnectionManagerBase connection, ICollection`1 freshUpdateFilesObjectList, IResultObject destinationPackageObject)
  at Microsoft.Forefront.EndpointProtection.SoftwareUpdateAutomation.SoftwareUpdater.Update(SoftwareUpdateAutomationArguments arguments)
  at Microsoft.Forefront.EndpointProtection.SoftwareUpdateAutomation.SoftwareUpdater.Main(String[] args)

 

Cause

More than one FEP 2010 definition update is being detected as active by the tool.

More Information

The FEP 2010 Definition Update Automation tool queries WMI (SELECT * FROM SMS_SoftwareUpdate WHERE ArticleID=2461484 AND IsSuperseded=0 AND IsEnabled=1) to get the single active FEP 2010 definition update. The exception happens as a result of more than one update being returned. The tool may detect more than one update as being active when one of the two conditions is TRUE:

1. One or more FEP 2010 definition updates has been expired but not superseded, OR
2. One or more FEP 2010 definition updates has been orphaned.

To confirm if you’re experiencing condition #1 or #2, run the below WMI query:

SELECT * FROM SMS_SoftwareUpdate WHERE ArticleID=2461484 AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0

If the query only returns one row, then you are experiencing condition #1. If two or more rows are returned, you are experiencing condition #2.

Workarounds

Condition #1

If you are experiencing condition #1, you can prevent the symptom by simply adding the /UpdateFilter flag to the command line for the tool (SoftwareUpdateAutomation.exe) with the appropriate values to filter out expired definition updates that are not superseded.

For example:

SoftwareUpdateAutomation.exe /AssignmentName <AssignmentName> /PackageName <DeploymentPkgName> /UpdateFilter “ArticleID=2461484 AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0”

Condition #2

If you are experiencing condition #2, you will need to manually decline the orphaned updates via the WSUS administration console. For each update returned from the WMI query that you used to confirm that you have condition #2, double-click on the LocalizedDisplayName property and note the definition version. The update with the highest definition version will be the active one. The update(s) with the lower definition versions have been orphaned.

For example, using the list below, 1.107.713.0 would be the active update and the other two updates are orphaned and would need to be declined manually in WSUS.

Definition Update for Microsoft Forefront Endpoint Protection 2010 – KB2461484 (Definition 1.103.1405.0)
Definition Update for Microsoft Forefront Endpoint Protection 2010 – KB2461484 (Definition 1.105.2231.0)
Definition Update for Microsoft Forefront Endpoint Protection 2010 – KB2461484 (Definition 1.107.713.0)

After you have determined the orphaned update(s) title (and version), load the WSUS snap-in and drill down to the Updates node. On the action pane, click New Update View. Select “Updates are in a specific classification” and “Updates are for a specific product”. In step 2, click any classification and ensure that only Definition Updates is checked. Next click any product and ensure that only Forefront Endpoint Protection 2010 is checked. In step 3, specify a name for the view and click OK.

Locate the created view in the WSUS console. Change the Approval value to “Any Except Declined” and the Status to “Any” and hit Refresh. Click the Title column so that the results are sorted using the version. Find the orphaned update(s) that you identified by version and select the Decline action for each. Once this is complete, you’ll need to wait for the next scheduled Software Update Point (SUP) sync to complete, at which time the updates that you declined will be marked as expired in the ConfigMgr database.

NOTE: Running a manual SUP sync will NOT expire the declined updates. Only a scheduled sync will perform this operation.

Once the sync is complete, you can run the WMI query used to determine condition to confirm that only one row is now returned. You will also need to run the tool going forward using the condition #1 workaround with the /UpdateFilter flag.

Definition Update Automation Tool does not refresh distribution points

 

Symptoms

The FEP 2010 Definition Update Automation Tool does not refresh distribution points (DPs) by default. Even though the help output for the tool states that /RefreshDP is set by default, it is not.

 

Workarounds

Add /RefreshDP to the command line for the tool (SoftwareUpdateAutomation.exe). For example:

SoftwareUpdateAutomation.exe /AssignmentName <AssignmentName> /PackageName <DeploymentPkgName> /RefreshDP

Hi folks,

There have been some questions about these two areas of definition updates, so I wanted to clarify this a bit.

Whenever FEP does a definition update, a silent rescan of all running processes and loaded modules is performed. If there is malware running that is now detected by the new definitions, that malware is detected within a few seconds of performing the update. There is no action needed on your part after new definitions are downloaded – this silent rescan happens automatically.

Additionally, the FEP client can be configured to check for definition updates automatically on service start. The behavior is the same as described in Checking for definition updates when starting (yes, that particular blog article deals with FCS, but the FEP behavior is the same). The registry key already exists in the FEP ADMX, which you can download as part of the FEP2010grouppolicytools-<locale>.exe here. For full documentation about all the values in the ADMX, see the FEP ADMX Reference.

Thanks!

 By Adwait Joshi

Hello,

An Update Rollup for Forefront Endpoint Protection 2010 is now available here: http://go.microsoft.com/fwlink/?LinkId=223229 .

 In addition to hotfixes, this Update also includes some important changes to note:

1. Support for Windows Embedded 7 platforms:  With this update, the FEP client software is supported on certain Windows Embedded 7 platforms (including Windows Thin PC) and Windows Server 2008 Server Core.  For more information about the additional support, see Prerequisites for Deploying Forefront Endpoint Protection on a Client Computer.
2. Signature Update Automation Tool used with Configuration Manager Software Update:  This tool automates downloading FEP definition updates using Configuration Manager 2007 Software Updates.  This is a command line tool that uses Configuration Manager APIs to get new definitions from Microsoft Update via the Configuration Manager software update feature, distribute the content to distribution points, and deploy the updates to Endpoint Protection clients on a recurring schedule.  The automation of the tool is done through the Windows task scheduler. To download the tool, see http://go.microsoft.com/fwlink/?LinkID=221205
3. Two new preconfigured policy templates for the following server workloads:
1. Microsoft Forefront Threat Management Gateway
2. Microsoft Lync 2010

You can find more details in the “What’s New” document on the  Technet site.  Please check out this KB article for a full list of fixes included in this Update Rollup.

Thanks,

Adwait Joshi

Sr. Technical Product Manager

Forefront Endpoint Protection

 By Adwait Joshi

Hello,

An Update Rollup for Forefront Endpoint Protection 2010 is now available here: http://go.microsoft.com/fwlink/?LinkId=223229 .

 In addition to hotfixes, this Update also includes some important changes to note:

1. Support for Windows Embedded 7 platforms:  With this update, the FEP client software is supported on certain Windows Embedded 7 platforms (including Windows Thin PC) and Windows Server 2008 Server Core.  For more information about the additional support, see Prerequisites for Deploying Forefront Endpoint Protection on a Client Computer.
2. Signature Update Automation Tool used with Configuration Manager Software Update:  This tool automates downloading FEP definition updates using Configuration Manager 2007 Software Updates.  This is a command line tool that uses Configuration Manager APIs to get new definitions from Microsoft Update via the Configuration Manager software update feature, distribute the content to distribution points, and deploy the updates to Endpoint Protection clients on a recurring schedule.  The automation of the tool is done through the Windows task scheduler. To download the tool, see http://go.microsoft.com/fwlink/?LinkID=221205
3. Two new preconfigured policy templates for the following server workloads:
1. Microsoft Forefront Threat Management Gateway
2. Microsoft Lync 2010

You can find more details in the “What’s New” document on the  Technet site.  Please check out this KB article for a full list of fixes included in this Update Rollup.

Thanks,

Adwait Joshi

Sr. Technical Product Manager

Forefront Endpoint Protection

Update 9 March 2011

 

 

Hello all,

 

 

Today (8 March 2011), we released an update to FCSv1.   Changes include:

• This update enables computers running Forefront Client Security to update definitions at the scheduled time while running on battery power.
• This update contains changes to allow computers running Forefront Client Security service to open files encrypted by Prim’X ZoneCentral that are located in a network shared folder.
• This update corrects issues in the mpfilter.sys kernel component used by Client Security that causes real-time protection errors on computers running Windows 2000.

For already installed FCS client installations, install the update for Microsoft Knowledge Base article 2508823 (http://support.microsoft.com/kb/2508823).
For new FCS Client installations, deploy the client components listed in Microsoft Knowledge Base article 2508824 (http://support.microsoft.com/kb/2508824).

For more information about the update, Microsoft Knowledge Base article 2508823 (http://support.microsoft.com/kb/2508823) has the detail.

 

Thanks!

---