Forefront TMG (ISA Server) Product Team Blog

Unable to Download an Office file from a Web Server Published through ISA Server 2006

isablog — Sat, 21 Nov 2009 00:55:00 GMT

1. Introduction

Consider a scenario where ISA Server 2006 is configured to publish a simple web site using HTTPS and within this site there is a link to download a Microsoft Word file. When external users try to download the file they receive the initial window with open or save file options as shown below:

After clicking Save the following error message appears:

The web server was listening on HTTP and an internal user connecting to the web server directly over HTTP was able to download this file. . This problem was happening on all versions of Internet Explorer regardless of the client OS platform (Windows XP, Vista and Windows 7).

2. Gathering more Data

The rule worked for the most part, only this specific condition (downloading office documents) was failing. From an ISA Server perspective, it’s always good in cases like these to get an ISA Data Packager in repro mode using Web Proxy and Web Publishing scenario. In this case it was also important to get a Network Monitor trace from the client workstation and IIS logs from the web server. This way we had the entire communication chain.

3. Analyzing

From an ISA Server perspective there were no errors in traces and live logging was also clear as shown below:

The Web Server logs also appear clear and according to netmon traces the content was transferred from the Web Server to the ISA Server:

ISA Server sends the GET request to the file:

10.20.20.2 10.20.20.25 HTTP HTTP:Request, GET /mydoc.asp

Web Server answers the request with the file:

10.20.20.25 10.20.20.2 HTTP HTTP:Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp

- Http: Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp

ProtocolVersion: HTTP/1.1

StatusCode: 200, Ok

Reason: OK

Date: Fri, 20 Nov 2009 21:20:28 GMT

Server: Microsoft-IIS/6.0

XPoweredBy: ASP.NET

Cache-control: no-cache

ContentLength: 38021

+ ContentType: application/msword

Cache-control: private

HeaderEnd: CRLF

- payload: HttpContentType = application/msword

HTTPPayloadLine:

IIS Logs from the Web Server also shows that the content was correctly answered:

2009-11-20 21:20:28 W3SVC1 10.20.20.25 GET /mydoc.asp - 82 - 10.20.20.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) 200 0 0

At this point we know that client sends the request, ISA correctly sends the request back to the web server which correctly provides the content to ISA. On the client side, Netmon just showed the encrypted conversation. In order to see what was really happening on the client side, we used HTTP Watch and there we could see that the actual content was already local as you can see in the figure below:

4. Resolution

The problem was related to the following header in the response from the web server:

10.20.20.25 10.20.20.2 HTTP HTTP:Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp

- Http: Response, HTTP/1.1, Status Code = 200, URL: /mydoc.asp

ProtocolVersion: HTTP/1.1

StatusCode: 200, Ok

Reason: OK

Date: Fri, 20 Nov 2009 21:20:28 GMT

Server: Microsoft-IIS/6.0

XPoweredBy: ASP.NET

Cache-control: no-cache

ContentLength: 38021

+ ContentType: application/msword

Cache-control: private

HeaderEnd: CRLF

- payload: HttpContentType = application/msword

HTTPPayloadLine:

Here it is the explanation why it was failing:

“In order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load. If the file is not stored to disk, this operation fails.

When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file.”

From http://support.microsoft.com/kb/316431

Although this article says it applies to IE 5 and IE6, this issue happened on IE7 and IE8. This is an expected behavior and in order to fix this you will need to follow the recommendation from KB316431. The reason why it was working internally for all users is because internally the access to this web server was using HTTP and this problem just happens when using SSL. Once more ISA was not guilty , it was only doing what the web server was asking it to do.

Author

Yuri Diogenes

Sr. Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team

Technical Reviewer

Mohit Kumar

Sr. Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team

Forefront Threat Management Gateway 2010 Release

isablog — Tue, 17 Nov 2009 09:01:40 GMT

It is our pleasure to announce that Forefront Threat Management Gateway (TMG) 2010 was released to manufacturing yesterday (Nov 16^th, 2009) after completing 3 Beta releases and receiving extensive customer feedback. The trial version is available for download today, and the product will be widely available for purchase soon.

We encourage you to download the new release and evaluate it in your environment. Forefront TMG provides an unparalleled value to the network security marketplace by integrating multiple web security technologies into a single, comprehensive solution. Forefront TMG is also all about “the basics” to ensure that besides the breadth of new features, Forefront TMG also provides the best infrastructure to run those features: reliability, scalability, performance and security. I would also like to take this opportunity and personally thank the very active user community in providing feedback throughout the cycle. Your support in downloading, deploying early versions and providing feedback was essential for us in the process of creating this product. We have incorporated significant parts of this feedback into the product, which is important in the process of making a great product.

In the following sections I will list some of the new functionality that we have added into TMG and will cover some of our infrastructure investments.

Secure Web Gateway
Forefront TMG is a Secure Web Gateway (SWG) that improves security enforcement by integrating multiple detection technologies such as URL filtering, Anti Malware, and intrusion prevention into a single, easy-to-manage solution. We have seen a lot of interest in the features that comprise this solution, so here is some information on what they do and how:

URL Filtering: URL Filtering allows controlling end-user access to Web sites, protecting the organization by denying access to known malicious sites and to sites displaying inappropriate or nonproductive materials, based on URL categories. TMG features over 80 URL categories including security-oriented categories, productivity-oriented and liability-oriented categories. Forefront TMG uses Microsoft Reputation Services (MRS), a cloud-based categorization system hosted in Microsoft data center. To ensure the best bandwidth utilization and low latency, Forefront TMG has implemented a local URL cache. There is a lot more on URL Filtering available in an earlier URL Filtering post.

Anti Malware: Stopping malware on the edge significantly decreases the possibility that a virus will hit a computer with anti-virus signatures that are not up-to-date or a test computer without an anti-virus to protect it. TMG has integrated the Microsoft Anti Malware engine to provide world class scanning and blocking capability on the edge.

Network Inspection System (NIS): NIS is a generic application protocol decode-based traffic inspection system that uses signatures of known vulnerabilities, to detect and potentially block attacks on network resources. NIS provides comprehensive protection for Microsoft network vulnerabilities, researched and developed by the Microsoft Malware Protection Center - NIS Response Team, as well as an operational signature distribution channel which enables dynamic signature snapshot distribution. NIS closes the vulnerability window between vulnerability disclosures and patch deployment from weeks to few hours.

In addition, we have introduced HTTPS scanning to enable inspection of encrypted sessions, eased the deployment and management with a set of easy to use wizards and significantly improved logging and reporting to provide full visibility into how your organization is accessing the web and whether it’s compliant with your organization’s policy.

