Forefront TMG Product Team Blog

In this article I want to provide a detailed view on a possible performance issue you might face, when you’re publishing CRM 2011 IFD using ISA Server or TMG.

Please note that the screenshots provided in this article are based on TMG, however the configuration in ISA is very similar to the configuration described in this article.

This article won’t cover the details on how to publish the CRM IFD (Internet Facing Deployment) in detail. In this article I assume, that you published your CRM IFD to the Internet using a standard Web Publishing rule on ISA/TMG and that the access to the CRM IFD is working from the Internet.

Scenario:

Consider the scenario, where your CRM IFD is up and running. You setup the publishing rule in TMG and everything appears to work as expected. Now you start sending the information about the published CRM to your users in their home office. A few minutes later you receive the first calls from users complaining that accessing the CRM IFD is terribly slow from their home office.

Troubleshooting:

To verify if something is going wrong with the server, you connect to the CRM IFD site, and cannot see any issues. Next you connect to the CRM Server and to the TMG to verify if you can see any obvious performance issues with the server, but everything appears to be “green”. In order to understand why the user experience is different to your experience you should start tracing the issue from the client which reported the issue.

One good way to perform this tracing is to collect a network trace on the client in order to verify if there’s anything like network delays which might be causing the issue.

I assume that your clients access the published site using HTTPS, therefore the relevant traffic in the network trace will be encrypted. If you don’t see any obvious delays you need to use tools to inspect the HTTPS traffic.

One of many tools which can help in this scenario is Fiddler (Download www.fiddler2.com) Please make sure to configure Fiddler to decrypt the SSL traffic as described here:

http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp

Once you setup fiddler on the client, please ask the user to reproduce the access while tracing the traffic with Fiddler.

Note: Please let the user know, to use a test account to reproduce the issue, as you will be able to see the user password in the fiddler trace.

Once the user collected the data, please ask the customer to save & send the fiddler trace to you. You can open it using Fiddler.

As the Fiddler trace will most likely not only include the traffic to the CRM host, but also some “noise”, you should first sort the tracing by host name and save only the relevant traffic between the client and the CRM server in a separate file.

With all the noise filtered it’s a good start to select all packets and have a look at the statistic section provided by Fiddler (screenshot below)

When you have a look at the ACTUAL Performance in this case, you can see that the client spends around 1:47min to load everything:

Requests started at: 10:23:13.759

Responses completed at: 10:35:04.469

Aggregate Session time: 00:01:47.804

The most interesting part is that the client did load about 10MB!

Request Count: 269

Bytes Sent: 141,293 (headers:127342; body:13951)

Bytes Received: 10,347,456 (headers:96136; body:10251320)

Given the fact that the client most is most likely connected with a slower bandwidth, compared to your company connection this explains why you didn’t face the issue when accessing the site!

The question you have to answer now is:

WHY DOES THE CLIENT HAS TO DOWNLOAD 10MB TO VIEW THE PAGE?

The first thing you should verify is if you can see some big files being transferred or some interesting content types in the request.

When you look at the response bytes, you can see which content-types are the “TOP TALKERS”:

RESPONSE BYTES (by Content-Type)

--------------

text/javascript: 6,260,298

application/x-javascript: 2,545,850

image/png: 854,138

text/x-component: 202,974

text/xml: 153,527

[…]

Thinking about this, this appears to be a quite lot of text/javascript and application/x-javascript which is send to the client. To get a better feeling, if there’s a specific pattern behind this, you should sort the Fiddler trace by Body

By looking at the biggest Reponses you can see the following, when you look at the headers:

The client Accepts compression, but for some reason TMG didn’t return the traffic compressed. When you have a look at the payload, you can see that it’s pure text, perfect to be compressed. You can have a look at some different packets, and you’ll see the same behavior. The client accepts encoding, but TMG just return uncompressed packets in most cases.

Time to look at the TMG now, to answer the question: WHY ISN’T TMG COMPRESSING THE TRAFFIC?

First of all you have to verify if compression is enabled. This can be verified when you open the Web Access Policy and open the HTTP Compression settings:

Next you should select the “Return Compressed Data” tab, to verify if the Listener you use in your CRM web publishing rule is listed there. It should be listed by default, the listener is called CRM Test in this case:

The next thing you should verify is which Content Types will be compressed at all, by clicking the Content Types … button.

This will show the following list of content types:

As you can see TMG doesn’t compress all content types by default, only those which are configured in HTML Documents and Text.

To verify what’s configured in those two content types, you have to open the properties of the content types using the Toolbox:

As you can see neither in HTML Documents nor in Text you can find an extension or content type which matches the “TOP TALKERS” from the Fiddler trace. That’s why TMG isn’t returning the traffic compressed.

You may ask yourself now, why isn’t TMG compressing everything by default to save bandwidth?

Here’s a good answer from TechNet:

In general, some Web servers, when responding to a request, do not accurately provide the content type in the response header. For example, a response may include a Microsoft Office PowerPoint® 2007 (.pptx) file, but the response header may indicate that the content is plain text. When an Internet Explorer client receives this type of response in compressed format, it cannot interpret the response, and the user sees meaningless characters on the monitor. If the response is received uncompressed, Internet Explorer can interpret it, and the user can open and view the content.

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

Button Line: It’s all about user experience. The scenarios where compression can break a website are more common than the scenarios where it helps to improve the user experience.

Note: By default TMG won’t ask for compression, when you use it in as forward proxy configuration, to provide the best user experience.

Of course there can always be scenarios, where you might need to add specific content types to the compression List, in order to provide a better user experience. Publishing CRM 2011 IFD is one of these scenarios.

In order to enable the compression for the “TOP TALKERS”, please do the following:

1. Configure a new Content Type set, including the content types which are listed in the TOP 3 of the TOP Talkers:

application/x-javascript

text/javascript

text/xml

2. Open the Compression settings -> Return compressed settings -> Content Types… and select the CRM content type you just created.

3. To verify if the changes had been applied correctly, you can start another fiddler trace from your client. When you use the Inspectors again, you can see that the RAW content is compressed / non-human readable.

Access to the CRM should be much faster now for users with slow bandwidth.

I hope you can find this article useful.

Author

Philipp Sand

Microsoft CSS Forefront Security Edge Team

One of the reasons for using an array is the availability of NLB, which is known to provide fault tolerance and load balancing.

NLB relies on heartbeats to determine whether the cluster nodes are alive. The nodes divide the potential client IP addresses among each other (in fact actually the hashes of the IPs) and send each other heartbeats, thereby notifying the other members that they are up and running.

As soon as a node is down (fails to send the heartbeats), the remaining nodes take ownership over the failing node’s IP hashes, providing coverage for all the clients normally served by the broken node.

How does this all relate to patching?

For new connections, the above behavior is straightforward, but what if we just “unplug” one of our TMG machines? What happens to existing connections served by this box? No other node will be aware of the state of these connections, so essentially they will simply fail.

This is exactly what happens if you just all of a sudden patch and reboot one of your TMG nodes.

How can we circumvent this? Is there any workaround?

In general, NLB supports what is called “drain mode”.

When your “drainstop” a node, NLB will still serve existing connections owned by that node but it won’t accept new connections. New connections will be handled by the other available nodes in the array.

With that, If you are intentionally taking a node offline then you can use drainsstopping to service all the active connections before you take the node offline for patching.

Therefore, when patching a particular TMG node, Ideally you will :

1. drain the node, wait until the session count drops to zero (sessions tab)

2. suspend it (so that NLB won’t be automatically started on next reboot)

3. patch the node

4. make sure the system operates properly with the patch

5. start NLB again to make the node join the array again

Here is a screenshot of the NLB options available in the TMG Management console:

Reference:

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

Authors
Balint Toth
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Eric Detoc
Escalation Engineer
Microsoft CSS Forefront Edge Team

When publishing services like Outlook Anywhere, OWA and Active Sync for exchange in ISA/TMG, we sometimes need certificates with subject alternative names (SAN). This enables us to publish multiple DNS names using one SSL Web Listener. Requesting SAN certificates is something we can perform directly through a Microsoft internal CA. However there are some steps to follow before gathering a new certificate that makes use of SANs.

This article explains how to request a new certificate with a SAN from the Microsoft Management Console on the TMG computer.

The following security best practices apply when adding subject alternate names to certificates:

· In general, the use of user-defined SANs can increase the risk of impersonation attacks because it allows a user to specify arbitrary names in a certificate request. Because user input can be abused by persons with malicious intent, precautions should be taken to mitigate the risks associated with the use of user-defined SANs and protect the integrity of your public key infrastructure (PKI).

· Certificate requests that contain SANs should be held in a pending state until they can be reviewed by a certificate manager. For information about configuring certificate templates to require certificate manager approval, see Issuance Requirements.

· Implement administrative procedures for reviewing pending certificate requests and verifying the requester is authorized to use the requested subject names.

· Implement separation of duties and role-based administration to ensure that individuals who can request certificates with SANs cannot also issue them. See Implement Role-Based Administration.

· Restrict usage of SANs to only those individuals that require it, such as administrators who install Web server certificates. For information about configuring certificate template security, see Issuing Certificates Based on Certificate Templates.

· If you must use SAN attributes because your server that requires a certificate with a SAN is running Windows Server 2003, consider completing certificate enrollment procedures on a computer that is running Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista.

Hence we definitely suggest to make use of the mmc console to generate your SANs certificates.

Generating a certificate using the certificate console on TMG/ISA

To generate a SANs certificate use the Microsoft Management console on the TMG/ISA server as explained in the following paragraphs.

However before running the mmc certificate console we need to duplicate the template “web server” on the CA and make it visible under mmc-> certificate itself.

To accomplish this step we must open the certification authority as enterprise administrator and under certificate templates, right click on “manage”. We will open the certification template console where we have to duplicate the template “web server”. You have to configure it with the permission to be “visible” under the mmc certificate console, by selecting “enroll” in the security tab for the “authenticated users”. Be careful that the template version must be V2 and NOT V3 (2003 and not 2008), as TMG doesn’t support CNG certificates (http://technet.microsoft.com/de-de/library/ee796231.aspx#dfg9o9i8uuy6tre).

Once we have opened it and we have expanded local computer –> personal, we have to right click and chose “all task” and “request new certificate”.

After pressing “next” twice and choosing the template model “web server”, which had been duplicated previously, we select details and we must click on “properties”.

At this stage we have the two fields under the subject tab which are of interest:

Subject name -> type-> CN

Alternative name -> type-> DNS

Then press “ok”, “enroll” and if everything goes fine, we should get something like this:

At this point the certificate has been correctly created and installed under the certificate store.

However from TMG/ISA there is something to do before enrolling the certificate. By design TMG/ISA blocks DCOM and you’ll see an error similar to this:

With certutil from the command line you’ll see something like this:

C:\Windows\system32>certutil -ping -config "WIN2008DC.via.santagiulia\via-WIN2008DC-CA"

Connecting to WIN2008DC.via.santagiulia\via-WIN2008DC-CA ...

Server could not be reached: The RPC server is unavailable. 0x800706ba (WIN32: 1722)

In TMG/ISA we need to disable the Strict RPC compliance using “edit system policies” -> “authentication services” -> “enforce strict RPC compliance” and apply it. This is because TMG/ISA blocks DCOM by design and DCOM is required to acquire a certificate.

You can also use the following command from the command line to check the CA availability on any server:

C:\Windows\system32>certutil -ping -config "FQDN\CA_Name"

if everything is fine we should get:

C:\Windows\system32>certutil -ping -config "WIN2008DC.via.santagiulia\via-WIN2008DC-CA"

Connecting to WIN2008DC.via.santagiulia\via-WIN2008DC-CA ...

Server "via-WIN2008DC-CA" ICertRequest2 interface is alive

CertUtil: -ping command completed successfully.

That’s all. We have successfully created and imported our new SANs certificate.

Please be aware that you need to make sure that this certificate is installed on each node if you’re running an Array of ISA/TMG server, in order to be able to create a SSL listener on each one of the nodes.

Author
Andrea Vescovo
Support Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Philipp Sand
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Carsten Kinder
Principal Consultant
Microsoft Consulting Services

Usually we’re using tools like Network Monitor, various text file parser, Procmon, Windbg… to solve ISA/TMG cases every day in and out in Microsoft Customer Service & Support. Sometimes we also use Excel to be able to filter the exported Firewall or Web Proxy Logs our customers send to us, e.g. only display traffic for a specific Client IP or for a specific rule.

Some time ago I realized that there’s another quite powerful feature of Excel, which I didn’t connect with analyzing network traffic before, but more with things like management analysis or accountancy: Excel Pivot Tables!

In this blog I want to describe how Pivot tables can be quite handy for analyzing TMG Logs if you want to identify specific patterns or things like netstat if you want to get an overview about who’s talking with your server.

Scenario 1 – Is the load* in my TMG Web Farm distributed well? (*based on number of requests)

You’re using TMG Web Farm publishing. In your web farm you have 9 Web Server, publishing one SSL site. 2 Server currently drained for maintenance.

The Web Server Internal IP addresses are 10.1.1.1-10.1.1.9.

We have an export of a Firewall Log which might look similar to this (the header descriptions had been modified):

[…thousands* of rows to follow…]

*check Excel specifications and limits for details how many rows Excel allows in one Worksheet, you might need to split files for large logs

First Steps creating a Pivot Table

In order to find how many connections had been handled by each of your published web server, you could just use the Sort & Filter Option in Excel, and just filter each server and count rows, or you create a new Pivot Table.

Insert -> PivotTable

This will automatically select a coherent section in the Worksheet:

And will create the PivotTable in a new Worksheet.

In Excel 2010 you’ll find the blank Pivot Table in the Worksheet in the left and on the right you’ll see the PivotTable Field List, which is you main tool to modify the Pivot Table:

For the case you don’t see the Field List, make sure, that the Field List Button is selected in the upper right.

In the Field List you can see a list of fields which can be used for the Pivot Table. This list of fields represents all columns for your worksheet:

Your “Pivot Tools” can be found in the lower right:

Report Filter: You can add columns here to filter the data sources

Row Labels: Labels for the rows you want to summarize.

Values: Used to calculate the results summarized in the rows

Column Labels: If you want to have multiple columns per row, these can be used

Let’s pivot

In our scenario we have a fair number of columns and lots of data to analyze. Remember, in this scenario, we want to know how many requests had been handled by each internal server in our farm. If we look at the fields we can use to generate the PivotTable the most interesting one is the “destsock”, which contains the destination IP+Port of the connection.

Let’s use this field in the Row Labels area.

This will generate a list like this, showing all sockets which had been logged:

You can now filter the destsock, to only display the sockets we’re interested in. In this case these are 10.1.1.1:443 to 10.1.1.9:443

In order to filter the list, just move your cursor to the list of fields we can add over the destsock:

And click on the little arrow, this will pop up the Excel Search&Filter list:

In the search field I now enter 10.1.1. and select the sockets of interest. This will give me a list like this:

Now if you want to know how many times this socket had been logged, you can move one of the fields to the Values area, e.g. Server name:

You’ll immediately get an updated Pivot Table, with a list of how many times each socket had been logged and how many times the filtered sockets had been logged in total:

With very few steps this already provides a quite good overview about the connection distribution for each Web server. You can also identify the two drained server very easy. They both are logged 172 times in this example.

If you wonder which they are logged at all, you can simply double click the 172 in the pivot column “Count of Servername”, and a new Worksheet will open with a filtered view for these lines:

We have no information about the User Agent in this log, but based on the time you can see, that the requests are logged exactly every 30 sec, which is the default behavior for connectivity verifier.

Based on this Filtered view, you can also see that every connection (almost) always contains 2 actions, “Establish” and “Terminate”. If you’re only interested in the number of Established connections, you need to go back to the Pivot Table and move “Action” to the Report Filter:

This will move Action to the Top of the Pivot Table, just select the drop down array again, and Filter for “Established”:

Based on this list, you can clearly say, that the balancing seems to work quite good… all with the help of Excel and a few mouse-clicks ;-)

Scenario 2 - Who is connecting to / attacking my server?

In Scenario 1, we already found if the connections to the web server are balanced equally, among each server. With a few additional mouse-clicks you can analyze who is actually causing the load on your server, based on the client IP, using mostly the same steps we did before. Unfortunately we didn’t log the original client IP in this set of log, with this information you could just move the original client IP to the Rows Area to see which client connected to which server.

As we don’t have the information, we cannot determine which client connected to which backend server, but we can still analyze which clients connected to the published web site, as we know the socket on which we configured the TMG Web Listener. In this case it’s the 192.168.100.101:443.

To get a nice Table, which shows number of Established connections to this socket, the fields will look like this:

You can filter “Action” to show only Established connections and “destsock” to show only connections to socket 192.168.100.101:443 and you’ll get a table like this:

You can sort the list to get the “Top Talker” to the Top of the list, by right-clicking the “Count of Action” column and choose Sort -> Largest to smallest:

If you want to see only the Top10 “Talkers”, just right-click the Row Label column and choose Filter -> Top10

If you want to “Pimp” your results, you can either use the Excel “Conditional Formatting”, to highlight the results:

Or create a PivotChart (PivotTable Tools -> PivotChart -> Pie):

This can help you to understand who caused the most connections to your farm. In case of an attack I would double check the 10.10.63.247 in this scenario, and eventually create a rule to block this traffic J

Scenario 3 –Using Excel Pivot Tables to identify an ongoing flood attack

In a scenario, where you don’t have any exported logs yet, e.g. when you’re just experiencing an attack on the TMG or on a Webserver, you might need to use different types of data to analyze the source of an attack.

One tool I find quite handy for these situations is NETSTAT. The Netstat output provides an immediate view on the connections the server is currently handling.

In order to receive better results I would always suggest to use Netstat in combination with the –n switch, to avoid name resolution for addresses, which can take a while when you have thousands of connections to your server and the –ao switch, to display all sockets and the PID of the process, which is handling the socket.

In order to have everything in a file a sample command would look like this: netstat –ano > netstat.txt

Next step is to import the text file into Excel. As Excel will most like put all the data into one column you need to use Data -> Text-To-Columns, to generate one column for each type of information.

In the Wizard select the Space as separator and “Treat consecutive delimiters as one”:

In this case you might also want to delimit the Sockets, in order to be able to better filter on the source IP of the potential attacker. You can do this by just selecting the column with the socket and run Text-To-Column again, using the “:” as delimiter this time.

In the end the worksheet might look similar to this one:

Now you can create a new Pivot Table. Use the Foreign Address in the Row Labels again, and a column of your choice in the Values, and you can see which IP has the most connections to your server:

Please make sure to verify the IP addresses before configuring any sort of deny rule in your firewall. You don’t want to block the NAT IP if you most valuable customer J

Hope that helps!

P.S: There might also be other ways to analyze these scenarios, fell free to let me know about your favorite tools in the comments Smiley

Author
Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Eric Detoc
Microsoft CSS Forefront Security Edge Team

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

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

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

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

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

Visit our TechNet Library for more information.

- The Forefront TMG Team

In TMG 2010 Service Pack 2, we did put our focus on bug fixing, in order to improve the overall experience with TMG 2010. However next to pure bug fixing, we also introduced some new features.

One of these new features introduces the possibility to allow Kerberos Authentication when connecting to TMG in a “High Availability” (HA) scenario.

Consider the scenario, where you have a TMG array of two or more nodes. Let’s call them Florence.contoso.com and Firenze.contso.com in this scenario. Both nodes are member of a Domain, and you require Proxy Authentication to authenticate your user for Forward Proxy Access. You enabled Load Balancing on the internal network, e.g. by enabling TMG Integrated NLB, the NLB VIP in your internal network resolves to SP2Array1.contoso.com in this example setup.

Why didn’t Kerberos authentication work in a HA scenario before?

In the given scenario your user could already use Kerberos to authenticate the proxy requests. They could only do this though, when using the FQDN of either one of the nodes, e.g. when using a WPAD file with both proxy FQDN included (see this article to find out how to configure FQDN in the WPAD file), or when connecting to only one node’s FQDN. It wasn’t possible to use Kerberos when connecting to the NLB virtual IP address or when installing a load balancer between the client and the TMG array to balance the requests. As Tom Shinder summarizes in the article CARP and High Availability – Not So Much, the setup using WPAD with multiple FQDNs included, provides some load balancing mechanisms like Client CARP, but it shouldn’t be considered as a HA scenario.

The reason for this limitation is directly connected to the Service Principal Names (SPN), which uniquely identifies an instance of a service. A web client (such as a browser) that uses Kerberos to authenticate against the proxy uses the proxy name as it knows it to construct the SPN for the client-to-proxy authentication. For Domain’s computer accounts, a respective SPN with the computer’s FQDN is created automatically when the computer is joined to the domain. This SPN is associated with the computer account so processes running as NETWORK SERVICE principal, such as TMG’s Firewall Service, can authenticate clients through Kerberos tickets referring to this SPN. In HA scenario all array members need to be able to authenticate such tickets because the client may connect to any array member. However, SPNs have to be registered on only one account. If you register the SPN on multiple accounts in your active directory, you will end up with duplicate SPNs, which can lead to quite unpredictable behavior in your AD. For further details here’s the MSDN description for SPNs:

A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.

Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information, see How a Service Registers its SPNs.

When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate. For more information, see How Clients Compose a Service's SPN.

http://msdn.microsoft.com/en-us/library/ms677949(v=VS.85).aspx

Before TMG SP2, the Firewall Service (the process hosting the Web Proxy and hence the one authenticating proxy clients) could only run under the NETWORK SERVICE account. Therefore it could authenticate only tickets that refer to SPNs associated with the respective computer account. If you considered to register the SPN for SP2Array1.contoso.com in this setup, you would need to register the SPN on each one of the array nodes computer accounts, which leads to duplicate SPNs in your AD and isn’t a valid configuration.

What did change in SP2 to allow Kerberos Authentication in HA scenarios?

In SP2 we introduced the possibility to configure the TMG Firewall Service to run in a context of a user account. With this new possibility it’s now possible to use Kerberos for HA scenarios, as you can register the SPN for the “HA-IP address” FQDN on the user account that is configured for Firewall Service.

How to configure Kerberos Authentication in TMG HA scenarios?

1. You need to configure a domain user account, which will be used as “TMG Firewall service account” in the future. In this example the Account name I use is TMGSP2KRB in Domain contoso.com

Recommendations for creating the user account to help protect your domain:

· The domain account that you use for the TMG Firewall service is not a member of any local or domain groups. However, since an account must be a member of at least one primary group, define a new placeholder group and use that as the primary group. Make sure that the placeholder group does not have any permission or user right on any domain resource.

· The domain account has no permissions or user rights on any domain resource.

· The domain account is used only for the TMG Firewall service and not for any other purpose within the domain.

Forefront TMG grants the domain account the minimal permissions required on the TMG array nodes when you configure it for the Firewall service and removes the permissions when you configure a different account. Hence, do not manually grant any permission for that user on the TMG array nodes.

2. You need to register at least the SPN for SP2Array1.contoso.com on this user account. You can register the SPN, using the setspn command line tool.

Here’s how to register the SPN for SP2Array1.contoso.com on the account TMGSP2KRB:

setspn –A http/SP2Array1.contoso.com TMGSP2KRB

In order to be able to use Kerberos when connecting to the FQDN of each individual node, we recommend to register the additional SPNs for each FQDN on the service account as well.

In the end you can use setspn –L TMGSP2KRB to list the SPNs which had been added to the user account. In this example scenario this will look similar to this:

3. With the account all setup, we can now open the TMG MMC of the array to complete the TMG configuration of this scenario.

Right-click the Array name and select properties:

Select the Credentials Tab to configure the service account:

Apply the settings. Please be aware, that the TMG Firewall Services needs to be restarted for this change to take effect. A proper prompt will be displayed when applying the configuration changes. It is also recommended to restart the TMG Admin console (MMC) in this case.

After successfully applying the change, you can open the Services.MSC to verify if the changes were applied successfully.

If applied successfully, you’ll notice, that the Microsoft Forefront TMG Firewall Service will Log On As contoso\TMGSP2KRB now:

When you configure Proxy Authentication now, and collect a network trace on one of your clients, the trace will look similar to this when you connect to your favorite technet blog Smiley

Notice that the client is using GSS-API Authorization which is the equivalent to Kerberos Authentication in Netmon 3.4.

If your client still tries to use NTLM, and the trace looks like this:

make sure that you Enabled Windows Integrated Authentication in the Advanced Internet Explorer Settings:

Without Integrated Windows Authentication the client will try to use NTLM instead of Kerberos. (Please don’t ask me why this setting had been named like this, as Kerberos and NTLM are both Integrated Windows Authentication types as far as I know J)

Author
Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Oved Itzhak
Senior SDE TMG Product Group

Have you ever been interested in which users did visit specific sites in the Internet very often? E.g. which users did browse most on blogs.technet.com last week? In SP2 we added a new report, which allows analyzing the usage of specific sites connected to users in your organization, with a few mouse clicks.

