Forefront TMG (ISA Server) Product Team Blog

Email Protection in Forefront TMG 2010 Release Candidate

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

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

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

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

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

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?

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

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

Posted by isablog | 0 Comments

Filed under: Troubleshooting, ISA Server

TMG Client introduces automatic detection using Active Directory

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

Copyright (c) Microsoft Corporation. All rights reserved.

 

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

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

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.

 

 

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

 

Posted by isablog | 0 Comments

Filed under: Troubleshooting, TMG, Threat Management Gateway, HTTPS Inspection

Network Inspection System (NIS) in Forefront TMG Release Candidate

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

Understanding HTTP logging in Microsoft Forefront TMG

Consider a firewall policy which contains two Web access rules:

1. My Public Restrictive access rule- Allow traffic from internal network to a restricted set of URLs on the external network.

2. My Private Permissive access rule- Allow traffic from a limited subnet to all destinations on the external network.

As a simple example, at home you allow all computers to access a restricted set of URLs which are safe for children, and allow your personal computer to access everything on the Internet.

With this scenario, logging may be non intuitive for secureNAT clients.

Consider your personal computer accessing a destination which is not in the restricted url set. The traffic will be matched by the “My Private Permissive access rule” rule.

If your computer is configured as a Web proxy client, the logging is as expected:

The traffic is allowed by the “My Private permissive access rule”. Traffic to port 8080 is logged too.

On the other hand, if your computer is configured as a secureNAT client, the logging is as follows:

Unexpectedly, the traffic is allowed by both “My Public Restrictive access rule” and “My Private Permissive access rule”. How come?

The Web proxy is an application filter on top of the firewall engine. It implements its own rule engine which evaluates all web related rules to determine if traffic is allowed or denied.

Traffic from Web Proxy clients enter directly into the Web proxy code, because the Web proxy has listeners on ports 80, 443, and 8080. So only the rule engine of the Web proxy is involved in the evaluation of the policy. Therefore, logging is done by the Web proxy and points to the correct rule.

The story is different for secureNAT clients. Such traffic is first handled by the firewall engine, which runs its rule engine to evaluate the traffic. For Web related traffic, the firewall engine performs only partial evaluation. This is done for optimization, to reduce the resources consumed by the firewall engine. If the firewall engine determines that the traffic may be handled by the Web proxy then it is delivered to the Web proxy and the firewall engine logs the rule where it makes that decision. Then the Web proxy will do a complete evaluation and log the correct rule.

In the above example, the firewall engine makes the decision to delegate full evaluation to the Web proxy when it examines the “My Public Restrictive access rule” rule. This is the wrong rule, but it is enough for the decision in the firewall engine. Later on, the Web proxy will make the final decision and log the final result and the correct policy rule.

More on client types here.

Doron Juster

Senior Development Engineer

The ISP Redundancy Feature of Forefront TMG

Overview

Today, more and more businesses rely on their Internet Service Providers (ISP) to handle their outside Internet communications. Sending emails, browsing the web and any other web related actions are essential business infrastructure services that are only available as long as the ISP line is up and running.

Keeping a stable, available and reliable outside Internet connection is one of the critical tasks on every administrator’s check list.
Forefront TMG provides a new capability called ISP redundancy which enables utilizing not one, but two ISP links for external connectivity, either for traffic load balancing or as a failover backup.

This post explains an important aspect in the ISP Redundancy configuration: “Persistent Routing Rules”, which is required for smooth operation of the ISP redundancy feature, and explains the way TMG decides which connection will use which ISP.

Load Balance mode, algorithm description

When selecting the Load Balance mode in the ISP Redundancy Wizard (as seen in the screenshot), it is not obvious which connection will go through which ISP (this is handled automatically by TMG) but in case you are curious…

We calculate a hash value based on the source IP and the destination IP, resulting in a number between 0 and 100. In the case that the result is below the percentage defined for ISP link 1, TMG will use link 1 for this connection, otherwise, ISP link 2 will be used.

 

TMG performs the calculation when establishing every outgoing connection.

This form of calculation assures session stickiness – all connections for a specific (Source, Destination) pair will go through one link.

Finalizing Configuration

Once you complete the ISP Redundancy wizard located in Networking -> ISP Redundancy:

The next step left to complete the configuration of the ISP Redundancy feature: both NICs should be configured properly.

A default gateway must be defined on the NICs connected to both ISPs. Otherwise, when the ISP that is configured with the only default gateway is down, there is no route to the Internet.

Windows alerts the user with the warning below when defining more than one default gateway on the machine. In our case it’s OK.

Note: Traffic originating from the local-host is not affected by the ISP Redundancy feature. This includes DNS requests from the local-host, initiated by the proxy.