VPN, Firewall, Email Protection and Infrastructure.
We have also made significant investments to ensure that we keep delivering top notch VPN and Firewall functionality. We made quality improvements in Web Caching and made sure it works well with the new Windows 7 BranchCache feature. We have added several new features, among them: Email Protection, ISP redundancy, NAP integration with VPN role, SSTP, VoIP traversal (SIP support), Enhanced NAT, SQL logging and Updated TMG Client (previously known as the Firewall Client). In addition TMG was built as a native 64bit product that supports Windows Server 2008 R2, and Windows Server 2008 SP2, allowing better scalability and increased reliability.

These improvements are in direct response to your requests and protection needs. We firmly believe that listening to your voice makes our product better! We are looking forward to hearing what you think about TMG 2010 as you test and deploy in your own environment. So go ahead and download it today to try it out!

Yaron Zakai-Or

Group Program Manager, Forefront TMG

Customizing the mobile device xHTML FBA page to allow password change

isablog — Mon, 16 Nov 2009 15:25:52 GMT

In this article I want to provide a quick guide, about how to modify the xHTML F(orm) B(ased) A(uthentication) page the client will receive, when it is connecting to a site published with FBA through ISA server 2006 using a mobile Client, e.g. running Windows Mobile.

Every time a client connects to the ISA server FBA site ISA server will check the HTTP Header Field “User-Agent”. Based on the information in this header ISA server will decide which HTLM form it will deliver to the client.

This behavior can be controlled by the FPCUserAgentMapping COM object, as described in the MSDN.

With this setting we want to provide the best experience for the client based on the device you use to connect to the published server.

If you’re using the Password Change Feature in your environment, you may have recognized that the password change option is not available when you connect using a mobile device by default. This is intentionally left out, as this feature is not implemented into the xHTML Form ISA delivers to the mobile device.

With ISA server 2006 we are providing the opportunity to officially customize the FBA HTML pages as described here. Providing this opportunity you can not only customize the Form to include your company logo and change the message strings you will see on the FBA page, but you can also modify the HTML code of each page.

In this article I want to provide an example on how to modify your xHTML Form to enable the Password Change Feature, e.g. for a scenario when you connect to your published Exchange OWA using a mobile device.

Important: Please be aware, that Microsoft won’t provide support if something isn’t working with the customized HTML Forms you created, including the steps described in this article. Please be aware, that Microsoft will ask you to ‘roll-back’ to the standard forms provided with ISA server for the case you need to open a service request with Microsoft. Customizing HTML Forms is a supported configuration, but Microsoft can’t support the customization itself.

Before you actually start to modify any files, you should create a new folder in the ISA installation directory CookieAuthTemplates Folder

And name it e.g. mycustom. Now copy the xHTML folder from the ISA directory to your new folder.

Important: You’ll have to create the same folder with the same content on all Array Nodes if you’re running ISA 2006 Enterprise Edition.

Any changes made in this folder will only be applied when you restart the ISA Firewall services. If you want to use this custom form in the ISA configuration, you’ll have to restart the Firewall services first. However at this point this wouldn’t make any real sense, as we didn’t modify anything yet J

In the xHTML directory we can see the different files send by ISA to the client based on the configuration applied in ISA. To achieve our goal to enable the password change, we need to modify the user_pwd.htm.

Please open the file in a text editor and search for the lines:

<img src="/CookieAuth.dll?GetPic?formdir=@@FORMDIR&image=mslogo.gif" alt=""/>

<br />

In the body part of the code.

And insert the following lines:

<p>

<label for="chpwd">@@L_RequestPwdChange_Text</label><br />

<input id="chpwd" name="chpwd" type="checkbox" class="rdo" onclick="clkChpwd()" />

</p>

Save the file. If you open the file in a browser it should look like this:

When the checkbox is ticked, it will call the clkChpwd() Method, which triggers that the password change page will be send to the client.

After you saved the file, make sure to copy the directory to all array members if you’re running the Enterprise Edition and restart the firewall service on all array nodes.

In order to use this custom html form you got two choices:

1. Configure the setting directly on the listener being used for the publishing rule:

Open the listener properties and select the ‘Forms’ tab. Tick ‘Use customized HTML forms instead of default’. Enter ‘mycustom’ in the text field and tick ‘Allow users to change their passwords’:

2. Configure the setting in the publishing rule:

Open the publishing rule and select the ‘Application Settings’ Tab. Tick the checkbox and add ‘mycustom’ to the text field:

Don’t forget to enable the Allow users to change their passwords in the listener properties in any case.

Please be aware, that all clients which don’t match the user agent to which ISA server will deliver the xHTML files you will see the standard pages configured in the ISA CookieAuthTemplates folder.

Feel free to copy and modify the HTML and cHTML folder from the ISA or Exchange folder to your mycustom folder, to create a customized experience for your users.

Happy customizing :)

Author

Philipp Sand

Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Thomas Detzner

Microsoft CSS Forefront Security Edge Team

Email Protection in Forefront TMG 2010 Release Candidate

isablog — Tue, 10 Nov 2009 10:44:02 GMT

Hello Community: As you probably know, Forefront TMG introduced the E-mail Protection feature in Beta 3. Since then we’ve made significant improvements based on our plans and your feedback.

I’d like to go over the basics of installing Forefront TMG and the additional components necessary for e-mail protection, and point you to the relevant links where you can extend your knowledge on this great feature.

But first, what is the E-mail Protection feature?

The E-mail Protection feature provides central management for Microsoft Exchange Edge and Forefront Protection for Exchange when located on the same server with Forefront TMG. The feature provides e-mail protection at the edge with array support and allows firewall administrators to manage and deploy SMTP, antispam and anti-malware policies on the edge, so that the organization will be able to protect itself from malicious e-mail messages and spam. The feature also allows administrators to configure Exchange Edge Subscriptions for the entire array using a couple of wizards.

This feature is leveraging two best-of-breed Microsoft products — Microsoft Exchange Edge Transport, and Microsoft Forefront Protection for Exchange — that offer a great SMTP experience while maintaining security throughout for SMTP traffic. To take advantage of this feature, you need to install both of these products on all of the Forefront TMG servers in your array.

What’s new in E-mail Protection since Forefront TMG Beta 3

In release candidate (RC) release, we added the following enhancements:

1. Edge Subscription support – Configuring an Edge Subscription in Exchange Edge through Forefront TMG is simpler than ever:

a. Use the E-mail Policy Wizard to allow Edge traffic on Forefront TMG.

b. Create the subscription files with a click: “Generate Edge Subscription Files”.

c. Import the files to the Exchange Hub server, and that’s it! The subscription is up and running.

2. Flexible installation time – In Beta 3, you needed to install the Edge Transport role and Forefront Protection for Exchange 2010 (the prerequisites) before installing Forefront TMG on the server. Today you can install E-mail Protection prerequisites before or after deploying Forefront TMG.

3. Route authentication configuration – we’ve added authentication configuration support through the Forefront TMG UI. Simply right-click on the relevant SMTP route, select Properties, and set the authentication method.