In order to create the report you have to open the TMG MMC / Logs & Reports:

On the right hand side you can select “Create Site Activity Report”.

In the Wizard you can configure how many sites will be reported per user and how many users will be included in the report:

Be aware that in the default setting the Site Name parameter is OVERWRITE. You have to enter the parameter of your choice here. In this example I used blogs.technet.com, you can also use parameters like .com to see all requests to “.com sites” or narrow down to www.microsoft.com if you like to see only request to www.microsoft.com.

Here’s how a report can look like:

Be aware that you’ll only see the user name, if you’re using proxy authentication in your environment and if you’re logging the user name. If no proxy authentication is enabled, or specific rules don’t require proxy authentication, you will also see the “anonymous” User in the report.

Author
Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Roman Golubchyck
Senior SDET TMG Product Group

In TMG 2010 Service Pack 2, we put our focus on bug fixing, in order to improve the overall experience with TMG 2010. However next to pure bug fixing, we also introduced some new features.

In this article we’ll provide a quick introduction to the new error pages and will provide a brief overview of how to modify them.

For more information please visit the Technet documentation about Customizing HTML error messages, which has been updated to reflect the changes in SP2.

In TMG SP2 you can now configure TMG to use an improved version of Error Pages. With these new error pages you now have the option to include pictures, e.g. including your company logo on the error page.

In order to configure TMG to use the new version of error pages, you have to open the TMG MMC, right-click the Array and select Properties:

There’s a new tab called “Error Pages”:

As described in the UI, the new version of error pages can be found in the TMG installation directory \Templates\WebObjectsTemplates\ISA. After applying the changes the TMG Firewall service has to be restarted.

The new error pages will look like this when they are not modified:

If you want to modify the pages, there are two default HTLM error files in the \Forefront Threat Management Gateway\Templates\WebObjectsTemplates\ISA folder that can be used as templates for creating additional HTML error message pages, Default.htm for internal clients and DefaultR.htm for external clients.

In the new error pages directory you can find a subdirectory HTML, containing the following files:

These image files will be used in the error pages. If you want to modify things like the Logo, you can do this by simply replacing the image files with your corporate identity logos, without having to modify the template html files.

Another option is to copy the objects/pictures you want to embed into the error pages into the HTML directory and add the reference into the error pages, like this: <img src="HTML/MyImage.gif"> </img>.For detailed information have a look at this Technet article.

Note: Before modifying the error pages or the image files, we strongly recommend to create a backup of the original files! Please be aware that you have to restart the Firewall service to use the modified images.

In my example I just performed some simple modifications to the logo.png file. Here’s how the modification might look like:

I’m sure you can do much nicer modifications though Smiley

Author
Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
James Kilner
Technical Writer

Introduction:

In this scenario I am going to share a very unique issue which I came across while trying to join one of the TMG servers to the Stand alone array.

In this case we had two Enterprise Edition TMG servers installed on an Appliance.

Scenario:

We had two Enterprise Edition TMG servers and we were trying to join one of the servers to the Stand alone array pointing it to the other TMG server as the Array Manager.

But when we ran the ‘Join Array’ Wizard it failed with an error ‘KEYSET DOES NOT EXIST’ on the TMG server which we were trying to make the Array Member.

Troubleshooting:

Looking at the above error message it seems that TMG is trying to access some Folder/File which is either missing on the server or it does not have access to it.

So, we ran the Process Monitor on the TMG server while trying to join it to the Array. We filtered the Process Monitor file to show the results related to wspsrv.exe (Microsoft Forefront TMG Firewall Service) process.

And in the filtered trace we could see the following files being accessed by wspsrv.exe process:

2:02:36.6488085 AM wspsrv.exe 2756 CreateFile C:\ProgramData NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: N, ShareMode: Read, Write, AllocationSize: 0

2:02:36.6489655 AM wspsrv.exe 2756 CreateFile C:\ProgramData SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

2:02:36.6489971 AM wspsrv.exe 2756 QueryBasicInformationFile C:\ProgramData SUCCESS CreationTime: 7/14/2009 8:50:08 AM, LastAccessTime: 5/5/2011 12:58:49 AM, LastWriteTime: 5/5/2011 12:58:49 AM, ChangeTime: 5/5/2011 12:58:49 AM, FileAttributes: HDNCI

2:02:36.6490214 AM wspsrv.exe 2756 CloseFile C:\ProgramData SUCCESS

2:02:36.6491280 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Attributes: S, ShareMode: Read, Write, AllocationSize: 0

2:02:36.6492088 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft\Crypto NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Attributes: S, ShareMode: Read, Write, AllocationSize: 0

2:02:36.6493243 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft\Crypto\RSA NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Attributes: S, ShareMode: Read, Write, AllocationSize: 0

2:02:36.6494460 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft\Crypto\RSA NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Attributes: S, ShareMode: Read, Write, AllocationSize: 0

2:02:36.6496038 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Attributes: S, ShareMode: Read, Write, AllocationSize: 0

2:02:36.6498710 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: S, ShareMode: None, AllocationSize: n/a, OpenResult: Opened

2:02:36.6499060 AM wspsrv.exe 2756 QueryStandardInformationFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS AllocationSize: 4,096, EndOfFile: 1,467, NumberOfLinks: 1, DeletePending: False, Directory: False

2:02:36.6499310 AM wspsrv.exe 2756 WriteFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS Offset: 0, Length: 1,467, Priority: Normal

2:02:36.6499949 AM wspsrv.exe 2756 CloseFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS

2:02:36.6501323 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

2:02:36.6501620 AM wspsrv.exe 2756 QueryAttributeTagFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS Attributes: SA, ReparseTag: 0x0

2:02:36.6501855 AM wspsrv.exe 2756 SetDispositionInformationFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS Delete: True

2:02:36.6502116 AM wspsrv.exe 2756 CloseFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_c49c7513-8b86-4d0e-90bf-4805804a9318 SUCCESS

2:02:36.6506463 AM wspsrv.exe 2756 CreateFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

2:02:36.6506747 AM wspsrv.exe 2756 QueryDirectory C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\a63f7ad5b2228889fc41ae79c417446b_* NO SUCH FILE Filter: a63f7ad5b2228889fc41ae79c417446b_*

2:02:36.6507028 AM wspsrv.exe 2756 CloseFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys SUCCESS

As you can see in the above logs Firewall service is trying to access a particular file in the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder on that server and due to some reason it was not able to access it and hence was showing the message as ‘NO SUCH FILE’.

So now it was pretty clear that wspsrv.exe was looking for a file in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder but it was not able to find it or it did not have access to it.

As the Microsoft Forefront TMG Firewall Service runs under the NetworkService account, we tried to give Permissions to NetworkService account on the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder (You can check on some other Windows Server 2008 for the Permissions to be given to ‘Network Service’ account). But while trying that we got an error ‘Access Denied’.

So it looked to be some major issue with the server itself. We checked back with the Appliance vendor and came to know that the boxes were hardened. They replaced that server with a new one and when we tried to join the TMG to the array on this new server, it got joined fine.

NOTE: The above troubleshooting was done on the TMG server which we were trying to join to the array and make it an Array Member.

CONCLUSION:

This was not a failure of the product. Problem was due to misconfiguration of server and overzealous hardening by the hardware vendor. TMG was working fine but not allowed to do what it should be able to in default installation.

Author:

Nitin Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Billy Price

Security Sr. Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Richard Barker

Security Sr. Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

In ISA 2006 SP1 and TMG RTM it’s possible to configure ISA/TMG to distribute
your own custom WPAD configuration file. This can be quite handy if you already
did write your own WPAD configuration file, which had been distributed on a
separate server, or if you want to use the ISA/TMG provided WPAD configuration
file as baseline for some changes, e.g. configure your clients to connect to the
NLB IP instead of using the Client CARP mechanism, which is used by ISA/TMG by
design.

To configure ISA/TMG to use your custom WPAD configuration file, you need to
follow these steps:

1. Please download the compressed file from http://www.isatools.org/tools/KB953293.zip
(Thanks Jim!)

2. Copy & Unzip die File on your ISA/TMG Server.

3. Copy the WPAD configuration file you want to distribute with your ISA/TMG
server to the ISA/TMG local hard drive.

4. Before you proceed importing the WPAD configuration file in your ISA/TMG
configuration, you have to make sure, that there are no non-ASCII Characters in
your WPAD configuration file, as the import process won’t import the complete
file if there are any non-ASCII characters included.