Due to the fact that the OS selects the DNS servers to use with no reference to the NIC they are configured on, there might be a scenario that a query to the DNS server of ISP-2 will be sent through ISP-1.

A common behavior of ISPs is not to answer DNS requests that are not from their network as shown in the drawing below.

 

The solution to the scenario above is to complete the configuration of ISP Redundancy by adding a persistent static route for each DNS IP address configured on the external network adapters on every Forefront TMG server.

This is required to ensure that DNS requests are routed through the proper network adapter.

Adding the persistent static route:

Syntax:

C:\> ROUTE [-f] [-p] [-4|-6] command [destination] [MASK netmask] [gateway] [METRIC metric] [IF interface]

Example:

C:\> route -p add 192.168.5.1 mask 255.255.255.0 192.168.1.1 metric 1

For more options like flushing the IP Routing table or to delete/modify an IP Routing table entry, use the route command with no arguments. This displays the various options for the route command.

Example:

C:\> route

The last step in configuring Forefront TMG for ISP redundancy involves turning off the automatic metrics option. Instead, you must define a different static metric for each network adapter.

If automatic metrics is not turned off, when the operating system recalculates the network selection, it may cause misalignment with Forefront TMG route cache functionality. This can interrupt communication, such as UDP communications used typically by Instant Messenger network discovery phase.

To turn off the Automatic Metric feature:

1. In Control Panel, double-click Network Connections.
2. Right-click a network interface, and then click Properties.
3. Click Internet Protocol (TCP/IP), and then click Properties.
4. On the General tab, click Advanced.
5. To specify a metric, on the IP Settings tab, clear the Automatic metric check box, and then enter the metric that you want in the Interface Metric field. It is recommended to define a lower interface metric value for the network adapter set to handle more traffic in ISP redundancy load balancing mode, or set as the primary link in failover mode.

For more information regarding Automatic Metric - http://support.microsoft.com/kb/299540/

Important To Remember

1. ISP Redundancy is only functional for a NAT relationship: testing connectivity from the local-host will not work and an admin may fail to understand why.

2. Because of the specifics of the load balancing algorithm explained above, it is possible that a bandwidth-consuming session will be assigned to the “slower” ISP connection and will lead to an incorrect load balancing ratio.

3. It is highly recommend leaving the “Connectivity detection” field in ISP settings as enabled. This value should be changed for troubleshooting purposes or in special cases only. Changing it will cause a malfunction in the failover mechanism.

FAQ

Question: Where can the administrator see the ISP Redundancy behavior?

Answer: The information is presented in TMG Dashboard à Network Status. :

Question: In what cases can I use the ISP Redundancy feature?

Answer: ISPR can be used for any internet traffic, not only HTTP. However, the web application filter is only used for HTTP / HTTPS traffic.

Question: Can I use ISP Redundancy in a single NIC configuration?

Answer: Yes, to configure ISPR with a single NIC you should choose the same NIC for both ISPs, but specify separate subnets for each of them. This is true for Load Balancing mode and for Failover mode.

Author: Alon Yardeni, Program Manager, Microsoft Forefront TMG.

Reviewers: Evgeny Katz, Gabriel Koren, Meir Feinberg, Nathan Bigman

Problems with user sets in cross forest scenarios

In cross forests scenarios, where users are migrated from one Active Directory forest to another using ADMT and enabling sidHistory, users from one forest may be denied traffic by ISA if policy rules are restricted to certain user sets.

For example, consider the following scenario:

1.      You have user accounts  in an Active Directory forest ForestA.

2.      You have another active directory forest, ForestB.

3.      You use the ADMT tool to migrate users from ForestA to ForestB, with sidHistory enabled. Now all users from ForestA exist in ForestB too.

4.      Your ISA server is installed in ForestB.

 

In ISA MMC, you create a new user set and add a Windows user from ForstA, for example, ForestA\User.

With this scenario, the user which eventually appears in the user set is  ForestB\User, not forestA\user as entered.

Because of this problem, if the user set is used in a policy rule to limit access to that user set, User from ForestA will not have access to the resources protected by that rule.

To work around that problem, do the following:

1.       On a domain controller in ISA domain, create a domain local security group and populate it with the relevant user accounts from both forests.

2.       On the ISA Server, create a user set which includes only this security group.

3.       Use this user set in the relevant policy rule.

 

This problem is resolved in Forefront TMG 2010.

Reference:
ADMT: 
http://www.microsoft.com/downloads/details.aspx?familyid=6F86937B-533A-466D-A8E8-AFF85AD3D212&displaylang=en

sidHistory:
http://technet.microsoft.com/en-us/library/bb727125.aspx 

 

Author:  Doron Juster, Microsoft Forefront TMG

Reviewers: Jim Harrison, Jonathan Barner