4. Support for IP block/allow list providers, authentication, automatic tracking for Exchange/FPES licensing expiration, Exchange/FPES services monitoring (in the services pane and alerts are generated in case of a problem) and a few more features.

5. Several adjustments that were made in response to customer feedback.

How do I plan and deploy the feature?

Forefront TMG has comprehensive guides on planning and deploying the E-mail Protection feature:

1. The planning guide can be found here: http://technet.microsoft.com/en-us/library/dd897005.aspx.

2. A guide to the prerequisites you need to install prior to configuring E-mail Protection can be found here: http://technet.microsoft.com/en-us/library/ee207141.aspx.

3. You can learn how to configure E-mail Protection here: http://technet.microsoft.com/en-us/library/dd441084.aspx.

4. To learn more about Edge Subscriptions, please follow this link: http://technet.microsoft.com/en-us/library/aa997438.aspx.

5. Some information on what happens “behind the scenes” can be found in Understanding E-Mail Protection on Forefront TMG

6. How to implement and use Edge Subscriptions properly can be found in Using Mail Protection with Exchange EdgeSync on Forefront TMG

Q & A

1. Which versions of Microsoft Exchange and Forefront Protection for Exchange are supported in Forefront TMG?

In the table below you can find the support matrix:

Product	Windows Server 2008 (SP2)	Windows Server 2008 R2
Microsoft Exchange Edge 2007 SP2	+	-*
Microsoft Exchange Edge 2010	+	+
Forefront Protection for Exchange 2010	+	+
Forefront TMG	+	+

* Recently a blog post was published by the Exchange team saying that they reconsidered and are planning to support Windows Server 2008 (SP2). To read more about it please follow this link: http://msexchangeteam.com/archive/2009/11/04/453026.aspx

2. What licenses do I need to have in order to deploy the E-mail Protection feature?

In addition to the Forefront TMG 2010 license, you will need to purchase two other licenses: one for Microsoft Exchange Edge, and another for Forefront Protection for Exchange 2010. More on licensing can be found here:

· Microsoft Exchange 2010 licensing information can be found here: http://www.microsoft.com/exchange/2010/en/us/Licensing.aspx

· Forefront Protection for Exchange 2010 licensing information can be found here: http://www.microsoft.com/forefront/protection-for-exchange/en/us/pricing-licensing.aspx

Noam Ilovich

Program Manager, Forefront Threat Management Gateway

TMG Customer ID for Reputation Services

isablog — Sun, 08 Nov 2009 13:26:00 GMT

In a previous blog entry, we announced the availability of the Microsoft Reputation Services Feedback and Error Reporting Portal (beta). The portal’s purpose is to allow anyone the ability to provide feedback to Microsoft on URL classifications. When a block page is presented to the end user, Forefront TMG includes a link offering the opportunity to report the URL to Microsoft as misclassified. Users who click the link will be directed to the MRS Feedback and Error Reporting portal.

Customers may also manually select to report a URL to Microsoft Reputation Services as incorrectly categorized. To submit this URL to the MRS, TMG constructs a parameterized query string which includes a ‘CustomerID’, as shown below to identify the submission as originating from the Forefront Threat Management Gateway 2010 product.

The ‘CustomerID’ is a hard-coded value that is specific to the TMG 2010 product and is the identical for all installations and all customers. It is not and cannot be used to uniquely identify a specific installation, customer or usage. This parameter is only used to inform MRS servers that the request originates from a Forefront TMG product. The data provided from Forefront TMG is important telemetry to improve the MRS service and hence has a specific mechanism to identify the TMG product usage. To learn more about the Forefront TMG privacy, we encourage you to read the TMG privacy statement.

Author: Dotan Elharrar, Program Manager, Microsoft Forefront TMG

Reviewers: David Cross, Brita Jenquin, Joel Sider, Nathan Bigman

Forefront TMG Client

isablog — Tue, 03 Nov 2009 15:44:24 GMT

Hello Everyone:

I would like to introduce the new Forefront TMG Client (formerly known as Firewall Client).

As you might have noticed, we have changed the component’s name. This was done in order to emphasize the point that it is part of the Forefront family of products.

New functionality added:

HTTPS Inspection notification: When a user visits an HTTPS site and Forefront TMG HTTPS Inspection is configured to notify users that HTTPS inspection is applied, the Forefront TMG Client will display a message balloon notifying the user that the SSL traffic is being inspected. (This feature can be disabled on the Forefront TMG server or on the Forefront TMG client)

AD Marker Support: Forefront TMG Client now supports a more secure method of automatically discovering the Forefront TMG server by querying Active Directory. In addition, the new mechanism allows the administrator to configure different Forefront TMG servers for different Active Directory sites, thus improving the connectivity experience by allowing the Forefront TMG client to use the closest Forefront TMG server.
Note: by default, when the AD Marker is not available, the client will revert to the old methods. This behavior is configurable in the Forefront TMG Client control panel applet.

Forefront TMG Client will continue to support the following features:

Group- or User-based policies based for non-Web proxy TCP and UDP traffic.
Support for complex protocols without the need for an application filter.
Simplify routing configuration for large organizations.
Auto discovery, done by fetching the information from, DNS, WINS or DHCP servers

Please use the following tables to determine scenario and compatibility support limitations.

Operating system support

The following table summarizes the operating system support for Forefront TMG Client and Firewall client software.

Operating system	Forefront TMG Client	Firewall Client 2006 (Downloadable Version)	Firewall Client 2004	Firewall Client 2000
Windows® 7 /Windows Server 2008	Supported	Supported	Not supported	Not supported
Windows Vista (all service packs)	Supported	Supported	Not supported	Not supported
Windows Server 2003 with Service Pack 1 (SP1)	Supported	Supported	Supported	Supported
Windows XP (all service packs)	Supported	Supported	Supported	Supported
Windows 2000	Not supported	Supported	Supported	Supported

Client / Server Compatibility

The following table summarizes compatibility between Forefront TMG and ISA servers, and Forefront TMG and ISA clients.

	Forefront TMG server	TMG MBE	ISA Server 2006	ISA Server 2004	ISA Server 2000
Forefront TMG Client	Compatible	Compatible	Compatible	Compatible	Not Compatible
Firewall Client 2006	Compatible	Compatible	Compatible	Compatible	Compatible
Firewall Client 2004	Compatible	Compatible	Compatible	Compatible	Compatible
Firewall Client 2000	Not compatible	Not compatible	Compatible	Compatible	Compatible

Written by: Alon Yardeni, Program Manager

Reviewed by: Jim Harrison, Meir Feinberg, and Yaron Zakai Or.

Creating a Web Access Policy for Your Organization

isablog — Tue, 03 Nov 2009 07:52:21 GMT