Note: if you use a WPAD configuration file which had been
distributed by ISA 2006, the file will most likely include non-ASCII Characters
at the end of the file.
To remove those characters you have to
delete this part:

function HashString(str, h){
for(var i=0; i<str.length; i++){
var c = str.charAt(i);
if(c
==':' || c == '/') break;
c =
CharToAscii(c.toLowerCase());
h = (h
>>> 4) ^ h_tbl[(h ^ c) & 15];
h = (h >>> 4) ^ h_tbl[(h ^ (c>>>4)) & 15]; h
= MakeInt(h); } return h; }

and replace this part with those lines:

function HashString(str, h){
var hashstr=str.toLowerCase();
for(var i=0; i< hashstr.length; i++){
var c = hashstr.charAt(i);
if(c ==':' || c == '/') break;
c = hashstr.charCodeAt(i);
h
= (h >>> 4) ^ h_tbl[(h ^ c) & 15];
h = (h >>> 4) ^ h_tbl[(h ^ (c>>>4)) & 15]; h
= MakeInt(h); } return h; }

afterwards you have to delete this line:

var Chars ="
!\"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~€???????????Ž????????????ž?
¡¢£¤¥¦§¨©ª«¬¬®¯°±²³´µ¶•¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþ
"; function CharToAscii(c){ return Chars.indexOf(c) + 32; }

5. After you prepared your WPAD configuration file, use the script attached
to import the file to the ISA/TMG configuration, e.g. by executing this command:

to operate on the current array, use '.' as the array name or omit this
option:

cscript kb953293.wsf /array:. /net:internal /script:<FullPathToScript>

For a full list of options please refer to the readme.txt provided in the ZIP
file.

Remark: Please be aware, that any changes you configure in the ISA/TMG
UI will not be applied to the WPAD configuration file after you submit the
custom WPAD configuration file to your configuration. If you want to apply
changes to your WPAD configuration file once you’ve imported it to your
configuration, you have to manually edit the WPAD file and reimport it using the
script again.

If you want to stop using your custom WPAD configuration file and go back
using the ISA/TMG script you have to execute the following command:

cscript kb953293.wsf /array:arrayname /net:internal /del

Hope that helps!

Author

Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Frank Heilmann
Microsoft CSS Forefront Security Edge Team

Richard Hicks (Forefront MVP) was interviewed by Tom Shinder and Yuri Diogenes for their Security Talk Show called From End to Edge and Beyond. In this interview Richard explains and demonstrates some of the new capabilities of Forefront TMG SP2.

Check it out the interview here: http://technet.microsoft.com/en-us/edge/from-end-to-edge-and-beyond-episode-11

Hello All! It’s Brett Crane from the Forefront Edge team here at Microsoft. I wanted to take a few moments to talk about an issue you may see in your RRAS environment if you are utilizing NLB to load balance your External Interfaces of your TMG Array and you’re using an IPSec based Method.

Here is a problem statement you may be facing:

“My VPN clients are failing to connect to my environment when utilizing L2TP and connecting to the Virtual IP of the Array. If I connect to the physical IP of either of the nodes it connects without issue. PPTP and SSTP work but for some reason L2TP doesn’t. I am positive I have it setup right. What could be wrong with TMG or RRAS?”

Well, I will start by saying that if you are seeing this you may have already pulled out all your hair! There’s nothing in the event logs what-so-ever pointing to an issue of any kind! As well… when you do live tracing in TMG to see why the VPN connection is failing everything seems to be working fine. Where do you start looking for data???

Based on the issue I’m covering I’ve found that Network Monitor is a very useful tool to help troubleshoot LT2P/IPSec related issues. In addition, if you have a TMG Array with Integrated NLB enabled on the External Network, I’d suggest that you install Network Monitor on all nodes of the array as you may not be sure which node will handle the L2TP/IPSec traffic in question.

* You can download the most recent version of Network Monitor from the following location: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4865

Once Network Monitor is installed and running, go ahead and reproduce the L2TP VPN client connection issue. Once you have reproduced your issue stop your tracing and apply the following Display Filter: IKE or ESP. This will cause Network Monitor to show you IPSec related data.

Looking through the trace you will see the following behaviors…

The client tries to setup an IPSec Tunnel with the RRAS\TMG Server’s Virtual IP Address (Keep in mind that the Microsoft L2TP protocol utilizes IPSec as an underlying security protocol). The first part of the IPSec process is what we call Main Mode. As you can see below this works fine:

The next thing we see is that the Quick Mode Process works without issue. Quick mode is the second part of the communication process the IKE protocol utilizes to setup an IPSec Tunnel:

Once Main Mode and Quick Mode have completed we will now have an IPSec tunnel created and the client will communicate through that tunnel utilizing the ESP protocol:

Now comes the odd part. Instead of the Server returning ESP communications to the Client, as it should, it tries to open a new tunnel up to the client. It does this via a new Main Mode connection over the physical IP Address on the External interface of the RRAS\TMG server instead of the Virtual IP. The client would not have a policy to support this process therefore it silently drops the requests and retransmits the ESP data it sent before. Each time the server receives the ESP data it tries to send out a Main Mode request. The behavior can be seen below:

So the question is…

“Why does the server try to create a new tunnel out to the client over the Physical IP while there is already a tunnel established over the Virtual IP address?”

Answer…

The problem is that the server is not selecting the correct IPSec Security Association (SA) when trying to communicate back. Therefore it tries to create a new one. The only way the server sees to connect up to the clients IP Address is by sending the data out of its Default Gateway which is associated with its Physical IP Address\NIC.

How do I resolve this…

This is a known issue in the Server 2008 R2 operating system. To resolve this issue all you need to do is connect to the Microsoft TechNet article below and choose the “View and request hotfix downloads” Link in the upper Left corner.

You cannot establish an IPsec tunnel to a computer that is running Windows 7 or Windows Server 2008 R2 through a NAT device

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2523881

* Again… keep in mind that the data in the article only refers to IPSec and you are using L2TP. That’s perfectly ok. That’s because L2TP uses IPSec as its means of creating a secure tunnel. As well, the information covered in the article also covers NAT-T configurations. That is only 1 scenario that was found. The fix actually covers multiple scenarios although not listed.

Thank you for your time in reading this post. I hope it helps you out!

Author:

Brett Crane

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewer:

Richard Barker

Security Sr. Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Here’s a new KB article we published on TMG 2010. This one actually first came out a couple weeks ago but since it wasn’t announced at the time I thought I’d send out a quick heads up just to let you know it was there. This KB article talks about an issue where an installation of SP1 or SP2 at a branch office fails and then rolls back just after Setup stops the Firewall service:

=====

Notice

Important This article contains information that shows you how to help lower security settings or how to turn off security features on a computer. You can make these changes to work around a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.

Symptoms

Consider the following scenario:

The Microsoft Forefront Threat Management Gateway (TMG) 2010 Enterprise Edition server is running Microsoft Enterprise Management Server (EMS) in the headquarters network.
The TMG 2010 server that is installed on the branch office network is connected to the headquarters EMS using a Site to Site VPN that is hosted on the TMG 2010 server.

In this scenario, an installation of Service Pack 1 or Service Pack 2 on the branch office fails just after Setup stops the Firewall service. Then, the EMS connectivity problem is reported, and the Setup process roll backs the service pack installation. For more information about the ISA and TMG branch office scenario, visit the following Microsoft TechNet webpage:

http://technet.microsoft.com/fr-fr/library/bb794783(en-us).aspx

Cause

This problem occurs because the installation process must shut down the Microsoft Forefront TMG Firewall service to update binary files. When the service is stopped, the Site to Site VPN connection to the branch office network from the headquarters EMS server is closed. When this occurs, the installation process loses connection to the headquarters EMS server.

Resolution

To resolve this issue, follow these steps.

Upgrade process

On the headquarters EMS server:

Upgrade the computer to TMG 2010 SP1.

On the headquarters TMG server:

On the Remote Access Policy node, click the VPN Clients tab.
Enable VPN client access.
Configure VPN Client Access. To do this, on the Protocols tab, click to select the Enable L2TP/IPsec check box, and then click Apply.
Click Authentication Methods. In the Allow custom IPsec policy for L2TP connection field, click Use preshared key value, and then click Apply.
Apply the configuration changes.
Under Local Users and Groups, click Users, right-click New User, and then click Properties.
Type the user credential details (including the user password), and then click to clear the User must change passwords at next logon check box.
Click Create, and then click Close.
Right-click the new user, click Properties, point to Dial-in, and then click Network Access Permission.
Click Allow Access, click Apply, and then click OK.
Connect remotely to branch office TMG server’s external IP address from the headquarters TMG network.

