Introduction

Consider the following scenario: users logging to the websites published through ISA server 2006 using FBA (Forms Based Authentication) with LDAPS as authentication method were take long time to logon. Once they were logged in, the performance was normal. The delay was around 15 to 20 seconds that clearly happened during the initial logon process, after typing the credentials on FBA.

Data Collection

In order to find out why the delay is happening we need to collect data while doing a repro of the issue as follows:

• Test client machine: logon to the website where we get delay in the logon process.
• ISA server: Use ISA Data packager in repro mode with web proxy and web publishing template to collect data, when user is trying to logon to the website.

Data Analysis

When reviewing the netmon captures from the internal NIC of ISA server we found that when ISA Server was trying to communicate with the domain controller there was a delay of 7 seconds that happened during the during SSL handshake as shown below:

The SSL handshake is expected in this case since ISA Server needs to authenticate the user using LDAPS, therefore the first step is to establish the SSL handshake, during this process the domain controller would present its certificate (server authentication certificate) to ISA server for authentication, once this authentication process completes, SSL handshake completes and SSL connection starts (reference : http://technet.microsoft.com/en-us/library/cc514301.aspx and http://support.microsoft.com/kb/257591). As you can see in the above capture, there is a delay in the SSL handshake process.

Troubleshooting and Resolution

There are many components in this process that could be causing such delay, best thing to do is to narrow it down which component is causing that. Here it is the checklist that was used in this scenario:

• Make sure that the server authentication certificate on the domain controller does not have “Client Authentication” attribute enabled as per article http://technet.microsoft.com/en-us/library/cc514301.aspx.
• Make sure that the CRL check is also not an issue as per http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx and http://blogs.technet.com/b/yuridiogenes/archive/2009/03/28/unable-to-logon-using-forms-base-authentication-through-isa-server-2006.aspx.
• For this particular scenario the resolution was: initially it was detected that there was multiple certificates on the Domain Controller and one of the certificates had an unknown Enhanced Key usage type. In collaboration with Directory Services Team, we deleted the wrong certificates(took backup of these certificates along with the private keys) and only kept the correct server authentication certificate. The hotfix http://support.microsoft.com/kb/932834 was also applied, this hotfix makes sure that correct certificate is used on the domain controller and rebooted the domain controller. After that correct certificate was picked and we were able to logon to the websites quickly without delays seen earlier.

As you can see, in this particular scenario ISA Server 2006 was only a victim of an issue on the Domain Controller.

Author
Suraj Singh
Support Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Yuri Diogenes
Sr Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

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

Our focus with Forefront TMG SP1 was to address common customer requests on the new features presented in TMG 2010. Here are some of the new features we are introducing to address these:

User override for URL Filtering

We have added the ability to configure web access rules to allow users to override block decisions (if blocked due to URL filtering):

When a user is blocked by a rule allowing override, there will be an “Override access restriction” button in the error page:

This will allow evaluation of the rules to continue and if allowed, the user will be able to continue to the site, despite the deny rule.

Access to denied sites will appear in the logs with the “Overridden rule” field indicating which rule the user has chosen to manually override:

Reporting enhancements

Improved look and feel

We have changed the whole look and feel of our reports to match that of other Forefront products:

New features included in the reports

We have enhanced our reports to include the new user override and BranchCache integration features.

User activity report

We have added the ability to generate a report for a specific user (or users, separated by semi-colons):

This will generate a report showing the categories and sites the user has been surfing to:

Enterprise level override lists

In the original release version of Forefront TMG, overriding URL categorization was done on the array level only. We have added the ability to generate an override list at the enterprise level, which will affect all joined arrays.

Block category available in error page redirect

When redirecting an error page to a web server, the following tokens will be replaced by the appropriate values:

[DESTINATIONURL] – Displays the denied URL.

[URLCATEGORYNAME] – Displays the denied URL Category name (localized to TMG language);

[URLCATEGORYID] – Displays a number representing the denied URL Category Id.

[OVERRIDEGUID] – Displays the array GUID, necessary if you want to create a user override button similar to the one in the default notification page.

These tokens may be used in the redirection URL (in a Forefront TMG access rule). For example:

http://192.168.1.3/Default.aspx?OrigUrl=[DESTINATIONURL]&Category=[URLCATEGORYNAME]&CategoryId=[URLCATEGORYID]

BranchCache integration

With SP1, if installed on Windows Server 2008 R2 Enterprise, you can configure BranchCache in hosted cache mode through the Forefront TMG Management console:

You can also see the benefits of BranchCache WAN savings in dedicated dashboard counters and in Forefront TMG reports:

Support for installing Forefront TMG SP1 on a read-only domain controller

Forefront TMG can now be installed on a read-only domain controller in order to realize WAN optimization benefits related to local authentication in branch office scenarios.

Support for SharePoint 2010

The service pack adds support for publishing SharePoint 2010.

Getting more information

More information is available in the following links:

·         What's new in Forefront TMG 2010 SP1

·         Installing Forefront TMG SP1

·         Release Notes for Forefront TMG 2010 SP1

All of the URL categories for URL filtering that TMG is aware of are stored in TMG storage at the array level. Here’s an example script that queries for and returns all of the categories. Run the script on any TMG array member.

set root=CreateObject("FPC.Root")

For Each cat in root.GetContainingArray().RuleElements.UrlCategories

    wscript.echo "'" & cat.Name & "' --> " & cat.CategoryID

Next

Alexey Doctorovich, Software Engineer on the TMG Team

(with Nathan Bigman, Content Publishing Manager)

Last week, I encountered a strange issue for network intermittent interrupt.

My customer deployed two ISA Servers as a NLB array, but the network traffic to NLB array is intermittently interrupted periodically after a few minutes.

For example, if I pinged the NLB virtual address or NLB node dedicated address continuously, the output was:

Pinging 10.10.9.2 with 32 bytes of data:

Reply from 10.10.9.12: bytes=32 time<1ms TTL=127

...

Reply from 10.10.9.12: bytes=32 time<1ms TTL=127

Reply from 10.10.9.12: bytes=32 time=1ms TTL=127

Reply from 10.10.9.12: bytes=32 time<149ms TTL=127

Reply from 10.10.9.12: bytes=32 time<241ms TTL=127

Reply from 10.10.9.12: bytes=32 time<213ms TTL=127

Reply from 10.10.9.12: bytes=32 time<234ms TTL=127

Request timed out.

Reply from 10.10.9.12: bytes=32 time<1ms TTL=127

Reply from 10.10.9.12: bytes=32 time=1ms TTL=127

...

Reply from 10.10.9.12: bytes=32 time<1ms TTL=127

Reply from 10.10.9.12: bytes=32 time<156ms TTL=127

Reply from 10.10.9.12: bytes=32 time<202ms TTL=127

Reply from 10.10.9.12: bytes=32 time<212ms TTL=127

Reply from 10.10.9.12: bytes=32 time<190ms TTL=127

Request timed out.

Reply from 10.10.9.12: bytes=32 time=1ms TTL=127

Reply from 10.10.9.12: bytes=32 time<1ms TTL=127

...

After analyzing captured packets, it seems sometimes there is a big delay and timeout from client to NLB array.

If I disable NLB, everything is okay.

This is strange, and my troubleshooting steps included:

• Disabled EnableTCPChimney, EnableRSS, EnableTCPA and DisableTaskOffload in Windows Server 2003, but this didn’t help;
• The NIC mode is “Broadcom BCM5708C NetXtreme II Gige”, and I updated its driver to newest one, but it didn’t help;
• Disabled all offload functions in NIC driver’s advanced features, but it didn’t help;
• Reviewed ISA Server’s configuration - everything is properly configured.
• Asked network devices vendor to review switch’s configuration, but the switch’s configuration seems okay.

This was starting to make me crazy and I thought I didn’t miss anything.

 Finally, I tried to disable all of the advanced features in NIC driver configuration, beside all offload functions, I also disabled Flow Control, Ethernet@WireSpeed, Interrupt Moderation.

After that, everything was okay!!!

This is just a hint for you. Happy to help.

Meibo Zhang, Premier Field Engineer

I'm happy to announce that localized versions of Forefront TMG 2010 Service Pack 1 (SP1) are now available at the Microsoft download center.

Ori Yosefi, Forefront TMG Team

Introduction

Consider a situation where the TMG Administrator was getting an error while trying to install TMG 2010 RTM Standard Edition Server on a domain joined Windows 2008 R2 Server. The error message was:

Setup failed to install ADAM.\r\n (0x80074e46)

The interesting part of this problem was that even after reinstalling the Operating System the same error message was happening again.

This post is about two different scenarios where TMG administrator was facing this issue while trying to install Forefront TMG 2010.

Scenario 1 – The Domain Policy Issue

The first step on each scenario is to understand what the issue, once this phase is done you can build an action plan for data gathering. To Troubleshoot Setup issues on TMG you will need to collect TMG Setup Installation logs, located at %windir%\temp and ADAM Setup log files located at %windir%\debug. Once this is collected you can proceed with the data analysis.

Data Analysis

As previously mentioned, TMG setup log files are by default located at %windir%\temp and the name will start with a pre-defined prefix, such as ISAADAM_INSTALL_XXX. For more information on the file name and description read the article Setup log files at Microsoft Technet. For this particular issue, when the error was happening on the GUI we notice the following error in the in the setup logs.

According to the error message above we can assume that ADAM is failing to install due to a trust relationship issue with the domain. By knowing that, the next troubleshooting step is

to verify if TMG has valid secure channel with the Domain Controller. To do that you can use the NLTEST command as shown below:

Unfortunately, even after perform this step the issue continued to happen. This would lead us to believe that the issue could be with a domain policy that might have been modified causing the restriction on the domain joined server. Browse to Start > Run à gpedit.msc > Computer Configuration > Windows Settings > Security Settings > Local Policies. Check the Security Options and User Right Assignment sections to verify if all the permissions are set to default.

Resolution

In our scenario, the issue seemed to have been due to a modified Domain Policy which restricted the installation of ADAM. We fixed the issue by performing the following steps:

1. Disjoin the Server you are about to install TMG on from the Domain.

2. Run TMG Setup again.

Once this is done, TMG should install fine while in a workgroup since the problem here is related to Domain Policy, at this point you can rejoin the server back to the Domain.

Scenario 2 – Another Domain Policy Issue

Using the same approach as was used before we collected setup log files from TMG and ADAM to start troubleshooting this issue.

Data Analysis

In this scenario the TMG setup failed in ldap_search_ext_s function with same error code as scenario 1

Setup Logs reveal the following:

13:58:07 ISA setup CA ERROR  : pSecurityDesciptorValue == NULL

13:58:07 ISA setup CA ERROR  : Adam_GetContainerSecurity(CN=Sites,CN=Configuration,CN={53A16AA0-C09E-4536-B55D-0FE4210F6D14}) failed, hr = 0x80070002

13:58:07 ISA setup CA ERROR  : Failed to change DACL of Configuration objects (Apply failed) hr = 0x80070002

13:58:07 ISA setup CA ERROR  : AdamSecurity.SetupEnterpriseSecurity failed, hr = 0x80070002

13:58:07 ISA setup CA ERROR  : CreateStorage_Enterprise: Adam_SetupEnterpriseSecurity failed, hr=0x80070002

13:58:07 ISA setup CA ERROR  : Setup failed while creating Forefront TMG storage.

13:58:07 ISA setup CA ERROR  : (Error 28512) Setup failed while creating Forefront TMG storage.

13:58:07 ISA setup CA ERROR  : EXIT: CreateStorage_Enterprise, Custom Action failed (0x643)

13:58:43 ERROR:               Setup failed. Error returned: 0x643

13:58:43 ERROR:               CBasicInstaller: Install failed, hr=0x80070643

13:58:43 ERROR:               Installation failed. hr = 0x80070643

13:58:43 ERROR:               Installation failed, hr=0x80070643

13:58:43 ERROR:               InstallProducts: Install ISA (Core components) failed, hr=0x80070643

13:58:43 ERROR:               Wrapper: Install failed, hr = 0x80070643

13:58:43 ERROR:               Wrapper: DoSetup failed, hr = 0x80070643

13:58:43 ERROR:               Wrapper: DoSetup failed, hr = 80070643

Once the issue was understood we could go to the next level of troubleshooting and use the ldapsd tool to perform the same ldap_search_ext_s function in order to retrieve the security descriptor of cn=sites,cn=configuration <guid>.

This tool queries ADAM the way TMG setup does, run it as follows:

Ldapsd /s <local Server name> /b cn=sites,cn=configuration,cn={guid}

In our case the guid 53A16AA0-C09E-4536-B55D-0FE4210F6D14 was obtained from the setuplog above. Open command prompt with elevated privileges and run the command below:

C:\ldapsd> .\ldapsd.exe /Servername /b "CN=Sites,CN=Configuration,CN={53A16AA0-C09E-4536-B55D-0FE4210F6D14 }" –t

The output of this command in this case:

ldap_init(Host- Servername, port- 2171t) succeeded, version- 3t

options: timelimit- 0t, sizelimit- 0t. hoplimit- 32t

ldap_bind_s() return 0h

ldap_search_ext_s(CN=Sites,CN=Configuration,CN={ 53A16AA0-C09E-4536-B55D-0FE4210F6D14 }, SeInfo- fh) return 0h

ldap_count_entries() return 1t

...processing entry no. 1t, CN=Sites,CN=Configuration,CN={ 53A16AA0-C09E-4536-B55D-0FE4210F6D14 }

Attribute nTSecurityDescriptor not found, err- 87t, 57h, LastLdap- 16t, 10h

ldap_unbind_s() return 0h

C:\ldapsd> .\ldapsd.exe /s Servername /b "CN=Sites,CN=Configuration,CN={ 53A16AA0-C09E-4536-B55D-0FE4210F6D14 }"

ldap_init(Host- Servername, port- 2171t) succeeded, version- 3t

options: timelimit- 0t, sizelimit- 0t. hoplimit- 32t

ldap_bind_s() return 0h

Not using LDAP server control

ldap_search_ext_s(CN=Sites,CN=Configuration,CN={ 53A16AA0-C09E-4536-B55D-0FE4210F6D14 }, SeInfo- fh) return 0h

ldap_count_entries() return 1t

...processing entry no. 1t, CN=Sites,CN=Configuration,CN={ 53A16AA0-C09E-4536-B55D-0FE4210F6D14 }

Attribute nTSecurityDescriptor not found, err- 87t, 57h, LastLdap- 16t, 10h

ldap_unbind_s() return 0h

This means  that ldap_search succeeded and it retrieved the distinguished name, but failed with the security descriptor.

In a good box this will return the following

nTSecurityDescriptor found, length- 648t

Resolution

This issue was found to be due to “Manage auditing and security log" user right on the Default Domain policy, normally this setting is Not Defined.

Normally the TMG server’s local security policies give this right to Builtin\Administrators. Customer had modified their domain policy and set it to right to the Domain\Exchange Enterprise Servers and Domain\Exchange Domain Servers groups ONLY. This change in policy overwrote the local policy and removed this right from the Administrator. To fix this issue the “Administrators” was added to the user right list for the default domain policy.

Authors 
Bala Natarajan 
Sr Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Niladri Dasgupta
Support Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Yuri Diogenes
Sr Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Doron Juster
Sr SDE
Forefront Endpoint Protection Team

1 Introduction

Service Pack 1 (SP1) of Forefront TMG offers enterprise customers the ability to define URL category overrides for URL filtering, at the enterprise level.

Forefront TMG is connected to Microsoft’s URL categorization service (provided by Microsoft Reputation Services, MRS). If the categorization service returns either an “unknown” category or a category that an organization does not necessarily agree with, the organization can override the given category, that is, assign a different category to the URL.

In the RTM version of TMG this ability was available only at the array level. An organization with multiple arrays had to define the overrides for each array separately. Forefront TMG SP1 enables the organization to define enterprise level overrides that are propagated to all arrays with the enterprise configuration.

The enterprise level overrides are merged with the array level overrides on each array. We discuss the merge algorithm in Section ‎3.

2 Defining enterprise category overrides

In order to define (or remove) enterprise level category overrides do the following (see Figure 1):

1. In any TMG Enterprise Edition (EE) management console, click Enterprise at the top left corner.

2. On the Task pane (right side), under Enterprise Tasks, click the Configure URL Category Overrides (3^rd from the top).

The array level (TMG RTM) URL Filtering Settings dialog box will appear but with just one tab – the URL Category Override tab.

Use this dialog box to enter new URLs and categories, to change categories and to remove URLs with their categories, similar to array level overrides.

Figure 1: URL Category Override screen shot

3 Merging enterprise and array level overrides

The merging of the two lists is done as follows:

1. Start with the array level list.

2. For every URL in the enterprise list

a. If the URL is not in the array level override list – add it to the list

b. If the URL is there with a different category – use the array level category (i.e. don’t replace)

This merging algorithm gives priority to the array level overrides.

Note – the merge process considers the URLs www.mycompany.com/homepage and www.mycompany/homepage/ to be the same URL, i.e. the slash at the end does not make a difference.

Once we have a single merged list, the categorization is based on the same heuristic as the array level categorization, i.e. the longest URL in the override list that fits the queried URL. Examples:

1. If you have www.a.com/* categorized as U and www.a.com/a/b categorized as V, then www.a.com/a will be categorized as U, www.a.com/a/b as V and www.a.com/a/b/c as U.

Author: Mody Lempel.

Reviewers: Juda Thitron and Roman Golubchyck

Introduction

One of the features introduced in Forefront TMG SP1 (available here) is User Override for Blocked URL Categories. This feature warns the user about attempts to browse to a Web site that is blocked by the firewall policy, but still allow this user to explicitly override the restriction and access the site.

This allows administrators to evaluate a URL filtering policy before actually enforcing it as well as use the override pages to educate the organization about what is the acceptable Web usage policy without forcefully preventing access.

Forefront TMG administrators should keep in mind that User Override restriction is controlled by the end-users and shouldn't be considered a security feature.

Administering User Override

Provisioning

User Override option is enabled per deny rule.

Assume the following firewall policy:

To enable user override option in the first deny rule, the administrator needs to open its properties on the General page and select Allow user override.

The secondary checkbox allows applying time constraints to the User Override. It defines how long the user may browse the overridden site until he's requested to override the block again.

Note that the feature is based on a deny rule, which blocks the request unless overridden and is ignored otherwise. So by no means does this rule grant access to the Web. In order for the request to be allowed through there must be an additional access rule allowing it after the overridden rule.

User experience

When the user browses to a site that is blocked by a rule with User Override option enabled (e.g. hotmail.com in our case), the user sees the following webpage:

The page is provided by Forefront TMG and requires the client browser to be able to run JavaScript. Without JavaScript, the button won't function properly and the restriction wouldn't be overridden. When the user presses the button, he's granted access to all pages categorized as Web E-mail under the current domain (in our case it would be hotmail.com).

Override is done per domain and category, so if there are sites with different blocked categories under the same domain, the user will have to override access restriction for each category separately.

Consider the following example, where the firewall blocks sites categorized Sport and News. The blocking rule has the User Override option enabled. Let's assume that sites contoso.com and contoso.com/news are categorized as News; and contoso.com/sport is categorized as Sport. When user first accesses contoso.com/news, he'll override access restriction. After that when he accesses contoso.com – he won't be required to override, since he already has access to News on contoso.com. However, if he tries to access contoso.com/sport, he'll be required to override again. As a result he'll then have override access for Sport and News categories on contoso.com domain.

Each time a user overrides access restriction, this action is logged and enters the statistics shown in reports.

Override persistence

After a user acquired access by means of User Override, he can re-enter the site and its sub-sites (as long as they have the same category), until one of the following happens:

1. User closes the browser

2. The time period defined in the rule expires

In either of these cases, the next time the user tries to enter this site he'll receive the error page with override option.

Limitations

User Override feature has following restrictions:

· The protocol must be HTTP – unfortunately, HTTPS is not supported in SP1. This is because of a security feature in many of the browsers which prevents the browser from showing any pages (such as the user override HTML page) before the SSL tunnel was established. This means the administrator needs to create two Deny rules – one for HTTP with User Override option and another for HTTPS with strict deny.

· Destinations must contain only URL categories or categories sets. User Override option doesn't support other types of destinations.

· Content-types must be set to "All content types" (default option)

A rule with User Override option cannot be created if any of these restrictions are violated.

Logging

Let's continue to use the policy example that blocks the Web E-mail category.

When user accesses the site and performs User Override, the following entries will appear in the log:

The first line indicates the blocked requested, which triggered the error page.

The second line shows the User Override request that was served without being evaluated by the firewall, so it doesn't have a matching rule.

The third line shows the same request as in the first line, but now it is allowed due to the User Override. Here, the log column Overridden Rule (new column introduced in SP1) shows the rule that initially blocked the request but was overridden.

Reports

Among the brand new reports delivered with Forefront TMG SP1, there are two reports dedicated to the User Override feature:

These reports allow the administrator to analyze whether the overridden URLs are miscategorized and who are the users that used the feature the most.

Author: Dima Datsenko

Reviewers: Ori Yosefi, Nathan Bigman

After writing the previous blog about issues during the TMG setup, I encountered another issue where the TMG install completed in 1 minute without any specific error. As soon as the install started and after walking through the initial couple of screens where we add the internal network the install screen just proceeded further to the Finish option without installing any core or optional components. The total install time was well under one minute and so it definitely indicated a strange behavior. As usual we started the troubleshooting by looking at the TMG setup log at %windir%\Temp folder. All Instances of TMG install attempt will have following files ISAWRAP_xxx.log ,ISAFWUI_xxx.log , ISAFWSV_xxx.log ,ISAADAM_Install.log where xxx is the installation instance number , a random number generated at the time of each install. Normally we begin with looking at the ISAWARP_XXX and in this instance we saw the following failure:

11:32:25 INFO: Installer activated, command-line=''

11:32:25 INFO: Installing ISA (Core components)...

11:32:25 INFO: CFirewallInstaller: Activating installation, command line args = '-I "C:\TMG 2010 ENT\FPC\MS_FPC_Server.msi "WRAPPER=1 ARPSYSTEMCOMPONENT=1 MEDIAPACKAGEPATH=\FPC\ REBOOT=ReallySuppress'

11:33:27 ERROR: Setup failed. Error returned: 0x643

11:33:27 ERROR: CBasicInstaller: Install failed, hr=0x80070643

11:33:27 ERROR: Installation failed. hr = 0x80070643

11:33:27 ERROR: Installation failed, hr=0x80070643

11:33:27 ERROR: InstallProducts: Install ISA (Core components) failed, hr=0x80070643

11:35:58 ERROR: Wrapper: Install failed, hr = 0x80070643

11:35:58 ERROR: Wrapper: DoSetup failed, hr = 0x80070643

11:35:58 ERROR: Wrapper: DoSetup failed, hr = 80070643

11:35:58 ERROR: Setup of ISA failed. Return value: SETUP_ERROR_ISA

As we can see from the start of the Install to the fist failure line it is about a minute .

Using the Err.exe tool this error code translates to ERROR_INSTALL_FAILURE:

C:\Err>err 0x80070643

# as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0x643

# for hex 0x643 / decimal 1603

ERROR_INSTALL_FAILURE winerror.h

# Fatal error during installation.

# 1 matches found for "0x80070643"

Since this does not give much to investigate we moved to the next file ISAFWSV_xxx.log file and looked at the log entries at the first failure time of 11:33:27 and it revealed the following

ISAFWSV_xxx.log

MSI (c) (CC!F4) [11:33:27:775]: Product: Microsoft Forefront Threat Management Gateway EE -- Setup failed while attempting to display the dialog box used to define the Internal network.

Action ended 11:33:27: DoLatUI. Return value 3.

DEBUG: Error 2896: Executing action DoLatUI failed.

Internal Error 2896. DoLatUI

This error of failing to configure the LAT table corresponds with our install screen action of attempting to choose the “internal” network. Still this does not reflect the real reason for failure. The next action was to look at the next install log entries in the file ISAFWUI_xxx.log at the time of failure 11:33:27 and it revelaed the following

11:33:27 ISA setup CA INFO : Path for binaries is: C:\TMG 2010 ENT\FPC\Program Files\Microsoft ISA Server\

11:33:27 ISA setup CA INFO : Dll to load = msfpcsnp.dll

11:33:27 ISA setup CA INFO : Source path = C:\TMG 2010 ENT\FPC\Program Files\Microsoft ISA Server\msfpcsnp.dll

11:33:27 ISA setup CA WARNING: LoadLibraryEx failed. Error=0xc1. In order to understand the problem try to run depend.exe on msfpcsnp.dll in directory C:\TMG 2010 ENT\FPC\Program Files\Microsoft ISA Server\

11:33:27 ISA setup CA ERROR : GetHandleToDll failed. hr: 0x800700c1

11:33:27 ISA setup CA WARNING: GetHandleToDllEx failed. hr=0x800700c1

The Error code 0x800700c1 translates to bad ERROR_BAD_EXE_FORMAT:

C:\ Err>Err 0x800700c1

# as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0xc1

# for hex 0xc1 / decimal 193

ERROR_BAD_EXE_FORMAT winerror.h

# %1 is not a valid Win32 application.

# 1 matches found for "0x800700c1"

From the above log we can see the the error happened at the time of loading the msfpcsnp.dll file from the extracted install folder.

We looked at the file and it looked normal initially, but looking at the properties of the file revealed the following

Even though the file size looked right, it did not have any other file property like Digital signature or the file version info as would normally see in a working file

While checking further, we found the installation .iso file was downloaded from regular Volume License site, but the ISO file was extracted using a ISO extractor tool. The ISO extractor tool stripped the file properties that had the digital signature and version info. Then we got the ISO cut into a DVD and installed from the DVD drive. This resolved the issue.

Author 
Bala Natarajan 
Sr Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Yuri Diogenes
Sr Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

In some circumstances while using Malware Inspection feature on TMG you might wonder if certain malware is covered by this feature. Malware Inspection feature uses Microsoft AV Engine and the definition number that you see on TMG Update Center is same or higher than the definition from Malware Protection Center portal as you can see below:

If you go to this portal you will see a table with the malware name and the alert level, those are malwares that Microsoft AV engine is capable to detect. You should always have the latest version for malware inspection, in other words, the version on TMG should be the same or higher than the portal. If TMG version is lower than the one listed on the portal, try to force an update using the button below under TMG Update Center:

If you need to see if a lower version is capable to detect a malware you can switch to another version on the portal using the summary option on the right side of the page:

Last but not least, if you need to troubleshoot definitions update, read the blog post from Jim Harrison Using Windows Server Update Service for the TMG Update Center.

Author
Yuri Diogenes
Senior Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Bala Natarajan
Senior Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Introduction

In ISA Server 2004 and 2006 there was a difference in the behavior of configuration changes between Standard Edition and Enterprise Edition.

In Standard Edition, the configuration change operation was synchronous. This means that applying the configuration completed after the new configuration was stored and loaded by the ISA Server computer (which was always the same computer).

In Enterprise Edition, the configuration change operation was asynchronous. This means that applying the configuration completed after the new configuration was stored to the configuration storage server (CSS). However, for the configuration to take effect the array members still had to read the new configuration from the CSS and load it.

In order to check if the configuration reload was completed, the administrator needed to check the configuration status tab in the ISA Server console, as in the screenshot below (taken from a Forefront TMG computer):

Making configuration changes synchronous

In Forefront TMG 2010 configuration change is by default asynchronous for both Standard Edition and Enterprise Edition.

Some people have asked to be able to change the behavior to synchronous, so that the administrator will know the configuration has been loaded by the TMG computers when the Save Configuration Changes completes.

In order to change the behavior, create a text file with the following information and import it into the registry:

Windows Registry Editor Version 5.00

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

"WAIT_FOR_RELOAD_DURING_APPLY"=dword:00000001

Next time you apply a configuration change, a new step will be added to the progress bar in the Save Configuration Changes dialog:

This will make the dialog wait until the configuration has been loaded by all the TMG servers and only then finish:

Note

Please note that by default, the dialog box will only wait for 90 seconds for the Forefront TMG servers to reload the configuration. This period can be configured by creating and setting a WAIT_FOR_RELOAD_SEVER_TIMEOUT_IN_SECONDS registry key in the same location -[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\UI].

Author: Ori Yosefi

Introduction

Consider a scenario where an ISA administrator configures ISA Server 2006 to publish OWA with Smart Card /Client Certificate Authentication and Kerberos Constrained Delegation. When external users try to access OWA they get a 500 internal server error with the URL being denied by the ISA Server after they put in the pin to authenticate.

Troubleshooting

The first step to troubleshoot such an issue would be to verify if one of the authentication and/or delegation methods is failing. In our case, we changed the authentication on the Listener of the Publishing rule to FBA with Kerberos Constrained Delegation. We noticed that external users were now able to login to OWA which would prove that the issue is specific to Smart Card/Client Certificate Authentication.

To verify the reason behind the failure, we plugged the Smart Card Reader to the ISA Server and ran Certutil –scinfo against the domain. We noticed the following error as the output:

A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478)

We checked the Trusted Root CA store on the local computer and found that all the appropriate Root CA certificates were installed. Further investigation revealed that the Enterprise NTAuth registry key was not populated on the ISA Server. We also found that the the Enterprise NTAuth store on the ISA server was empty. Checked the Enterprise NTAuth store on the Domain Controller and it was populated with all the Root CA Certificates. These certificates needed to be present in the NTAuth Store of the ISA Server.

Note: To view the Enterprise NTAuth store, you need to have the Windows 2003 Resource Kit installed. You can then refer to KB295663 for more information on how to import to import third-party certification authority (CA) certificates into the Enterprise NTAuth store.

Resolution

The following steps were performed to export the Root CA Certificates from the Local Store to the NTAuth Store:

1. On the ISA Server browse to the Certificates mmc.
2. Export the Root CA Certificates used for Smart Card Certificate issuance to .cer files.
3. Run the following command on the ISA Server using CertUtil to import the certificates to the NT Auth Store.

Certutil -AddStore -Enterprise NTAuth CaCertificate.cer

This populates the NTAuth Store with the required certificates and external users now can access OWA with CAC and KCD.

Authors
Mohit Kumar
Sr Support Escalation Engineer
Microsoft CSS Forefront TMG Team

Niladri Dasgupta
Support Engineer
Microsoft CSS Forefront TMG Team

Technical Reviewer
Yuri Diogenes
Sr Support Escalation Engineer
Microsoft CSS Forefront TMG Team

The ISA documentation How to Configure ISA SSL Bridging for System Center Configuration Manager Internet-Based Client Management has been updated with the following information:

• The certificate requirements for clients that are members of the forest can use a certificate with a DNS SAN value, for example: DNS=computer1@contoso.com.  This means that you can deploy these certificates by using the standard Workstation Authentication certificate template and autoenrollment, which greatly simplifies client certificate deployment.  Previously, only a UPN SAN value was supported, which could not be deployed by using autoenrollment. Note that workstations that are not joined to the forest still require manual deployment and the UPN SAN value in their certificate.
• Security references are added that explain the differences between SAN attributes and SAN extensions, and security best practices for a production environment: How to Request a Certificate With a Custom Subject Alternative Name.
• Instructions are added for configuring ISA Server for the Internet-based software update point.  Separate instructions are required because WSUS does not support client certificates.
• Instructions are added for configuring the HTTP methods allowed for the Internet-based management point and distribution point, to help increase security. 

Note:  HTTP methods for the Internet-based software update point are not included because the HTTP verbs used by WSUS are not documented for the latest WSUS versions.  However, previous versions document these as GET, HEAD, and POST and our preliminary testing confirms that these verbs are still used.  If you want to increase security for the Internet-based software update point by restricting the HTTP verbs that are allowed, test this configuration yourself by using the instructions "To Modify the Web Publishing Rule to Enable the required HTTP Methods" and for the HTTP methods, substitute the following HTTP verbs: GET, HEAD and POST.

If you need to manually request certificates with a version of a Certification Authority (CA) that does not support Web enrollment for the computer store, see How to Request a Certificate With a Custom Subject Alternative Name for alternative certificate request methods.

This updated documentation has been published with the Community Content footer, so that you can share additional information about this scenario configuration with other customers. 

Our thanks to Jim Harrison (Program Manager for Forefront TMG), Jason Jones (Forefront MVP), and Rachel Aldam (Technical Writer, Identify and Security Division) for their help in updating this documentation for our customers.

- Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.

Introduction

While acting as proxy, Forefront TMG can allow or deny Web traffic originating from the protected web clients. In case of denied traffic Forefront TMG sends to the client an error page to display in the browser. The page contains basic information about the reason the traffic was denied:

The major limitation of these pages (in Forefront TMG RTM) is that they must be self-contained single pages. That means, they cannot contain images and cannot load other pages since they're viewed in the context of the originally requested page (the one that was denied). By default the pages are localized to the Forefront TMG installation language and due to the limitation they cannot be customized to dynamically adjust to the viewing browser locale.

Instead of showing these error pages upon denied access, the Forefront TMG administrator may configure the denying rule so that the proxy would respond to the denied request with a redirect to another URL (typically residing within network protected by Forefront TMG):

After the redirect, the target page is free of the built-in error pages’ limitations because of the explicit redirect resulting in the correct browsing context. However, new limitations are introduced – after the redirect all the data related to the denial reason is lost.

The "Redirect on Deny with dynamic parameters" feature that was released with Forefront TMG SP1 allows the administrator to specify a token in the redirection URL, which is substituted with run-time data each time the redirect is enforced.

Feature Description

In Forefront TMG SP1 the administrator can use the following token in a redirection URL:

[DESTINATIONURL] – substituted with the originally denied URL.

[URLCATEGORYNAME] – substituted with denied URL Category name in the Forefront TMG installation language.

[URLCATEGORYID] – replaced with a number representing the denied URL Category Id, necessary if you want to display the URL category in a language different from the Forefront TMG installation language.

[OVERRIDEGUID] – replaced w/ an array GUID which is to be used for user override feature purposes.

For example, a web user tries to access www.contoso.com, which is categorized as "Entertainment". Forefront TMG policy is configured to redirect "General Business" requests to http://192.168.1.2/Default.aspx?OrigUrl=[DESTINATIONURL]&Category=[URLCATEGORYNAME]&CategoryId=[URLCATEGORYID]

After the proxy renders the token, the user will get redirected to:

http://192.168.1.2/Default.aspx?OrigUrl=www.contoso.com&Category=Entertainment&CategoryId=82

It's the administrators' responsibility to ensure that http://192.168.1.2/Default.aspx exists, is accessible and handles passed parameters correctly.

Here's a sample script that would handle this specific redirection syntax:

<%@ Page Language="VB" validateRequest=false %>

<HTML>

<BODY>

<span id="Url">Url = <%Response.Write(Server.HtmlEncode(Request.Params("OrigUrl")))%><br></span>

<span id="Category">Category = <%Response.Write(Server.HtmlEncode(Request.Params("Category")))%><br></span>

<span id="CategoryId">CategoryId = <%Response.Write(Server.HtmlEncode(Request.Params("CategoryId")))%><br></span>

</BODY>

</HTML

After server side rendering, the HTML source will look like this:

<HTML>

<BODY>

<span id="Url">Url =www.contoso.com<br></span>

<span id="Category">Category = Entertainment<br></span>

<span id="CategoryId">CategoryId = 82<br></span>

</BODY>

</HTML>

Note:

In the given example we used the InnerText property and the Server.HtmlEncode function to prevent cross-site scripting.

We recommend sticking to this example pattern when creating custom error pages designed for Forefront TMG redirections.

Additional aspects

HTTPS inspection

In order not to disclose the sensitive information that can be contained in the path and\or parameters of a denied HTTPS URL, we can't forward the whole URL to the redirection page. Due to privacy reasons (since redirect can be done on non-encrypted channel), only the hostname of the denied URL will be shown in this case:

If user tried to access https://contoso.com/some _secret_path,

In case of HTTPS inspection enabled he'll see in the sample:

Url: https://contoso.com...

In case of HTTPS inspection disabled he'll see

Url: contoso.com:443

Long URLs

As defined in IE RFC, the maximal URL length that can be processed is 2047 (browser limitation). So if the redirection URL grows larger than this number due to token substitutions, the original denied URL parameter will be cut to fit the size. In this case an appendix of <...> will be appended to indicate that the URL was cut.

Author: Dima Datsenko

Reviewers: Ori Yosefi, Nathan Bigman

Introduction

Forefront TMG 2010 introduced URL filtering, which enables administrators to create rules that allow or block access to Web sites based on their categorization in the URL filtering database. When a request to access a Web site is received, Forefront TMG queries the remotely hosted Microsoft Reputation Service (MRS) to determine the categorization of the Web site. If the Web site has been categorized as a blocked URL category or category set, Forefront TMG blocks the request.

If a user requests access to a Web site and discovers that access to the Web site is blocked, he receives a denial notification that includes the URL category which resulted in the denied request. In addition, sites can be excluded from HTTPS and malware inspection based on their category.

The Forefront TMG URL filtering mechanism uses URL categorization provided by the MRS Web service. Some URLs have multiple categories, for instance http://finance.yahoo.com is categorized as
Financial, Online Trading and News. Forefront TMG’s policy and its rule engine are based on a single category per URL. This means that in case the MRS responds with multiple categories per URL, Forefront TMG will need to choose one of those categories as the “most relevant” URL category. In order to do that, Forefront TMG uses a pre-defined category precedence list.

Category precedence list

Multiple categories for a single requested URL are sent back by the MRS web service with no concept of prioritization or order. However, Forefront TMG uses single-URL categorization in its policy. Therefore, we need a mechanism to choose “most relevant” category from a set of URL categories provided by MRS. For that task Forefront TMG has a category precedence list, where categories are ordered by significance. The rule of thumb is that more malicious, harmful and non-productive categories have higher precedence.
The list is pre-defined and can’t be changed by administrators. The list for Forefront TMG SP1 is below.   

When Forefront TMG receives an HTTP request, it retrieves its URL category from MRS or from internal cache. If the URL has several categories, Forefront TMG applies category precedence rules according to the precedence list. The category with the highest precedence is used by the Forefront TMG rule engine, while all other categories are disregarded.

Let’s see an example. When a user browses to http://msdn.microsoft.com, MRS categorizes that URL as General Business and Technical Information,
as can be seen from the MRS portal at http://www.microsoft.com/security/portal/mrs/

Since “Technical Information” has higher precedence than “General Business”, TMG will use the “Technical Information” category for that URL. The “Technical Information” category will be applied for rules, will appear in log/reports and will be presented to users in denial pages.  It will also be matched to HTTPS inspection and malware protection exemptions categories.
We can use the Forefront TMG UI Category Query tool to validate that.

Summary

In this blog, I showed that although MRS provides several categories for each URL, Forefront TMG rules engine decisions are based on one category only.
This “most relevant” category has the highest precedence in the pre-defined precedence list. Administrators can verify which category was chosen by Forefront  TMG using the Log or Query Category UI.

Author: Igor Zarivach
Reviewers: Ori Yosefi, Roman Golubchyck

Introduction

Forefront TMG 2010 introduced a feature called HTTPS inspection, which allows inspecting HTTPS traffic in the same way as HTTP traffic.

Without HTTPS inspection, the client and server create an SSL tunnel and all traffic between them is encrypted. This prevents TMG for inspecting the traffic and protecting the user.

In HTTPS inspection mode, two SSL tunnels are created: client-TMG and TMG-server. Then, all traffic in network is encrypted, but TMG decrypts all traffic from client, inspects it, encrypts and sends to server and vice versa. HTTPS inspection provides the following benefits:

· Server certificate is validated. Servers with invalid certificates are blocked.

· Forefront TMG policy is applied even for encrypted communications.

· Forefront TMG web filters are alo applied to encrypted requests. In particular, the traffic is scanned with EMP, NIS and other Forefront TMG features to help protect from malware/vulnerabilities.

However, in some cases, HTTPS inspection cannot or shouldn’t be applied. This happens in some of the following cases:

• Privacy:

• Administrators can choose not to inspect sites that contain sensitive user information, like health, bank, stock etc. Such sites could be exempt from inspection by Forefront TMG.
• There are some clients whose traffic commonly include sensitive information (like company managers, lawyers etc.). Traffic from such clients could also be exempted.
• Client certificate authentication. Since the client certificate is only available on the client machine, TMG will not be able to authenticate to the server.

• ·Performance: HTTPS inspection has a performance impact due to the tunnels’ creation and traffic inspection. If an administrator trusts a particular site, he may elect to exclude it from HTTPS inspection to reduce the load on the Forefront TMG server.
• Misconfigured destination server: in some cases, destination servers contain an invalid certificate (self-signed, expired, etc.). While this is bad practice, it does not necessarily represent a malicious site.

For these reasons, Forefront TMG introduced two HTTPS exclusion mechanisms: destination exceptions and source exceptions.

Destination Exceptions

In order to configure exclusion by destination, open the HTTPS inspection UI (Web access policy->Configure HTTPS inspection) and go to the “Destination exceptions” tab (see screenshot below).

You can add the following network objects to the destination exception list: DomainNameSets, UrlCategories and UrlCategorySets.

Destination exception matching is performed in the following way:

1. Forefront TMG establishes an SSL tunnel with server. As a part of establishment, TMG receives the server certificate.
2. Forefront TMG retrieves the certificate’s subject name and names in SAN (Subject Alternative Name) extension, if existing. For each name, Forefront TMG looks for a match in the destination exclusion list. If there is at least one match, the site is excluded.
3. Even if the site is excluded, Forefront TMG performs a certificate check. The policy of certificate check is different for different types of exclusions (we will discuss this below). If a certificate doesn’t pass certificate policy checks, the site is blocked. Otherwise, the site is excluded from HTTPS inspection.
4. In case the site is excluded from inspection, Forefront TMG closes the connection with the server, opens a new one and moves to data pump mode: client and server establish SSL tunnel and TMG just transfers data from client to server and vice versa.

Source Exceptions

In order to configure exclusion by source, open the HTTPS inspection UI (Web access policy->Configure HTTPS inspection) and go to the “Source exceptions” tab (see screenshot below).

You can add to the source exception list the following network objects: Computers and Computer sets.

Source exception matching is performed in the following way:

1. Forefront TMG establishes an SSL tunnel with the server. As a part of establishment, Forefront TMG receives a server certificate.
2. Forefront TMG checks whether the client IP is in the source exclusion list. If yes, the traffic will be excluded.
3. Even if the traffic is excluded, TMG performs a certificate check. The policy of certificate check is different for different types of exclusions (we will discuss this below). If a certificate doesn’t pass certificate policy checks, the site is blocked. Otherwise, the traffic is excluded from HTTPS inspection.
4. In case the traffic is excluded from inspection, Forefront TMG closes connection with server, opens a new one and moves to data pump mode: client and server establish an SSL tunnel and TMG just transfers data from client to server and vice versa.

Certificate validation

One of the main added values of HTTPS inspection is validating server certificates. Browsers also perform a similar check and give warnings to users. However, many users ignore such warnings and continue browsing to malicious sites. HTTPS inspection completely blocks such sites.

There are five different error checks that can be performed by HTTPS inspection on server certificates:

• Certificate type – server certificate must be applicable for server authentication
• Name mismatch – server certificate subject name or one of names in SAN extension must correspond to host name in URL
• Trust – server certificate must be trusted on TMG server
• Expiration – server certificate must have valid start and end dates
• Revocation – server certificate must be not revoked.

In case of inspection, TMG by default performs all these checks. Two notes:

• Expiration and revocation are configurable globally on the “Certificate validation” tab of HTTPS inspection dialog.
• Name mismatch, trust and certificate type checks are always performed by TMG in inspection mode. This happens because in case of inspection, TMG is responsible for certificate validity.

In case of exclusion, there are two options: “certificate validation” and “no certificate validation”.

• Certificate validation: TMG performs certificate type check, name mismatch check and trust check.
• No certificate validation: TMG performs certificate type check only.

For destination exceptions, certificate validation is configured per object in the exclusion list (see second column in destination exception screenshot). For each object, you can change its validation mode by pressing on “Validation” and “No Validation” button (it is the same button, it just changes capture according to current object state)

The table below summarizes certificate checks for each mode:

New in TMG service pack 1– “complete” source exception

A new “No certificate validation” checkbox was added to the source exception configuration in TMG service pack1. It is configured globally for the whole exception list (see checkbox in second screenshot).

This mode can be used to completely bypass the entire HTTPS inspection mechanism for the machines in the source exceptions list. Please note that this mode is less secure as in this case TMG will not validate the server certificate in any way. It is usually recommended to prefer destination exceptions.

Choosing the right exception method

It is usually recommended to use destination exceptions. By choosing destination exception, you only exempt sites that you trust (either because they are well managed or because they have some validation problem, such as a self-signed certificate).

Source based exceptions may be used to exempt machines when you do not yet know the specific destinations that needs to be added to the exception list or if these are client computers that you do not want to inspect for some reason.

Author: Roman Golubchyck

Reviewer: Ori Yosefi

Introduction

Consider a scenario where a TMG administrator has configured their TMG Server 2010 installed on a Windows Server 2008 R2 for inbound VPN connections. External VPN users (two or more users) are behind a NAT device, which NATs all outbound L2TP VPN traffic. When users try to connect using L2TP VPN connections, only one user from this network can connect at a time. Every connection attempt from another user fails with the following error:

In this case, since users can connect to VPN as long as they are unique from behind a NAT device, the basic VPN configuration on the TMG Server would not have any problem.

To verify if the issue is specific to L2TP VPN, we configured the TMG VPN Server to allow PPTP. Tests from the client end revealed that we could successfully establish more than one PPTP VPN connections. So the test confirmed that the issue was specific to L2TP VPN connections.

Since in such a scenario, traffic would appear to come from the same external IP, it is normal to think that the TMG server might be dropping the connections as per its Flood Mitigation settings. We did notice some TCP/IP Connection Limit Exceeded errors on the TMG Server in this case. So we created an exception list for the incoming IP address in the Flood Mitigation Settings. Though we see the TCP/IP connection Limit errors go away, this did not resolve our issue.

TMG Live logging shows Initiated and Closed Connections without much detail. Network traces do not help much in this case as the traffic is L2TP and encrypted.

To isolate whether the issue was related to TMG or RRAS, we set up a parallel VPN setup with a Windows Server 2008 R2 machine, configured as RRAS. We were able to reproduce the issue successfully without installing TMG on this machine.

Resolution

The problem in our scenario turned out to be specific to L2TP VPN traffic from behind a NAT device to Windows Server 2008 R2 RRAS Server. This was identified as a problem in Windows Server 2008 R2 and the following KB article addresses this issue. The public hotfix included within the article below updates the Fwpkclnt.sys and Tcpip.sys files:

Only one of the clients that are behind the same NAT device can create L2TP VPN connections to a VPN server that is running Windows Server 2008 R2

Author
Niladri Dasgupta
Support Engineer
Microsoft CSS Forefront TMG Team

Technical Reviewers
Yuri Diogenes
Sr. Support Escalation Engineer
Microsoft CSS Forefront TMG Team

Mohit Kumar
Sr. Support Escalation Engineer
Microsoft CSS Forefront TMG Team

Introduction

Consider a scenario where users are not able to authenticate using FBA with LDAP to access the websites published through ISA server. In this scenario ISA server was part of one domain (contoso.com) and users who would access the website are part of another domain (fabrikam.com). FBA with LDAP is used on the web listener of the web publishing rule to authenticate the users from fabrikam.com’s domain controller. But these users are not able to authenticate using this method.

Note: More about Ldap authentication please refer http://technet.microsoft.com/hi-in/library/bb794854(en-us).aspx#ldap

Data Collection

To troubleshoot the issue took network traces while creating LDAP user set on the ISA server (reference http://technet.microsoft.com/hi-in/library/bb794854(en-us).aspx#LDAPUser), which failed with error, “access to LDAP server is denied.”

Data Analysis

In the network captures we found:

1. LDAP Bind Request as below

2. LDAP Bind Response as below

Troubleshooting and Resolution

We tested the user credentials from a machine which is already part of the fabrikam domain and we were able to authenticate using same credentials. Then as per http://blogs.technet.com/b/isablog/archive/2008/04/17/isa-server-2006-form-base-authentication-problem-using-upn-logon-format-on-a-multiple-domain-environment.aspx we checked the HKLM\System\CCS\CONTROL\LSA\LMCompatibilityLevel on the ISA server and it was set to 0x2 (only allow LM and NTLM). Then checked same on the Domain Controller (which it was windows 2008 server) of the domain where users were located and it was set to 0x5(only allow NTLMv2 and block LM /NTLM).Since Domain controller only allows NTLM v2 it was not authenticating the request coming from the ISA server which was sending it with NTLM v1 as we can see in the NTLM challenge response in the network traces.

To resolve the problem we set LMCompatibilityLevel key on the ISA server to 0x3 (although we could also set it to 0x4) and restarted the ISA server. After that users were able to normally logon via FBA.

Author
Suraj Singh
Support Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Yuri Diogenes
Sr Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Introduction

Cannot create a weblistener using any port other then 80 for non-ssl website publishing or trying to modify WebListener settings via UI for non-ssl website publishing. For example trying to use port 8080 on the listener as the port number in front of non-ssl connection option it gives an error:

Repro steps

1. Create a weblistener for non ssl connection
2. In weblistener properties, click on connection tab and change the port to 8080
3. Will receive an error: “web listener is configured to use SSL, you must specify a certificate".

Workaround:

Run the script:

========================================

ListnerName= WScript.Arguments.Named("Listener")

ListnerPort= WScript.Arguments.Named("Port")

set curArray = CreateObject("FPC.Root").GetContainingArray()

set listener = curArray.RuleElements.WebListeners.Item(ListnerName)

listener.Properties.TCPPort = ListnerPort

listener.Save

=========================================

1. Save it as SetListenerPort.vbs
2. Run it from elevated command prompt
3. SetListenerPort.vbs /Listener:<ListenerName> /Port:<PortNumber>
4. Where <ListernerName> and <PortNumber> should be substituted to the actual parameters.
5. Close and open tmg console. The port should be changed.

Note: This issue will be fixed in TMG 2010 SP1 Update 1.

Author
Masoud Hoghooghi
Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Brennan Crowe
Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Forefront TMG SP1 includes some significant improvements to the reporting functionality:

- New look-and-feel for all existing reports – cleaner aesthetics that match other Forefront products.

- User Activity Report: provides detailed information about the activity of specific users.

- Reports added for new features introduced in SP1 - User Overrides and BranchCache integration.

Here are some examples of how the existing reports look after redesign:

User Activity Reports

This kind of report allows you to see the web activity of specified users. User Activity report does not take its data from the summaries, but extracts it directly from Forefront TMG logs, so the report is always up-to-date at creation time.
This is a One-Time report which means that you can’t make a recurring User Activity report.
The users can be specified by their username (e.g. contoso\evgeny) or by IP address. Forefront TMG must require user authentication in order to be able to specify users for the report by username, otherwise all web traffic will be marked as anonymous and the report can only be generated by specifying IP addresses instead of usernames.

Here is a walk-through for generating a User Activity Report:

1. Go to ‘Logs & Reports’ à Reporting Tab and click Create User Activity Report Job

2. After typing the new report name in the wizard, a Reporting Details dialog will open.
In this dialog you should choose the period of time and list of the users you want to get a report for.

The list of users (and IP addresses) should be separated by semicolons.

3. After that you need to configure publishing location and email address to send the report to, finish the wizard and click Apply the configuration.

4. Select the just created report and click Generate Selected Report.
Please note, the generation is expected to take more time than a generation of regular one-time report, since the data is taken directly from the logs rather than from summary tables.

5. And this is the report that we get:

Reports for User Override feature

User Override for blocked URL categories is a feature introduced in SP1 which allows the user to override the policy restriction when permitted and access the blocked site.
This feature has two reports:

- The first report displays which URLs were overridden most by the users. This can indicate a need to reevaluate the policy regarding these URLs.

- The second report displays a list of ‘Top overriders’ and the URLs overridden by them.
If the authentication is not enabled by access rules, IP addresses will be shown instead of user names.

- This report can indicate a possible abuse of the policy by these users and may require further investigation of the users’ actions.

Reports for BranchCache feature

This report summarizes the overall cache utilization for both the Forefront TMG cache and BranchCache. It provides an estimation of the amount of bandwidth saved by the combination of caches.

Author: Evgeny Katz

Reviewers: Roman Golubchyck, Ori Yosefi