Forefront TMG introduces the Web Access Policy Wizard to help you create Web access rules and Web protection settings for your organization. You can launch the wizard from the completion page of the Getting Started wizard, or by navigating to the Web Access Policy node and selecting the Configure Web Access Policy option.

Note that in ISA Server 2004 and 2006, default access rules were created based on the policy selection in the Network Templates wizard. In Forefront TMG, the access rules are now created using the Web Access Policy Wizard, allowing you to configure rule properties and Web protection feature settings. All settings configured using the Web Access Policy wizard can be modified after completing the wizard, using the property pages.

Creating Default Web Access Policy Rules

When you run the Web Access Policy Wizard, a default rule allowing Web access from clients on the Internal network to the Internet is created for you. Based on your selections in the wizard, a default blocking rule may also be created and Web protection features, such as URL filtering, are enabled and applied.

The Web Access Policy Rules page lets you select if you want URL categories deemed harmful to the productivity or security of your organization automatically included in the default Blocked Web Destinations rule, or if you prefer to create the rule yourself.

Regardless of which option you choose in this page, the Blocked Web Destinations page, used to create the blocking rule will display when you click Next.

The rule will block access to all Web destinations listed in this page.

If you selected to have the rule created for you, a list of blocked URL categories is populated for you. If you selected no, the list is not populated.

Use the options provided to add or modify the list.

Note that if no destinations added to the list, the blocking rule will not be created.

By default, the Blocked Web Destinations rule is applied to all users. The Blocked Web Destinations Exceptions page lets you specify users or groups for whom the rule should not be applied.

Configuring Web Protection Features

After creating the default rules, you can configure Forefront TMG to inspect content requested from the Internet for malware such as viruses and spyware.

Configuring Malware Inspection Settings

The Malware Inspection Settings page lets you enable the Malware Inspection feature and apply the global settings for this feature.

You can view and modify global malware inspection settings, such as the content delivery method, in the Malware Inspection property pages after completing the wizard. You can also configure rule-specific settings for each access rule for which malware inspection is enabled.

Configuring HTTPS Inspection Settings

The HTTPS Inspection Settings page lets you specify if HTTPS connections are allowed and define how HTTPS inspection is applied to HTTPS traffic. If you select to allow HTTPS connections, the HTTPS protocol is added to the default allow rule.

Depending on the certificate option you select, additional settings are provided.

After completing the wizard, you can use the HTTPS inspection property pages to define any sites exempt from HTTPS inspection and to specify if certification validation should be applied.

Enabling Web Caching

The final step in the wizard is to create and enable the default Web caching rule and define the default cache drive.

The completion page shows the settings that will be applied. Based on these settings, Web protection features are enabled and the default Web access policy rules are created.

Viewing the Policy Rules and Settings

When you click Finish to complete the wizard, the Web access settings and rules are shown in the Web Access Policy results pane. You can view and modify the rule settings by opening the rule properties (either by double-clicking on a rule, or using the right-click menu). You can view and configure Web protection settings using the links in the Web Access Settings pane to open the corresponding property pages. Links to these property pages are also accessible from the Web Access Policy toolbar and the tasks pane.

The rules created in the Web Access Policy node are also listed in the Firewall Policy rules list. You can view and edit rule settings in either location.

Frequently Asked Questions

Q: How do I add other access rules to the Web Access Policy Group?

A: Selecting the group header, or a rule in the group, and then creating the new rule will put the rule into the group. You can also use the ungroup and move up or move down options available by right-clicking on a group header or rule to move rules around. Note that it is not necessary to add access rules created manually to this group. Rules are processed in order, regardless of groupings.

Q: How do I know if URL filtering is enabled? I don’t remember enabling it in the Web Access Policy wizard.

URL filtering is enabled automatically when URL categories are selected in the default blocking rule. The feature may also be enabled when running the Getting Started Wizard. You can view the URL filtering properties and settings by clicking the Configure URL Filtering option in the toolbar or tasks pane.

Q: What is the difference between the Web Access Policy group in the Firewall Policy node and the Web Access Policy group in the Web Access Policy node?

A: There is no difference. These are the same rules and can be edited in both places.

Q: What is the difference between the Create Access Rule option in the Web Access Policy node and the Create Access Rule option in the Firewall Policy node?

A: Both options launch the same Create Access Rule wizard. However, when launched from the Web Access Policy node, the HTTP and HTTPS protocols are preselected for you. You can add or remove protocols when running the wizard from either location.

Written by: Linda Lior

Edited by: Meir Feinberg

Management Pack for Forefront Threat Management Gateway 2010 Release Candidate Now Available

isablog — Mon, 02 Nov 2009 10:37:00 GMT

We are happy to announce the availability of the Management Pack (MP) for the Forefront Threat Management Gateway (TMG) 2010 Release Candidate. As a response to your feedback, we enhanced the management pack, to increase its coverage and usability.

While the previous release monitored and managed some of Forefront TMG’s features, we are now monitoring and managing all Forefront TMG features. We added discoveries (automatic detection mechanisms) of the new features, their state and events in Forefront TMG 2010 and made significant improvements to increase the usability and productivity of the MP. These changes are detailed below.

Discoveries: We added new discoveries to support all of Forefront TMG’s new features. TMG discoveries detect the activated features across arrays and constantly monitor your configuration to detect changes. For example, if the administrator joins a new server to the array it will be detected automatically and displayed, or if the administrator activates a new feature (like HTTPSi) it will be automatically monitored.

Visibility: To increase the visibility of your topologies, we extended our topology coverage to add automatically generated array/enterprise topology views. This simplifies your ability to understand which components (roles) are enabled and how Forefront TMG is deployed in your organization from a single, simple node deployment up to complex, multi-node deployments.

Topology View
(Two arrays are displayed – “HTTPSi” and “SWG”)

The image above provides a clear view of a typical enterprise deployment including an EMS server (named StageEMS1), two arrays (named “HTTPSi” and “SWG”), each of the arrays has a firewall connected to it (StageTMG1 and StageTMG2 respectively). The red X marks show there are problems in the servers and the administrator can drill down and see the relevant detected components and figure out which one is failing.

The image below shows the detected components in one of the servers (Malware inspection, NIS, HTTPS Inspection, URL filtering and VPN). All components are working as expected and no events were detected up to now. The admin can expand the critical events to see which components have critical events:

Installed Roles View
(The following roles are installed: Malware inspection, NIS, Publishing (HTTPSi), URL Filtering, VPN)

Events: To make sure our customers get the most accurate notifications with a minimal level of false alarms, we’ve remodeled the MP and made sure we have more granular discoveries that match each of the relevant components (features) exposed through Forefront TMG. Each component has a discovered state and by creating aggregated events we are passing them along to the enterprise level so that the admin can easily understand the current status and follow the failure path - both in the topology view and/or through the list of installed components.