On the branch office TMG server when it is connected:

Run the following from a command line with administrative permissions:

netsh tmg add allowedrange a.b.c.d a.b.c.d persistent

In this command, the placeholder a.b.c.d is the external address of the headquarters TMG server. This adds a Firewall Engine exception to enable the headquarters TMG server to connect to the branch office TMG network even when it is in lockdown mode (that is, when the TMG service is down).

Create a new dial-up connection:

Open Network and Sharing Center.
Click A new connection or network.
Connect to a workplace.
Click Use my Internet connection (VPN).
Click I’ll set up an Internet connection later.
Type the external address of the headquarters TMG network.
Type the user credentials. Use the headquarters TMG computer name as the domain.
Click Close.

Right-click the new connection, click Properties, and then click the Security tab:

For Type of VPN Connection, select L2TP/IPSec.
Under Advanced settings, click Use preshared key for authentication.

Make sure that the configuration on the headquarters TMG server is synced by using the Monitoring tab. Connect to the headquarters TMG network by using the newly created connection.

On the headquarters TMG after a VPN client connection is established:

In the headquarters TMG 2010 user interface, under Monitoring, click Sessions, and then confirm that a new VPN Client session was established.
Add a rule that enables all traffic from VPN Clients to Internal and Local Host networks for all users. Create the opposite rule enabling Internal plus Local Host to VPN Clients for all users.
Make sure that there is a respective network routing rule. The default VPN Clients to Internal Network would be sufficient for the routing rule.

On the branch office TMG server by using your existing remote connection:

Stop the Firewall service. To do this, at a command prompt with Administrative permissions, type the following:

net stop /y fwsrv

This also stops the Routing and Remote Access service and disconnects the existing Site to Site connection.

Install TMG 2010 SP1 by typing the following command:

Msiexec /p <full msp path> /L*v <full log path>

On the Locate Configuration Storage Server wizard page, provide explicit credentials. Do not use the Current user option.
After you successfully install TMG 2010 SP1, restart the computer if you have to. Then, if you have to, manually start the Firewall service and verify that the Site to Site tunnel is restored.
Disconnect the VPN client connection.

On the headquarters TMG server after you successfully upgrade the branch office TMG server:

Upgrade the headquarters TMG 2010 server to Service Pack 1. Please be aware that in order to be able to see the branch office TMG server’s configuration on the headquarters TMG server, you must first upgrade the headquarters TMG server to Service Pack 1.

Clean up after upgrade

On the headquarters TMG server:

Restore the VPN Client access configuration that you set in the "Upgrade process: On the headquarters TMG server" procedure. If the Routing and Remote Access service restarts, you may have to wait for several minutes until all the services are started.
Delete the user that was created in step 6 of the "Upgrade process: On the headquarters TMG server" procedure.

On the branch office TMG server:

Delete Firewall Engine exceptions created in step 1 of the "On the branch office TMG server when it is connected" procedure. To do this, follow these steps:

Open a command prompt with Administrative permissions.
Run the following command:

netsh tmg show all

In the command output, locate any dynamic and persistent IDs that corresponds to the IP range that you added in the "Upgrade process: On the headquarters TMG server" procedure.
Run the following commands. Use values for x that correspond to the dynamic IDs and use values for y that correspond to the persistent IDs that you found in step 1.c.:

netsh tmg delete allowedrange id=x

netsh tmg delete allowedrange id=y persistent

Delete the dial-up connection that you created in step 2 of the "Upgrade process: On the branch office TMG server when it is connected" procedure.

Query Words

TMG Service Pack Branch Office

=====

For the most current version of this article please see the following:

2648207: You cannot install a Forefront Threat Management Gateway 2010 service pack on branch office servers

J.C. Hornbeck | System Center & Security Knowledge Engineer

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Some days ago a customer opened a case because an ISA array was randomly refusing all the incoming connections and a restart of the Firewall Service was required to make the connections be accepted again.

After a quick investigation we figured that the cause of the issue was that the Firewall Services went in Lockdown mode after a log failure. Both the Firewall and WebProxy logs were configured to use a Remote SQL server but the connection to the database was not reliable enough to support that critical array, managing a lot of traffic.

Hence, to provide a quick relief and stabilize the system, we chose another logging method: logging to Text Files.
There was not enough space left on the drive C: so we decided to log to a folder on drive E:

Switching to flat files logging failed however unexpectedly and the following error was logged in the Application log:

Event ID 11003, “The failure occurred during reading of logging configuration because the configuration property msFPCLogFileDirectory of the key SOFTWARE\Microsoft\Fpc\Storage\EffecTree1\Arrays\{GUID}\Logs\Proxy-WSP is not valid. Use the source location <location> to report the failure. The error description is: Access Denied.”

Seeing the “Access Denied” error, we checked the rights on the default log folder and found that on that folder SYSTEM and NETWORK SERVICES are assigned Full Control rights.

We also checked the target folder and found that the required rights were already in place – therefore nothing explained an “Access denied” error.

At this point we really needed to figure what is going wrong. Is the error really complaining about insufficient rights on the folder or on the mentioned registry key?

To troubleshoot this problem, we decided to capture a Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645) log while switching the logging method.

Process Monitor allows you to trace File System/ Registry and process/thread activity, along with the result codes. This way we hoped that we can see which exact operation which runs into an “Access Denied” error.

We repeatedthe operation and analyzed the generated PML file by only including “Access Denied” result codes in the display (we used the filteringcapabilities provided by Process Monitor).

This way we found the following:

What we saw is that ISA actually requires permission on the parent folder as well!

After assigning Full Control rights on E:\logfiles folder to SYSTEM and NETWORK SERVICE the switch to Text file logging worked correctly.

This issue is actually covered here:

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

Event 11002 is Issued in the Event Viewer After Modifying the Default Location of the Logging Folder

Problem: After changing the location of the log folder when logging to a file or to an MSDE 2000 database, the following event is issued: Event 11002 Microsoft Firewall failed to start. The failure occurred during creation of logging module because the configuration property PropertyName is not valid. The error description is: The filename, directory name, or volume label syntax is incorrect.

Cause: Permissions were not configured appropriately on the customized logging folder.

Solution: Ensure that permissions are correctly configured. The Network Service must have read permissions from the root partition and any parent folder for the folder. On the logging folder itself, the following permissions are required:

Network Service: Full Control
System: Full Control
Administrators: Full Control

Authors
Gianni Bragante
Support Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Balint Toth
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

In this blog post I want to discuss a solution, which we provided to one of our customers.

The problem was linked to a published web site where specific flash content had not been compressed as expected by TMG/ISA.

The first thing which is important to mention is, that it usually it not necessary to compress flash content. My customer had the need to compress the content because of the client which was accessing the data was connected via a slow satellite link. When analyzing the ISAInfo (http://www.isatools.org/tools/isainfo.zip) output generated by the TMG BPA (http://www.microsoft.com/download/en/details.aspx?id=17730), we could see that ISA-TMG skips the compression for the following contents:

Compression Settings

...

HTTP headers exempt from compression

x-flash-version:

User-Agents exempt from compression

*BITS*

Hence if we want to compress this kind of content we need to “force” ISA/TMG to do it.

Please be aware that with the following changes I want to demonstrate the things you can do by modifying COM properties through scripting in ISA/TMG. Please be aware that all changes you perform through scripts, bypass all the logic verifiers, which are implemented in the UI. Always make a backup of your configuration before performing any changes with a script. Microsoft cannot guarantee that problems resulting from incorrect use of these scripts can be solved! Even if this solution was applied successfully by my customer and tested for a while in his specific environment, this is something Microsoft didn’t test extensively and hence the implementation of the solution itself is at its own risk!

Let’s have a look at the traces to better understand what we are talking about:

The following is a network trace taken before applying our script to modify the compression settings of our ISA-TMG machine:

Allowed www.contoso.com access (test) x.x.x.x Remote Client x.x.x.x 3000 www.contoso.com POST 200

…

POST /xmlservice/RemoteFramework/http/update HTTP/1.1

Referer: app:/core.html

Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, text/css, image/png, image/jpeg, image/gif;q=0.8, application/x-shockwave-flash, video/mp4;q=0.9, flv-application/octet-stream;q=0.8, video/x-flv;q=0.7, audio/mp4, application/futuresplash, */*;q=0.5

x-flash-version: 10,3,181,34

Content-Type: text/xml

…

Content-Length: 110

Accept-Encoding: gzip,deflate

User-Agent: Test Remote Client

Host: www.contoso.com

Connection: Keep-Alive

Cache-Control: no-cache

<update xmlns="test:remoteframework" id="{c095c364-ec83-4cf8-b79b-83601bd1e78e}" version="2011.1.0.22" />

As we can see the response is NOT compressed:

HTTP/1.1 200 OK

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-type:text/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>

<model xmlns="test:remoteframework"><meta><class up="6EDB::2"><attribute up="6EDB::6" type="text" /><attribute up="6EDB::7" type="pointer" /><attribute up="6EDB::75" type="pointer" /><attribute up="6EDB::65" type="pointer" /><attribute up="6EDB::76" type="boolean" /></class><class up="6EDB::1"><attribute up="6EDB::3

....

…

To change the compression behavior, we had to remove the x-flash-version entry from the list of incompressible content in the configuration. As there’s no UI option for this we had to perform these steps by directly modifying the COM properties. Afterwards TMG/ISA did compress the content as requested by the customer.

In the following I want to describe in detail how we can interact with the COM properties.

We can start from the following URL: http://msdn.microsoft.com/en-us/library/ff824938(v=VS.85).aspx

With the following VBScript we can verify which headers are included in the TMG list of non-compressible content:

' Create the root object.

Dim root ' The FPCLib.FPC root object

Set root = CreateObject("FPC.Root")

' Declare the other objects needed.

Dim isaArray ' An FPCArray object

Dim httpHeaders ' An FPCHTTPHeaders collection

Dim httpHeader ' A String

' Get references to the array object

' and the HTTP headers collection.

Set isaArray = root.GetContainingArray()

With isaArray.ArrayPolicy.WebProxy.HTTPCompressionConfiguration

Set httpHeaders = .UnsupportedHeaders

End With

' Display the unsupported HTTP headers.

For Each httpHeader In httpHeaders

WScript.Echo httpHeader

Next

WScript.Echo "done!"

For more information the following link describes the TMG Administration object model:

http://msdn.microsoft.com/en-us/library/ff824018(v=VS.85).aspx

This article gives us an idea which methods and proprieties are supported by the FPCHTTPHeaders collection object:

http://msdn.microsoft.com/en-us/library/ff824942(v=VS.85).aspx

At this point we can start writing the following scripts to remove the x-flash-version entry:

' Create the root object.

Dim root ' The FPCLib.FPC root object

Set root = CreateObject("FPC.Root")

' Declare the other objects needed.

Dim isaArray ' An FPCArray object

Dim httpHeaders ' An FPCHTTPHeaders collection

' Get references to the array object

' and the HTTP headers collection.

Set isaArray = root.GetContainingArray()

With isaArray.ArrayPolicy.WebProxy.HTTPCompressionConfiguration

Set httpHeaders = .UnsupportedHeaders

End With

httpHeaders.Remove(1)

httpHeaders.Save()

WScript.Echo "done!"

And just in case you want to re-add the header type, you can use this script_:

' Create the root object.

Dim root ' The FPCLib.FPC root object

Set root = CreateObject("FPC.Root")

' Declare the other objects needed.

Dim isaArray ' An FPCArray object

Dim httpHeaders ' An FPCHTTPHeaders collection

' Get references to the array object

' and the HTTP headers collection.

Set isaArray = root.GetContainingArray()

With isaArray.ArrayPolicy.WebProxy.HTTPCompressionConfiguration

Set httpHeaders = .UnsupportedHeaders

End With

httpHeaders.Add("x-flash-version:")

httpHeaders.Save()

WScript.Echo "done!"

At this point as we can see from the below test we have that the content is correctly compressed by ISA/TMG even if in the header of the packets the client application is still inserting the x-flash-version entry:

Host: www.contoso.com \r\n

POST /xmlservice/RemoteFramework/http/update HTTP/1.1

Referer: app:/core.html

x-flash-version: 10,3,181,34

Content-Type: text/xml

…

Content-Length: 110

Accept-Encoding: gzip,deflate

User-Agent: Remote Client

Host: www.contoso.com

Connection: Keep-Alive

Cache-Control: no-cache

…

As we can see the response this time is compressed:

HTTP/1.1 200 OK

Connection: Keep-Alive

Content-length:56138

Content-type:text/xml;charset=UTF-8

Content-Encoding:gzip

Vary: Accept-Encoding

.....g.N...}k..D....+.>q.@,`.......X..M`..q.iz..pO..Zc0..H=O{.U........=ju.*_../....e..j7u....."..U.Es\.N.z......?........q...gW.....gm..iO..V.MW.l.....}.../O........l...W..w....?d.........n|n.d..u......{.=.?...Z7................i.U..>.p..mD..D..Q.....R@.......9[.~.Ldi.P*....I}[dv.......^*...C.....k...f..P2..Lf...R._.vqJ.....J...........=-.O..

Author
Andrea Vescovo
Support Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Philipp Sand
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Disclaimer: Many of the steps outlining the configuration of the RSA Authentication Manager v 7.1 software are not directly supported by Microsoft. They should be used as a guideline to help familiarize and guide you in this configuration. For additional assistance in directly configuring the RSA Authentication Manager Software, please review your RSA SecurID documentation.

• Creating Users and Authentication Agents

• Import Tokens from Seeds files

The seed can be an *.asc or *.xml file and is typically supplied with the token<s>. The seed is the tokens’ factory encoded random key. Each token has a unique key (seed). The seed file is imported into the associated RSA Authentication Manager server.

• Add users and assign a Token to each user

User accounts information is added to the RSA Authentication Manager. New users are created under the ‘Identity’ tab using the RSA Security Console. These accounts can be AD accounts or manually created. Each account created is assigned a Token.

• Synchronize the Token

Each Token has a built-in clock that must be in sync with the RSA Authentication Managers’ clock. If the Tokens’ clock is out of sync, authentication will fail. It is typically a good idea to synchronize the Token after assigning it to a user.

• Create Authentication Agents

Authentication Agents are servers or devices that directly authenticate against the RSA Authentication Manager. In this case, the ‘Authentication Agent’ is the TMG server <s>. You should create a unique ‘Authentication Agent’ for each TMG server in the array.

• Use the resolvable FQDN for the Agent Host

When creating the Agent Host entry, make sure to use the Fully Qualified Domain Name of the ISA server. Also make sure that the RSA Authentication Manager server can correctly resolve this FQDN to the correct internal IP address of the TMG server <s>.

• Select “Standard Agent” as the Agent Type

• Create Configuration File (sdconf.rec) and Node Secrets

• Create SDCONF.REC file for each Authentication Agent (each TMG Array Member)

A global SDCONF.REC is generated that contains information for each Authentication Agent. The SDCONF.REC contains RSA Authentication Manager configuration information. This includes ports, processes, etc., essential to the authentication service.

• Copy the SDCONF.REC file from the RSA Authentication Manager to its matching Agent Host computer (i.e. TMG Array Member). Copy to …\system32 and ..\Microsoft TMG Server\sdconfig.

• Create the Node Secrets. The Node Secret is used to authenticate the Authentication Agent machine with the RSA Authentication Manager server. You need to create a separate Node Secret for each Authentication Agent. (Note: There are two separate options available)

1. On the RSA Authentication Manager Server

• Manually create a node secret for each Authentication Agent. Manually creating a Node Secret on the RSA server creates a file call NODESECRET.REC.

• Copy each NODESECRET.REC to the matching Authentication Agent machine (i.e. TMG Server) (Note: location you copy to is not important)

• Copy AGENT_NSLOAD.EXE from the RSA Server to each TMG Array Member (Note: location you copy to is not important)

2. On the TMG Array Members

• Automatically create Node Secrets using SDTEST.EXE on the TMG Array Members (details to follow)

Author

Richard Barker - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

• System Policy Rule and Registry Values

• Enable the SecurID System policy rule on each ISA Array Member

• Add the following String Value registry entry on each TMG Array Member (and then restart the Firewall service):

PrimaryInterfaceIP

HKEY_LOCAL_MACHINE\Software\SDTI\AceClient

Where the string value of PrimaryInterfaceIP is the IP address assigned to the interface that communicates with the RSA Server.

• Create Node Secret on each TMG array member

The “node secret” is a shared secret between the RSA Authentication Manager and each Authentication Agent (i.e. TMG array members). A distinct node secret is required for each Authentication Agent. A node secret for each Authentication Agent can be manually generated on the RSA Authentication Manager…or it can be automatically created during the first successful authentication from the Authentication Agent.

1. If you manually created the node secret on the RSA Server and then copied NODESECRET.REC (and AGENT_NSLOAD.EXE) to the respective TMG Array member <s>…

Manually create the node secret

• On each TMG server, run the following from a command prompt:

AGENT_NSLOAD.EXE –f NODESECRET.REC –p <node secret password>

This creates the Node Secret file (SECURID) in the <windir>\system32 folder.

On a default install of RSA Authentication Manager 7.1, AGENT_NSLOAD.EXE can be found in the following folder:

…\RSA Security\RSA\Authentication Manager\utils\bin\ace-nsload\win32-5.0-x86

IMPORTANT NOTE: see the following blog describing an issue when running the 32-bit version of AGENT_NSLOAD.EXE on 64-bit Windows:

Manually creating the SecurID Node Secret fails on Forefront TMG

• Copy SECURID from …\system32 to …\Microsoft TMG Server\sdconfig.

The AGENT_NSLOAD.EXE creates the node secret file (SECURID) in the <windir>\system32 folder as most Authentication Agents expect the file to be located there. Additionally, the SDTEST.EXE utility also creates, and expects to find, the node secret file in <windir>\system32. However, TMG has a unique folder location for this file. That is …\Microsoft TMG Server\sdconfig. This also holds true for the Configuration File (SDCONF.REC) discussed in Part 1 of this series. This is why it is useful to maintain both the node secret and the configuration file in both of these locations.

SDTEST.EXE uses node secret and config file in <windir>\system32

TMG 2010 uses node secret and config file in …\Microsoft TMG Server\sdconfig

2. If you did not previously create the Node Secrets on the RSA Server, you can manually create the Node Secrets on each TMG Array member by using the SDTEST.EXE utility. This method assumes that there is currently no node secret file (SECURID) located in <windir>\system32…and you DO have a valid Configuration File (SDCONF.REC) located in <windir>\system32.

• On each TMG Server, run the SDTEST.EXE utility. This utility allows you test user authentication from an Authentication Agent to the RSA Authentication Manager Server. Upon a successful user authentication, the Node Secret file (SECURID) will be created in the <windir>\system32 folder.

SDTEST RSA SecurID authentication utility

• Copy SECURID from <windir>\system32 to …\Microsoft ISA Server\sdconfig

Additional Notes on using the SDTEST.EXE utility…

• The SDTEST Authentication Utility is used to verify that a computer running TMG Server can successfully authenticate, using valid credentials, to the RSA Authentication Manager. Again, note that SDTEST.EXE requires the SDCONF.REC configuration file to be located in the <win32>\system32 folder to run and test authentication successfully.

• You may need to run SDTEST.EXE as Administrator if your logged in account does not have the proper permissions to write SECURID to the system32 folder.

• If this is the first time authenticating to the RSA server with this user, you may be prompted to create a PIN. If so, enter a new PIN number. When a new PIN is created, the RSA authentication Passcode for this user will now be:

<PIN><passcode displayed on the token>

• The SDTEST.EXE tool (RSA Test Authentication Utility) is available in the TMG 2010 Tools & Software Development Kit available here:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11183

On the above page, download SdTestPack.exe which contains the utility.

Author

Richard Barker - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

• Configuring Authentication on the Listener

• On the Authentication tab of the Listener, select “HTML Form Authentication” from the drop down list and select “RSA SecurID” as the Authentication Validation Method.

• Check “Collect additional delegation credentials in the form” if you would like TMG to delegate Active Directory credentials to the published server. It should be noted that these “additional credentials” are not used to authenticate to TMG. TMG will simply pass along/delegate those additional credentials to the published server if:

1. The published server requires authentication

2. The Delegation Method of the Publishing rule matches the authentication type configured on the published server

• Configuring Delegation on the Publishing Rule

On the Authentication Delegation tab of the Publishing Rule, choose one of the following options:

1. No delegation, but the client may authenticate directly

User will receive the RSA Authentication form prompting them for their SecurID Username and Passcode.

NOTE: Even if you select “Collect additional delegation credentials in the form” in the Web Listener, those collected credentials will not be sent to the published web server if you choose “No delegation…”

2. Basic, NTLM or Negotiate (Kerberos/NTLM) Authentication

These Delegation options are only available when you have selected “Collect additional delegation credentials” on the Authentication tab of the Web Listener.

The user will receive a form prompting for both RSA SecurID and Active Directory credentials.

NOTE: If you select NTLM or Negotiate (Kerberos/NTLM) delegation, the published server must be configured to accept Integrated authentication.

3. RSA SecurID

User will receive a form prompting for only RSA SecurID credentials. Once the user has successfully authenticated to the RSA Authentication Manager, the TMG server will delegate these RSA credentials to the published server; therefore the published server should be configured to accept RSA credentials. For example, the published server is IIS with the RSA web agent installed. In this scenario, the IIS (with RSA web agent) is another Authentication Agent of the RSA Authentication Manager. The following Blog discusses RSA SecurID Delegation in ISA Server 2006. Most, if not all, of the same concepts apply to TMG 2010

Walk-through for RSA SecurID Delegation for ISA Server 2006

Author

Richard Barker - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

We'd like to advise that Rollup 1 for TMG SP2 is now available.

TMG SP2 Rollup 1 can be downloaded here: http://support.microsoft.com/kb/2649961

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

The Build Number is: 7.0.9193.515

Thank you.

Blank User Activity Report if domain or username contains accented characters

Administrators creating a User Activity Report for users where the domain or user name contain characters that are not included in the

english alphabet, may not be able to see any activity for these users. The report will be generated, but it will not contain any information and only contain the report headers.

Please find an example from my test environment below:

Result:

This problem occurs because of a character conversion problem during the generation of the report.

Fortunatelly, we can control this conversion behavior by setting the follow registry key on the TMG Report Server:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\COM\

DWORD

USE_ACP_FOR_FILTER

Value: 1

After a reboot, let’s make a test with the same user again.

Now, the report looks better.

Author:

Arpad Gulyas

Microsoft CSS Forefront Security Edge Team

Technical Reviewer:

Lars Bentzen

Sr. Escalation Engineer

Microsoft CSS Forefront Security Edge Team

“Slow Performance” accessing CRM IFD published with ISA/TMG

How to patch a TMG array– some thoughts on NLB high availability

How to generate a certificate with subject alternative names (SAN)

Use the Power of Excel Pivot Tables to analyze attacks and session distribution

Scenario 1 – Is the load* in my TMG Web Farm distributed well? (*based on number of requests)

First Steps creating a Pivot Table

Let’s pivot

Scenario 2 - Who is connecting to / attacking my server?

Scenario 3 –Using Excel Pivot Tables to identify an ongoing flood attack

Forefront TMG Service Pack 2 Now Available

New in SP2: Kerberos Authentication in Load Balanced Scenarios

Why didn’t Kerberos authentication work in a HA scenario before?

What did change in SP2 to allow Kerberos Authentication in HA scenarios?

How to configure Kerberos Authentication in TMG HA scenarios?

New in SP2: Site Activity Report

New in SP2: Improved Error Pages

Unable to Join a TMG server to the Stand Alone Array

Introduction:

Scenario:

Troubleshooting:

CONCLUSION:

Use ISA/TMG to distribute your custom WPAD configuration file

Forefront TMG SP2 at Security Talk Show

L2TP VPN issues when utilizing TMG as your RRAS server and NLB is configured on your external Interfaces

You cannot install a Forefront Threat Management Gateway 2010 service pack on branch office servers

Switching to text file logging fails with Event ID 11003

X-flash-version header can prevent ISA/TMG from compressing contents

Walk-through for RSA SecurID Authentication for TMG 2010 Part 1: RSA Authentication Manager 7.1 Server Configuration

Walk-through for RSA SecurID Authentication for TMG 2010 Part 2: TMG Array Members Preparation

Walk-through for RSA SecurID Authentication for TMG 2010 Part 3: Configure TMG Authentication and Delegation

TMG SP2 Rollup 1 available

Blank User Activity Report if domain or username contains accented characters