Performance Counters: In addition to the new events, we’ve added a new set of performance counters off the shelf to support additional monitoring. They are not enabled out-of-the-box to save bandwidth and assure faster response. These can be accessed through the performance node.

Compatibility: The new MP is compatible both with Microsoft System Center Operations Manager 2007 and Microsoft System Center Operations Manager 2007 R2, but we recommend that you use the Microsoft System Center Operations Manager 2007 R2 for better performance and easier customization.

This is the most usable, powerful and feature rich management pack produced for Forefront TMG 2010. You are welcome to download it to try it out.

Author: Noam Ilovich, Program Manager, Microsoft Forefront TMG

Reviewers: Nathan Bigman, Vladimir Holostov, Alon Yardeni

Issues after updating the ISA Management console on a Windows Vista/7 client

isablog — Fri, 30 Oct 2009 12:18:52 GMT

Issues after updating the ISA Management console on a Windows Vista/7 client

If you start the Management console after installing an ISA update or service pack, regardless if you updated it via Windows Update or by manually downloading/installing a hotfix, you may the following Error Message:

Looking in the Application Event log on your client you’ll see an event similar to this:

Log Name: Application

Source: MsiInstaller

Event ID: 1004

Level: Warning

Description:

Detection of product '{DD4CEE59-5192-4CE1-8AFA-1CFA8EB37209}', feature 'MSFirewall_Management', component '{741C7C93-4289-4B2E-98BA-F9DB44DA0E36}' failed. The resource 'C:\Program Files\Microsoft ISA Server\License_SP1_EE.rtf' does not exist.

When checking the File System, we can see that the file is actually there. But while checking if the file exists, you will see, that you’ll be prompted when trying to access the ISA installation folder:

This prompt didn’t occur before you installed the update.

If you try to open the Management console now, you’ll also realize, that it will actually start like magic ;-)

CAUSE:

Before you install the update, the permissions on the ISA installation folder look like this:

Afterwards the permissions for the Authenticated Users group are gone, that’s why the Management console won’t start properly.

WORKAROUND:

Please make sure to add the read permissions for the ‘Authenticated Users’ after installing any update for the Management console your management client. With this workaround you won’t have any issues starting the Management Console.

APPLIES TO:

This issue applies to ISA 2004 Enterprise Edition, ISA 2006 Standard and ISA 2006 Enterprise Edition MMCs, installed on Windows 7 or Windows Vista.

TMG and ISA 2004 Standard Edition Management Consoles are not affected.

Author

Philipp Sand

Microsoft CSS Forefront Security Edge Team

Technical Reviewers

Jonathan Barner

ISA/TMG Sustained Engineering Team

Forefront TMG and BranchCache: Which should I deploy in my organization?

isablog — Mon, 26 Oct 2009 15:06:19 GMT

Branch offices are often connected to a corporate headquarters or corporate data center to access Line of Business (LOB) applications via a WAN link. Depending on the deployment, branch offices may connect directly to the Internet, or indirectly via the WAN link. WAN links can be slow, so organizations often look for ways to optimize their WAN utilization and improve the effectiveness and user-experience of users in the branch.

Forefront TMG optimizes branch office Internet traffic by applying caching and compression. Windows 7 and Windows Server 2008 R2 introduce BranchCache, which optimizes LOB HTTP applications and file-access traffic via caching. This post lists various aspects that describe how Forefront TMG and BranchCache provide improved WAN-link utilization. By considering those aspects, organizations can select the solution that best serves their specific needs. In many cases the best solution will actually be to deploy both!

	BranchCache	Forefront TMG
Protocol support	HTTP, HTTPS and SMB2	HTTP
Caches access restricted or encrypted content	BranchCache securely caches access-restricted content and content sent over encrypted channels. It works seamlessly with network security technologies, including SSL, SMB signing, and IPSec – even when the content is encrypted - without compromising access restriction or privacy.	No
Compression	BranchCache-enabled servers deliver a compact description of the actual data. BranchCache-enabled clients use this compact description to lookup and retrieve the locally cached data.	Optionally applies GZIP compression (and decompression) of HTTP traffic. GZIP is very effective for textual data, and least effective for most media data. Compression can be set per source or destination.
(related note)	The first two requests from a BranchCache-enabled server are served full data.	In TMG data is cached after the first request.
Distributed Cache	Supports both distributed (peer-to-peer) and central (HostedCache) caching. Using BranchCache does not require a deployment of a cache server at the branch	To provide caching capabilities in a branch, Forefront TMG must be deployed in the branch.
Supported Server OS	Accelerates applications running on Windows Server 2008 R2 via caching. You can optimize delivery of published content from LOB applications running Windows Server 2008 R2 by enabling BranchCache on these servers. BranchCache is not available on earlier Windows Server releases	Caches content from any server
Supported Client OS	Supports clients running Windows 7 and Windows Server 2008 R2	Delivers cached content to any client
Cache management	Provides monitoring via performance counters.	Provides extended cache management capabilities. For example, you can define what content should or should not be cached. You can also monitor the cache behavior, through Forefront TMG logging and reporting modules.
Pre-fetching	No	Yes. Download content jobs can be defined and run overnight to pre-fetch content during idle hours.
Content Inspection	No	Yes. Provides advanced Web-access protection via URL filtering, malware inspection and even HTTPS inspection. In addition to providing cache capabilities, Forefront TMG is an edge firewall. As such, it can apply corporate security policies (for example limit access to specific applications or destinations by specific users, groups or source network, at specified times).

Frequently asked questions:

Q1: I want to deploy both Forefront TMG and BranchCache Hosted Cache in a branch office. Can they be deployed on the same host to save hardware, software and management cost?

Yes, Forefront TMG and BranchCache can be deployed on the same Windows Server 2008 R2 host. You will need to add Forefront TMG policy rules that allow BranchCache-specific traffic (e.g. retrieval of cached objects from BranchCache) to and from the host. In the near future, we will issue a special administrator guide that describes step by step how to deploy Forefront TMG and BranchCache hosted cache on the same host. We’ll announce it on the team blog.

Q2: I already have Forefront TMG deployed in a branch office as a firewall, separating the branch office network from the corporate network. I intend to deploy Windows 7 clients in the branch, and enable BranchCache in distributed mode. Should I apply a special policy to allow BranchCache traffic through Forefront TMG to the corporate network?

No special policy is required to enable BranchCache traversal across Forefront TMG. Regular LOB HTTP, HTTPS and SMB2 traffic between the branch office and the corporate network must be allowed via Forefront TMG policy rules. Forefront TMG will recognize BranchCache and allows its traffic as part of the regular LOB traffic, within that policy.

Q3: Is there any other kind of interference between Forefront TMG and BranchCache that I need to be aware of?

As a Secure Web Access Gateway and as a firewall, Forefront TMG inspects all the traffic that passes through it. While that essentially increases latency, combining Forefront TMG with BranchCache implies that there will be less traffic to inspect, because cached data is inspected once for all subsequent uses. Thus, both security and performance may be improved.

Q4: I have more questions about BranchCache. Where can I find more information?

http://www.branchcache.com .

Authors: Adi Kurtz and Yossi Siles

Reviewers: Ravi Rao, Eliot Flannery, Nilesh Shah, David Strausberg, Neta Amit, Alon Yardeni

Error 500 “Not Supported” while browsing Internet through ISA Server 2006

isablog — Sun, 25 Oct 2009 15:27:00 GMT

1. Introduction

This post is about a specific condition that can triggers the “Not Supported” error while browsing some web sites through ISA Server. The error message that the end users receives is similar to the one shown below:

The ISA Diagnostic Logging will not say much beyond that but if you enable you can see the following error:

ISA Server rejected the request with the HTTP status code 0 and will return the following error message to the Web client. \""The request is not supported. \"""

9/30/2009 1:25:21 PM ISA Server Diagnostics Information None 30107 N/A SRVISA "Date and time: 09/30/2009-14:25:21.039

Packet context: 0cc48f30 0cc4908e

Log source: Web Proxy

The data gathering for this scenario should be done by using ISA Data Packager in repro mode with the Web Proxy & Web Publishing template.

2. Understanding the Behavior

The condition that triggers this specific error can happens when the client workstation sends a HTTP GET request that doesn’t say that the content can be encoded and the destination server responds with the Content-Encoding header in the HTTP Response. Here it is a sample of this trace:

1) Client sends the request to access a web page through ISA Server:

2009-09-30 16:24:02.187193 ISAExternalNIC DestinationWebSRV HTTP GET /shopping/navigate.do?catg=5328 HTTP/1.1

Hypertext Transfer Protocol

GET /shopping/navigate.do?catg=5328 HTTP/1.1\r\n

Request Method: GET

Request URI: /shopping/navigate.do?catg=5328

Request Version: HTTP/1.1

Via: 1.1 ISACONTOSO\r\n

Cookie:

2) Destination Web Server responds with:

2009-09-30 16:24:02.484068 DestinationWebSRV ISAExternalNIC HTTP HTTP/1.1 302 Moved Temporarily (text/html)

Hypertext Transfer Protocol

HTTP/1.1 302 Moved Temporarily\r\n

Request Version: HTTP/1.1

Response Code: 302

Server: WEB_Server\r\n

Location: http://www.fabrikam.com/shopping/navigate.do?catg=607\r\n

Content-Encoding: gzip\r\n

Content-Type: text/html;charset=UTF-8\r\n

Content-Language: en-US\r\n

Date: Wed, 30 Sep 2009 20:24:01 GMT\r\n

Transfer-Encoding: chunked\r\n

Connection: keep-alive\r\n

Connection: Transfer-Encoding\r\n

\r\n

HTTP chunked response

After that ISA resets the request and shows the error message (“The request is not supported”) to the client. This specific behavior happens when the compression filters (compression filter/caching compressed content Filter) are disabled. The compression filters will block the request since the client did not indicate in the request message that it does support gzip compression. Since the web server returned the content compressed the ISA server needs to discard the request.

3. How to change this Behavior?

This behavior can be changed by executing the script showed in KB927263 for forward proxy scenario that matches this condition when those filters are disabled. If the scenario is reverser proxy then you can use SendAcceptEncodingHeader property.

Authors

Yuri Diogenes

Sr Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team

Thomas Detzner

Escalation Engineer

Microsoft CSS Forefront Edge Team

TMG Client introduces automatic detection using Active Directory

isablog — Thu, 22 Oct 2009 23:04:00 GMT

1. Introduction

The new TMG Client that is available on TMG 2010 is now capable of performing automatic discovery using a record that resides on Active Directory. TMG Client still able to use the traditional methods (DHCP / DNS) for automatic discovery, the difference now is that if both options are enabled on UI (see Figure 1) the auto detection will take effect using the following flow:

1. TMG Client will first try to retrieve information from Active Directory using LDAP query.

2. If TMG Client is unable to retrieve that information due to an error with the connection, it won’t failover to DHCP / DNS automatic detection methods for security reasons. This reduces the risk that an attacker might try to force fallback to a less secure method by affecting Active Directory marker availability. Active Directory discovery is considered more secure than DHCP/DNS methods.

3. In case that the connection succeeded to Active Directory but no information was found the TMG Client will failover to DHCP and then to DNS.

Figure 1 – TMG Client

In order to configure Active Directory to support that you should use the TMG Auto-Discovery Configuration Tool (TmgAdConfig.exe). This tool configures an Active Directory with a marker key that points to your Forefront TMG server. This key is going to be used by the TMG Client to locate the Forefront TMG server and connect to it.

Note: Active Directory-based auto detection works only for computers that are members of a domain. Use of AD Marker in workgroups is not supported.

2. Using TMGADConfig Tool

You can download the TMG AD Config Tool from Microsoft Download Center (look for the AdConfigPack.EXE). After download and install on TMG you can execute the following command line in order to register the AD marker key:

tmgadconfig add -default -type winsock -url http://ftmgfw.contoso.com:8080/wspad.dat

Forefront TMG Auto-Discovery Configuration Tool

New Winsock default marker successfully registered.

Note: to see more switches for this command used TMGAdConfig /?

The highlighted part is the one that will change according to the TMG’s FQDN and also the port used by TMG. When you run this command line TMG will send an LDAP request to the Domain Controller asking for the registration of this marker key. Here it is a sample of the LDAP traffic caused by this execution of this command line:

Figure 2 – Typical LDAP Traffic (click here to enlarge this picture).

Note: on this example TMG is 10.10.10.69 and the DC is 10.10.10.10

The LDAP search that is marked in the above traffic sample is exactly the location where this marker will be registered. If you use LDP.EXE you can browse through the location shown below:

Figure 3 – LDP Tool result.

When accessing this location, the right panel should show the value that has the TMG AD Marker that was registered as shown below:

Expanding base 'CN=Winsock Proxy,CN=Internet Gateway,CN=Services,CN=Configuration,DC=contoso,DC=com'...

Getting 1 entries:

Dn: CN=Winsock Proxy,CN=Internet Gateway,CN=Services,CN=Configuration,DC=contoso,DC=com

cn: Winsock Proxy;

distinguishedName: CN=Winsock Proxy,CN=Internet Gateway,CN=Services,CN=Configuration,DC=contoso,DC=com;

dSCorePropagationData: 0x0 = ( );

instanceType: 0x4 = ( WRITE );

keywords (2): Winsock Proxy; ISAServer;

name: Winsock Proxy;

objectCategory: CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=contoso,DC=com;

objectClass (4): top; leaf; connectionPoint; serviceConnectionPoint;

objectGUID: a87cf902-1b5a-4532-a9cb-bef8dd663fed;

serviceBindingInformation: http://ftmgfw.contoso.com:8080/wspad.dat;

serviceClassName: Winsock Proxy Service;

showInAdvancedViewOnly: TRUE;

uSNChanged: 496989;

uSNCreated: 496988;

whenChanged: 10/22/2009 9:08:54 AM Pacific Daylight Time;

whenCreated: 10/22/2009 9:08:53 AM Pacific Daylight Time;

3. Testing Client Configuration

To test the configuration on the client side you can use the FWCTool that comes with TMG Client, which is installed by default in %programfiles%\Forefront TMG Client folder. Follow the steps below to perform this test:

1. On the client workstation, open command.

2. Navigate to the location where TMG Client is installed.

3. Run the command fwctool TestAutoDetect

Here it is an output sample of this command when perform all tests successfully:

FwcTool version 7.0.7733.100

Forefront TMG Client support tool

Action: Test the auto detection mechanism

Type: Default

Detection details:

Timeout is set to 60 seconds

Locating WSPAD URL on the Active Directory server

WSPAD object was found in the global Active Directory container

WSPAD URL found on the Active Directory server:

http://ftmgfw.contoso.com:8080/wspad.dat

Initializing Web server connection

Resolving IP addresses for ftmgfw.contoso.com

Resolved 1 address(es):

10.10.10.69

Connecting to address #1: 10.10.10.69:8080

Waiting for address #1 to connect

Address #1 successfully connected

Requesting wspad.dat file

Web server is connected and ready to send WSPAD file

Downloading WSPAD file

WSPAD file was downloaded successfully

Detected Forefront TMG: FTMGFW:1745

Result: The command completed successfully.

The highlighted text above is your confirmation that the AD registration was correctly found by the TMG Client.

Author

Yuri Diogenes

Sr Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team

Technical Reviewers

Bala Natarajan

Sr Security Support Escalation Engineer

Microsoft CSS Forefront TMG Beta Team

Eric Detoc

Escalation Engineer

Microsoft CSS Forefront TMG Beta Team

Forefront TMG is SIP-aware

isablog — Wed, 21 Oct 2009 15:52:51 GMT

Introduction

Voice over IP (VoIP) communications are transmitted via the internet and therefore need to be allowed to pass through your firewall.

A basic VoIP call is based on Session Initiation Protocol (SIP), which is the most common protocol used today. A SIP VoIP call is carried out using User Datagram Protocol (UDP), and incorporates two protocols: Session Initiation Protocol (SIP) for call establishment and termination, and Real Time Protocol (RTP) for media (audio and/or video). SIP can also be carried out using Transmission Control Protocol (TCP) but for the purpose of this post I will refer to SIP carried out using UDP.

Every RTP stream uses two connections, one for media and one for control data. The control data protocol is called RTP Control Protocol (RTCP) and is used to provide feedback on QoS in the media stream by periodically sending statistical information.

Basic SIP deployments supported by the SIP filter

A VoIP call requires a minimum of three opened connections, one for SIP and two or more for media. Since the media ports are usually selected dynamically by the phone, the firewall needs to understand SIP in order to open and close the media connections.

In Forefront TMG, we have developed a SIP filter to manage the opening and closing of the media connections automatically, based on the SIP transactions between allowed endpoints. The filter also checks quota, thus preventing DoS attacks by ensuring that only a configurable number of calls or registrations is allowed by the firewall.

Configuring VoIP with the Forefront TMG SIP filter is very easy and straightforward. We have divided the VoIP deployments into two main scenarios:

1. Centrex - In the diagram below we see a deployment where the organization doesn’t own a PBX.The phones in the organization are connected to the VoIP service provider. This scenario is most commonly referred to as a SIP Centrex.

Centrex deployment requires the filter to ensure that all the phones in the organization can access the VoIP provider and vice versa.

2. SIP trunk - In the diagram below we see a deployment where the organization does own a PBX, which is located in a different segment than the phones, and the organization’s phones are connected directly to the PBX. You can also see that the PBX is connected to a VoIP service provider for long distance calls termination.

SIP Trunk deployment requires the filter to ensure that all the phones in and out of the organization can access the PBX, and that the PBX can access the SIP Trunk proxy.

Obviously the deployments are different in most offices but when you break them down you will see that the base is one of the two deployments I mentioned here.

To start configuring your VoIP deployments using the VoIP wizard click the “configure VoIP” button

Enjoy,

Yariv Trabelsi

Senior Software Development Engineer

Reviewers: Rachel Aldam, Shimon Yannay, Nir Katz

Common Problems while Implementing HTTPS Inspection on Forefront TMG 2010 RC

isablog — Mon, 19 Oct 2009 18:08:00 GMT

1. Introduction

The HTTPS Inspection feature on TMG 2010 can protect internal client workstation from accessing non legitimate HTTPS web sites. The whole idea is to avoid that client open a SSL tunnel with the destination server and the content that pass through this tunnel not being inspected, causing a potential way for malicious code to pass through and reach the client workstation.

The goal of this post is to explain the most common scenarios where client workstation might have issues when HTTPS Inspection is implemented on TMG 2010.

Note: For the implementation steps use the TMG Documentation page at Microsoft TechNet for more details.

2. Understanding the Inspection Process

In order to address the most common problems while implementing HTTPS inspection you need to understand how the HTTPS inspection works. The basic flow process happens as shown below:

Figure 1 – Basic HTTPS Inspection Flow

1) TMG reads configuration from storage via the configuration manager. This includes reading HTTPS inspection CA certificate. Configuration manager is a class implemented in msphlpr.dll module – this module is loaded in Firewall service memory space.

2) Client initiates connection (HTTP CONNECT request for full proxy, TCP server:443 for transparent client).

3) TMG makes SSL handshake with the destination server.

4) TMG checks server certificate according to HTTPS inspection configuration (certificate policy and exclusion checks) and works as follows:

a. Site should be blocked – send error page to client (full proxy clients will show it)

b. Site belongs to the exclusion list – close the connection with server and opens a new one, sends “200 Connected” to client (for full proxy clients). Client and server make SSL handshake and continue regular SSL.

c. Site is inspected and not blocked – make SSL handshake with client.

5) TMG makes SSL handshake with the client workstation.

The options that govern the inspection process can change according to the settings that you choose for your HTTPS inspection. For example: the certification validation process can perform the tests specified in the figure below, however it is up to the administrator which options he wants to select or not:

Figure 2 – Certification validation policy

There are some other checks that are not exposed in the UI, such as:

· Name mismatch

· Server certificate is not trusted

· Server certificate type (if it is not for server authentication for example)

3. Common Problems

Any security measure that is implemented in an enterprise can cause side effects that can raise questions from the end users about why something that was possible in the past is not working anymore. End users may assume that because the browser uses HTTPS to connect to the site, the connection is secure, which it is not a fully true statement since the web site can be using a bogus certificate or contain malicious code.

While the HTTPS inspection can protect internal clients from accessing suspicious sites that uses HTTPS, it can also cause end users to complain that they are unable to access some HTTPS web sites. This can indeed happen in some scenarios, such as the ones that will be explained below:

Question 1) I’m trying to browse a HTTPS web site and I’m receiving an error saying: The page cannot be displayed - Error Code 502 (Proxy Error) – the certification authority that issued the SSL Server certificate supplied by a destination server is not trusted by the local computer.

Cause: This problem happens when TMG does not trust the certificate of the SSL web site. For the most web sites that use commercial certificate authority this error shouldn’t happen. If the user really needs to access this web site, TMG administrator will need to import the CA certificate into the TMG local trusted root certificate store. Another workaround would be to add the site to the inspection exclusion list, and set certificate validation to “No validation”.

Question 2) I’m trying to browse a HTTPS web site and I’m receiving an error saying: The page cannot be displayed - Error Code 502 (Proxy Error) – the name on the SSL server certificate supplied by a destination server does not match the name of the host requested.

Cause: There are special cases where the “name mismatch” error that can happen and the conditions are:

· Web server uses a wild card certificate (*.domain.com for instance)

· Client is a transparent client (so accessing the web server using its IP address)

· Client is web proxy, but accesses the web server using its IP address

· Reverse name resolution (IP to name) of the web server fails from TMG

In that case, TMG needs to perform a reverse name resolution to identify any name mismatch.

However if the reverse name resolution fails for some reasons, TMG can’t complete the name mismatch validation. If this is a valid site and the end user needs to access the recommendation is to add the *.domain.com to the list of destinations exempted from inspection, and set the certificate validation to “No validation”.

Question 3) All HTTPS web sites that I’m trying to access the following message appears on IE:

Figure 3 – Web site security warning.

Cause: The most common cause for this error while accessing all HTTPS web sites is because the client workstation doesn’t trust the certificate that TMG is using. The CA certificate (e.g. self signed certificate) used by TMG must be deployed on the client, otherwise the client won’t trust the certificate issued by TMG on behalf of the web server. Read Deploying the HTTPS inspection trusted root CA certificate to client computers from TMG Documentation on TechNet for more information on how to deploy the CA certificate to the clients.

Question 4) All HTTPS web sites that I’m trying to access from Firefox I receive the error below (it works if I access using Internet Explorer):

Figure 4 – Error while browsing HTTPs sites through a third party browser.

Cause: Some third party browsers such as Firefox have their own trusted root certificate store and does not use the local windows trusted root certificate store while browsing Internet. Consult the third party browser documentation to see how to install the root certificate that TMG is using for HTTPS inspection. The reason why it works with Internet Explorer is because Internet Explorer consults the local Windows trusted root certificate store, therefore if the root CA certificate used by TMG is already deployed using group policy, then IE will trust the CA.

Question 5) My client workstations are using TMG Client because I want them to receive the balloon notification below while HTTPS inspection is happening:

Figure 5 – Message from TMG Client.

Users are saying that this notification just appears once for the same web site. Is that correct?

Cause: By default the notifications are cached for 12 hours. This means that a notification for a same site won’t reappear before 12 hours (if client machine is not rebooted during these 12 hours). The value can be changed using in the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\FwcMgmt]

"FWC_MGMT_HTTPS_TEMPORARY_DISABLED_TIMEOUT"=dword:2932E00

The current value is 2932E00 which equals 43200000 = 12 hours in milliseconds. This setting is used by the TMG Client UI (which is responsible for showing the notification), no need to restart the process – this will take effect on the next notification arrival.

Question 6) The site that I'm trying to access requires client certificate authentication, but when I try to browse I got the following error message:

Figure 6 – Error while browsing a site that requires client authentication.

TMG live logging shows the following message:

Cause: TMG doesn’t support this scenario because it doesn’t own the client certificate. The workaround is to add site to exclusion list with any mark (“Validation” mark is recommended).

4. Conclusion

In this post we discussed the basic functionality of HTTPS Inspection on TMG 2010 and the most common deployment problems that you might face while deploying this feature.

Authors

Yuri Diogenes

Sr Security Support Escalation Engineer

Microsoft CSS Forefront Edge Team

Bala Natarajan

Sr Security Support Escalation Engineer

Microsoft CSS Forefront TMG Beta Team

Technical Reviewer

Eric Detoc

Escalation Engineer

Microsoft CSS Forefront TMG Beta Team

Network Inspection System (NIS) in Forefront TMG Release Candidate

isablog — Sun, 18 Oct 2009 11:27:33 GMT

TMG Community,

We are pleased to announce that the release candidate (RC) update for Forefront Threat Management Gateway (TMG) will include several important developments for the Network Inspection System (NIS), the signature-based part of the Forefront TMG Intrusion Prevention System:

The NIS Engine can now be updated dynamically, in conjunction with NIS Signature set update, which allows us to introduce, over time, support for a wider range of protocols and protection scenarios.
We have completed development of traffic parsers for the most common protocols: HTTP, DNS, SMB, SMB2, NetBIOS, MSRPC, SMTP, POP3, IMAP and MIME, thus supporting comprehensive Web, mail and file sharing protection scenarios. These protocol decoders lay the foundation for signature development and rapid response by the Microsoft Malware Protection Center to newly discovered threats.

Please make sure to upgrade your Forefront TMG beta deployments to the Forefront TMG RC release. In this release, NIS signature updates, including the dynamic engine update, will be available through Microsoft Update. We will no longer support NIS signature updates to earlier beta versions once the RC is released.

If you have configured NIS with the default configuration for automatic signature set updates, NIS should have the latest signature set version (4.0 or higher, see a screenshot below).

If you need to update the signature set manually, please refer to Configuring Network Inspection System (NIS) for instructions.

Thank you for your feedback

A significant factor in the protocol quality assessment and enhancement is the community effort of the Microsoft Telemetry Service. Telemetry reports are monitored on a regular basis, and reported anomalies and suspected quality issues are analyzed in order to drive quality enhancements in future signature updates. We would like to take this opportunity to thank everyone who joined the telemetry reporting community, and encourage others to join and have a direct impact on the quality of protocol parsing and signature detection.

Authors:

Evgeny Skarbovsky, Senior Development Lead, Forefront TMG

Moshe Golan, Senior Program Manager, Forefront TMG

Reviewers:

David B. Cross, Product Unit Manager, Forefront TMG

Avi Ben-Menahem, Principal Group Manager – Forefront, GAPA

Alon Yardeni, Program Manager, Forefront TMG

Asaf Rosenfeld, Software Development Engineer, Forefront TMG

David Strasberg, Technical Writer