The story… one of our customers called in that he had just finished with the migration to TMG and as a last step he wanted to enable

VPN Client Access. He did that, but the outcome was  unexpected. The TMG array was not reachable through the NLB address anymore.

According to the TMG console: the VPN Client Access was enabled, but on the Services tab under Monitoring the Remote Access service

and Network Load Balancing were in stopped state. Actually, Network Load Balancing was complaining about a VPN problem.

The services could not be started manually.

The first thing what I checked was the Application log:

Log Name:      Application

Source:        Microsoft Forefront TMG Firewall

Date:          25/01/2012 16:32:05

Event ID:      14104

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      XXX

Description:

Failed to start the Routing and Remote Access service. Look at the system event log for more errors.

Log Name:      Application

Source:        Microsoft Forefront TMG Firewall

Date:          25/01/2012 16:32:05

Event ID:      21199

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      XXX

Description:

The Remote Access Service configuration for VPN could not be completed. As a result, the Remote Access Service may be stopped.

Log Name:      Application

Source:        Microsoft Forefront TMG Firewall

Date:          25/01/2012 16:32:36

Event ID:      21122

Task Category: None

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      XXX

Description:

Network Load Balancing on the local computer will be stopped because the Remote Access Service is not running or not responding, although VPN is enabled.

Since the service related issues are logged in the System log, had a look at that log as well:

Log Name:      System

Source:        RemoteAccess

Date:          25/01/2012 16:32:04

Event ID:      20103

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      XXX

Description:

Unable to load C:\Windows\System32\iprtrmgr.dll.

Log Name:      System

Source:        Service Control Manager

Date:          25/01/2012 16:32:06

Event ID:      7024

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      XXX

Description:

The Routing and Remote Access service terminated with service-specific error A device attached to the system is not functioning..

Based on the logs it turned out that we have here a Remote Access service starting issue.  Searching on the

error message “A device attached to the system is not functioning” gave many hits. In most of the cases the issue started after

IPv6 had been disabled by the registry value DisabledComponents (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters).

Checking out the registry we noticed that the value was really there.

So we deleted it and rebooted the server. After this the problem was gone and everything worked fine.

Only one question remained: How to disable IPv6 in a supported way on a TMG server?

Fortunately, our Technet document about “Unsupported configurations” gives a clear answer:

Forefront TMG does not support IPv6 traffic

Issue: IPv6 traffic is not supported by Forefront TMG (except for DirectAccess).

Cause: Filtering of IPv6 traffic is not supported, and all IPv6 traffic is blocked by default.

Solution: It is recommended that you unbind IPv6 on the Forefront TMG computer network adapters. To do so, open each network adapter’s properties, and on the Networking tab, clear the checkbox for Internet Protocol Version 6 (TCP/IPv6).

Unsupported configurations

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

The most important takeaway is that the story might be different, but the Routing and Remote access service will not start if you fully disable IPv6 by the DisabledComponents registry value.

Author:

Arpad Gulyas

Microsoft CSS Forefront Security Edge Team

Technical Reviewer:

Lars Bentzen

Sr. Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Here’s a new Knowledge Base article we published today. This one talks about an issue where HTTP redirects in TMG 20101 fail if the Exchange Edge role is installed on the same box:

=====

Symptoms

If you deploy Microsoft Threat Management Gateway 2010 (TMG) and the Exchange 2010 Edge role on the same machine, you may encounter an issue where HTTP Redirect in TMG fails.

If you monitor the TMG packets when attempting to connect to http://mail.domain.com/owa, TMG will report a "Denied Connection” with the following status:

The policy rules do not allow the user request.

In the Event Log you may also see an Event ID 14148 Warning with the following text:

The Web Proxy filter failed to bind its socket to 172.x.x.x port 80. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service

Cause

When you install Exchange 2010 Edge role on a W2k8 R2 Server, the prerequisites instruct you to install features using the PowerShell commands below:

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart

This will also install WWW Publishing service and it will bind to port 80. Because the WWW Publishing service is already bound to port 80, when you install TMG it will be unable to redirect requests since it will be unable to bind to port 80.

Resolution

As a workaround, stop the WWW Publishing service, then restart the TMG firewall service. If your rules are setup correctly the HTTPS Redirect should now work.

An alternative temporary solution is to delay the start of the WWW publishing service on startup so TMG has a chance to bind to port 80 first.

More Information

Pre-requirements to Install E-Mail Protection Role on TMG : http://technet.microsoft.com/en-us/library/ee207141.aspx

Troubleshooting E-Mail Protection Feature on TMG : http://social.technet.microsoft.com/wiki/contents/articles/2702.aspx#TShootEP

=====

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

2682632 : HTTP Redirect in Threat Management Gateway 2010 fails when the Exchange 2010 Edge role is installed

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

Get the latest System Center news on Facebook and Twitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
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/

Consider the following scenario. You are running an array of more than one TMG Server 2010 and need to establish a VPN Site-to-Site connection. Therefore you will need to define a connection owner. The reason for this is that you need to define a tunnel endpoint in your array.

Normally you define the connection owner this in the wizard while creating such a Site-to-Site connection.

Furthermore you can change this setting after you have created it. For the Site-to-Site connection there is a tab called 'Server' which enables you to change this.

Generally speaking you should have this tab if you have an array of multiple servers and if NLB has been disabled.

This is also explained in the following TechNet article: http://technet.microsoft.com/en-us/library/dd441072.aspx

“If the Forefront TMG server is a member of an array, on the Connection Owner page, click the array member that will serve as the VPN tunnel endpoint in the array. If Network Load Balancing (NLB) is enabled for the array, you do not have to specify a connection owner; it will be assigned automatically.”

However, if you have enabled NLB on one interface only (e.g. the internal one), but not on the external interface, the 'Server' tab will be missing if you open the properties of a Site-to-Site connection. This can get an issue if you need to change the connection owner.

To address this issue, you can use the following script which resets the connection owner. Copy the content below to a text editor and save the file to a vbs file (e.g. connectionsowner.vbs).

Then you can run the script with the syntax
'cscript connectionsowner.vbs ConnectionName NewConnectionOwnerName'.

Running this script will create an output in the cmd.exe like the following example:

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' This script will display the currently assigned Server for a given
' VPN S2S connection and will set it to the value in the parameter
' serverName. Future versions can add this one as an addtl. argument
' to the script
' This script can be run from a command prompt by entering the
' following command:
' CScript SetAssignedServer.vbs NetworkName
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Option Explicit
'Define the constants needed
Const Error_FileNotFound = &H80070002
Const fpcPolicyRuleWebPublishing = &H02
Const fpcPolicyRuleServerPublishing = &H01
Dim networkName
Dim network
Dim serverName

Main(WScript.Arguments)
Sub Main(args)
If(args.Count <> 2) Then
Usage()
End If
networkName = args(0)
serverName = args(1)
SetValue()
End Sub

Sub SetValue()
' Create the root obect.
Dim root ' The FPCLib.FPC root object
Set root = CreateObject("FPC.Root")
'Declare the other objects needed.
Dim array ' An FPCArray object
' Get references to the array object
' and the network rules collection.
Set array = root.GetContainingArray
'Get the Networks
Dim arrayNetworks
Set arrayNetworks = array.NetworkConfiguration.Networks
On Error Resume Next
Set network = arrayNetworks.Item(networkName)
If Err.Number = Error_FileNotFound Then
WScript.Echo _
"The network specified could not be found."
WScript.Quit
End If
On Error GoTo 0
WScript.Echo "Found the network " &networkName &" it currently has the server " &network.VpnConfiguration.AssignedServer &" assigned to it"
'set the assigned server to the servername
network.VpnConfiguration.SetAssignedServer(serverName)
CheckError
WScript.Echo "Now set the connection owner server to " &network.VpnConfiguration.AssignedServer &" "
'save the changes
network.Save false, true
CheckError
End Sub

Sub CheckError()
If Err.Number <> 0 Then
WScript.Echo "An error occurred: 0x" & Hex(Err.Number) & " " & Err.Description
Err.Clear
End If
End Sub

Sub Usage()
WScript.Echo "Usage:" & VbCrLf _
& " CScript " & WScript.ScriptName & " NetworkName" & " ServerName" & VbCrLf _
& "" & VbCrLf _
& " NetworkName - Name of a VPN S2S network" & VbCrLf
WScript.Quit
End Sub

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Please note that running this script will not display the missing tab again, but you will be able to change the settings. You would need to completely disable NLB integration in TMG to see this tab again.

I hope this blog is helpful for you and I am looking forward to your comments.

Author:
Frank Hennemann
Microsoft CSS Forefront Security Edge Team

Reviewer:
Thomas Detzner
Microsoft Consulting Services

Microsoft’s own Suraj Singh has some great info over on his blog about a couple issues you may see when CRM is published through ISA or TMG.  The issue is that when Internet based users would log on to the CRM site, they had to click on links twice in order for them to open.  Also, when using a user edit form the Save and New buttons were grayed out.  You can check out Suraj’s complete article at the link below:

CRM published through ISA/TMG : Save and new button on the form does not work properly, need to click twice on the links in the CRM page : http://blogs.technet.com/b/sooraj-sec/archive/2012/01/25/crm-published-through-isa-tmg-save-and-new-button-on-the-form-does-not-work-properly-need-to-click-twice-on-the-links-in-the-crm-page.aspx

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

Get the latest System Center news on Facebook and Twitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
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/

We had a lots of customers reporting that after installing MS11-030 ( http://support.microsoft.com/kb/2509553 ), RRAS from time to time started to hang.

Typical symptom was that VPN connections were no longer possible; the RRAS service could not even be restarted. Only solution was a full reboot.

The good news is that a fix is released for the underlying issue:

Known issues that occur when you install update 2509553 for Windows Server 2003

http://support.microsoft.com/kb/2669182

With this fix, the hang should no longer occur.

Authors
Balint Toth
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Eric Detoc
Escalation Engineer
Microsoft CSS Forefront Edge Team

Today I would like to describe an easy way to solve a small visualization mismatch related to the Update Center of TMG 2010.

If you are a Forefront Threat Management Gateway administrator in a country where English regional settings are not used, it could be possible that, when entering the TMG Update Center section, you're going to find something like this:

NIS and Malware Inspection are two powerful mechanisms which allow Forefront TMG 2010 to provide full protection against potential network attacks and malicious content.

In case you're experiencing the above info reported, in particular, there are two possibilities:

1. The checking for and download of up-to-date NIS & Malware versions have really failed.

2. The reported info in the Update center is not up-to-date.

In the first case, the following article could be very useful to troubleshoot signature update failures:

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

In particular, check in the Update Center Properties form if the server is correctly configured to get the updates from the Microsoft Update servers and/or an internal WSUS server:

When you have excluded any kind of connectivity issue, you're pretty sure that the new definitions have been correctly downloaded and installed, but you can't figure out why the info reported in the Update Center section are not correct, you're probably in the kind of situation which can be solved with the hints described in this article.

The pictures below represent two examples of abstracts of the ISA_UpdateAgent.log file (in the %Windir%\Temp folder) in which the installation of NIS and anti-Malware new signatures has been performed correctly:

You can use the above log file in order to check the NIS/Malware signatures’ last installations status.

The TMG Management console reads the status of the “Last Update Status” and “Last updated” fields, for both NIS and Malware Inspection, from the information contained under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fpc\DefinitionUpdates registry key on each TMG node.

Note: this key actually contains two sub-keys: one for Malware inspection, another one for NIS.

The date and time format used here are related to the regional settings defined for the system accounts of the TMG node. This is because the TMG service, which is responsible for writing this information in the registry, runs under a local system account.

The issue described here where a “Never” status appears for “Last Update status” and “Last Updated”, might occur when the regional settings of the user account executing the MMC are different than the regional settings defined for the system accounts of the TMG node.

For instance, the problem will appear if the Format setting of the system accounts on the TMG nodes is Italian, while the Format setting of the user account executing the MMC is English (United States) – as in the example below:

To solve this, you should make sure that there is a match between the Format setting of the user executing the MMC and the Format setting of the system accounts defined on the TMG nodes. In our example above, this could be solved, for instance, by changing the Format setting of both the user account executing the TMG MMC and of the system account -Welcome screen- to English (United States).

In order to do that, follow this procedure:

Open the “Region & Language” settings panel from the server’s Control Panel and select English (United States) in the Format box:

Click APPLY and go in the "Administrative" section:

Click on "COPY SETTINGS"

In the following form, check the "Welcome screen and system accounts" check-box and click OK.

If needed, the above procedure can be implemented considering Italian language – or any other - instead of English, just be sure to apply this to both current user’s and system accounts.

Now reboot the server.

After this procedure, the format of the registry key which is read by the TMG Update Center can be well interpreted.

Coming back to the Update Center, check for new definitions and install them:

The final result should be a correct status, reported in the two columns:

In case you’re running an Array of TMG nodes, and you use the local TMG MMC on EMS machine, you’ll have to change the current user regional settings (Format) of the EMS machine so that they match the system accounts regional settings (Format) of the TMG array members.

In some cases, it's possible that the registry key values related to the NIS update status still fail to converge. This could be due to a persistent "wrong" value set in the above mentioned registry keys.

It's quite easy to manually solve this problem:

From Regedit, open the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fpc\DefinitionUpdates\{464716F5-0BAB-494a-A51A-30400DDF127F}

If the UpdateStatus value is set to "b" (in HEX format) this means an un-correct status.

You should now change this UpdateStatus value to "7" and insert in the UpdateTime word a valid value (for example the same value of the CheckTime field).

Now the info in the Update Center should be perfectly reported as "Up-to-date".

Perform a new check for updated definitions and install them, if needed.

This is for sure not a big problem, and it doesn't impact the functional level of the NIS & Malware mechanisms, but for sure it's always beautiful to see a green "Up-to-date" comment in our Update Center :-)

Hope you enjoyed it and found it useful!

Let's see you back with the next topic !!

Ciao,

Daniele Gaiulli – MS Support Engineer

Reviewer: Eric Detoc – Senior Escalation Engineer

The following Table summarizes the Forefront TMG Event IDs.

This table was put into graphs with event information of the Forefront SCOM Management Pack 7.0. We hope you find it useful.

Credits to Jan Tiedemann, Microsoft Forefront Sr. Premier Field Engineer, who prepared this table:

The concept of for HTTPS Inspection (referred to HTTPSi later) was covered in a previous blog article of Yuri Diogenes which also contains helpful formation about common issues which can occur. If you have missed it, you can find it here.

This current article is intended to explain the root cause of a specific issue and how to solve this.
The issue is: Mac OS client are not able to use a certificate which is created by Microsoft Forefront TMG 2010 for HTTPSi when using the option “Use Forefront TMG to automatically generate a certificate”.

See the following TechNet Article which provides more inform

ation on this process. http://technet.microsoft.com/en-us/library/dd441053.aspx

When analyzing this issue, we found that the issue is connected to the fact that TMG uses Unicode and not ASCII to create these certificates. If you take a look at the details of the certificate, you can see that the Subject and Issuer fields for a Certification Authority created certificate are CERT_RDN_PRINTABLE_STRING (ASCII), whilst in the certificate generated by TMG the above fields are CERT_RDN_UNICODE_STRING.

TMG is only able to create a UNICODE certificate when issuing a self-signed certificate for HTTPSi. However, Microsoft completely sticks to the RFC 3280 by using UNICODE.
http://www.ietf.org/rfc/rfc3280.txt
Here is some more information on UTF-8 which is used.
http://en.wikipedia.org/wiki/UTF-8
http://msdn.microsoft.com/en-us/library/aa377501(VS.85).aspx

You can display this certificate’s details if you use the following syntax: ‘certutil –verify –v certname.cer’
Analyzing the given output, you can see the following properties:

Issuer:

CN=Microsoft Forefront TMG HTTPS Inspection Certification Authority

[0,0]: CERT_RDN_UNICODE_STRING, Length = 128 (64/64 Characters)

2.5.4.3 Common Name (CN)="Microsoft Forefront TMG HTTPS Inspection Certi

fication Authority"

Subject:

CN=Microsoft Forefront TMG HTTPS Inspection Certification Authority

[0,0]: CERT_RDN_UNICODE_STRING, Length = 128 (64/64 Characters)

2.5.4.3 Common Name (CN)="Microsoft Forefront TMG HTTPS Inspection Certi

fication Authority"

If you compare this to a certificate issued by a Certification Authority, it looks like this:

[2,0]: CERT_RDN_PRINTABLE_STRING, Length = 13 (13/64 Characters)

2.5.4.3 Common Name (CN)="DCTMGNETZ1-CA"

…

Subject:

CN=A2-EE-DOM-1.TMGNETZ.LOCAL

[0,0]: CERT_RDN_PRINTABLE_STRING, Length = 25 (25/64 Characters)

2.5.4.3 Common Name (CN)="A2-EE-DOM-1.TMGNETZ.LOCAL"

Solution:
As described, TMG is working 100% RFC compliant in this case. However, you are able to issue a certificate from a Windows Server 2003 or Windows Server 2008 (R2) Certification Authority which can be handled by Mac clients.

The following screenshots are intended to provide assistance on how to enroll for a Subordinate CA certificate using a Windows Server CA and how to install it in TMG 2010.

Connect to the Certification Authority and open the CA MMC.
First you will need to duplicate the existing template for a Subordinate CA and edit the properties before you are going to publish that new template.

Then you must grant the permissions to enroll. Open the Security tab and click on Add. Click on Object Types to be able to choose from computer accounts, too.

In this example I am granting the enroll permission to both the DC DCTMGNETZ1 and my TMG Server A2-EE-DOM-1. If your TMG Server does have connectivity to the CA, you can enroll for this certificate using the TMG Server itself. If this is not the case, you could also create it on the CA first using this permission example.

Then please click on OK to save the template.
Now you will need to issue this certificate template before you enroll for a certificate

After you have clicked on OK, you are ready to enroll for this certificate. There are multiple ways to do this. One of them is to use the tool certreq.exe. Using certreq.exe to achieve this is pretty similar to the procedure described in the following two articles:
http://blogs.technet.com/b/pki/archive/2009/08/05/how-to-create-a-web-server-ssl-certificate-manually.aspx

http://support.microsoft.com/kb/321051

Assuming you might be inexperienced in this area, I am going to show you how to do this using GUI tools.

Assuming the TMG is a domain member and has connectivity to the CA, open a MMC on the TMG Server by clicking on Start and then type MMC. In the new MMC window click on File > Add/Remove Snap-in > Choose ‘Certificates’ from the available snap-ins > Add > Choose ‘Computer Account’ and click on Finish.

After you have expanded the list, right-click on Certificates (Local Computer)\Personal\Certificates and choose ‘Request New Certificate” as shown below.

After you have clicked through the first two screens, you will hit the list of certificate templates which you are eligible to enroll for. Navigate to the name of the created template and click on “Click here to configure settings”. This is necessary to enter required information manually, like the Common Name for example.

If you want to be able to archive the private key afterwards, therefore you will need to switch to the ‘Private Key’ tab and check this option.

After you have finished this wizard, you should receive a confirmation that the certificate has been enrolled.

Back in the MMC, right click on the new certificate and choose All Tasks > Export

In the new wizard, choose ‘Yes, export the private key’ and click on next > optionally choose one of the options and click on Next > type a password > Next > Choose a path and filename (e.g. c:\certificate.pfx) for the exported certificate.

Now we are ready to import this certificate into TMG for HTTPSi. Therefore open the Forefront TMG MMC, navigate to Web Access Policy in the left pane > click on ‘Configure HTTPS Inspection’ in the tasks pane which will take you to the following screen. Choose ‘Import a certificate’.

Browse to the pfx file you exported before and enter the password you chose. This is it. After you have applied the configuration in TMG, you are ready. You can verify the installed certificate to double-check everything by clicking on ‘HTTPS Inspection Trusted Root CA Certificate Options’ and ‘View Certificate Details…’.

The next screen is intended to illustrate that the created custom template was used to issue to the certificate to the TMG Server.

Assuming that the CA is already being trusted by your clients, you don’t need to add anything for your clients. Otherwise you would need to install/deploy the CA Server’s certificate into the Trusted Root CA’s store of your HTTPSi clients. Coming back to the MAC clients, the following article might be helpful to you.
How to install a trusted root CA certificate and an intermediate CA certificate on a computer that is running Microsoft Entourage 2004 for Mac on a Mac OS X 10.3 or a Mac OS X 10.2 operating system
http://support.microsoft.com/kb/887413

I hope this article explains the background information for this issue and how to work around them for if you need to use Mac clients. I am looking forward to your comments.

Author:
Frank Hennemann
Microsoft CSS Forefront Security Edge Team

Reviewer:
Philipp Sand
Microsoft CSS Forefront Security Edge Team

Introduction:

Recently, I worked on a case where we were publishing Exchange CAS (Client Access Servers) servers on TMG. We were seeing some unexpected behavior while using KCD (Kerberos Constrained Delegation) as the Authentication Delegation Method and using a Web Farm in the Publishing Rule.

The Scenario was like this.

We were publishing the target CAS servers as a Web Farm and using KCD as the Delegation method. Therefore, the SPN specified on Authentication Delegation was “http/*”.

But when we were using TEST RULE Button to Test this, we were getting the Following Error:

Category: KCD error

Error details: There is no suitable Service Principal Name (SPN) entry found for this Forefront TMG computer in Active Directory.
Action: Kerberos Constrained Delegation requires the Forefront TMG computer to be trusted for delegation for any authentication protocol and the Service Principal Name (SPN) used by Forefront TMG must be added to Active Directory

However, when we tried to Access Exchange Services like OWA, Active Sync etc. externally, everything worked just fine.

So, that made us believe that there is something wrong with the TEST RULE Button here in this case.

Further Troubleshooting:

Then we tried to put the SPN with the name of one of the CAS servers in the Authentication Delegation Tab. And now when we ran the TEST RULE again it was Successful.

While researching the issue further, we discovered that this behavior is a known issue that is currently under investigation.

CONCLUSION:

If you are publishing a Web Farm using KCD as the Delegation method, and find that using the “Test Rule” button gives the above error, try testing connectivity/authentication from an external client.
As the “Test Rule” button may not be a reliable test with this publishing scenario, you should test using an external client.

Author

Nitin Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Richard Barker

Sr. Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

We recently received a case from a customer reporting that the TMG log data were not being properly stored in a remote SQL database but was accumulated in the Large Logging Queue (LLQ).

The LLQ is an improvement added in TMG, particularly useful in scenarios where logging to a remote SQL Server is involved.
This feature allow the logging to continue even if the database is unavailable: log data is stored in a local folder and will be replayed to the database once it becomes available again.
You can read more of this feature here: http://technet.microsoft.com/en-us/library/dd183731.aspx

In the case of our customer the database was available but TMG was logging to LLQ for some reason.
The alert we were getting on the console was:

Forefront TMG failed to connect to SQL Server for Forefront TMG Web filter logging. This failure may be due to a temporary condition, low resources, or inadequate permissions. SQL Server error description: Invalid or unknown table specified.

Connecting to SQL Server will be retried periodically. Until a connection is established, log records will be saved in a log queue on the disk on the local computer. Forefront TMG will continue to operate normally, but the log records in the log queue will not be available in the Forefront TMG log viewer. After a connection to SQL Server is established, the log records in the log queue will be moved to SQL Server and will be available in the log viewer.

The failure is due to error: Invalid or unknown table specified.

The status of the LLQ was particularly concerning, with several GB of data waiting to be committed to the database:

The error suggested Invalid or unknown table so we first checked the configured tables and their structure.
From the TMG console in Logs and reporting we have the current configuration:

Checking in SQL Server we have the tables with the expected names:

Next we checked the table structures.
The table definition files (fwsrv.sql and w3proxy.sql) are in the TMG installation directory which normally can be found in “C:\Program Files\Microsoft Forefront Threat Management Gateway”.

The structure of the current table in the database can also be exported to a text file from the SQL Server Management Studio interface:

Comparing the reference and the current table we found that the customer had added another column in the WebProxyLog table.
The extra column was supposed to cause no harm but in the internal tracing we found that TMG detects a different structure, not matching with any of the supported schemas, and therefore refuses to log into that table.

After removing the extra column the data from the LLQ were properly written to the database and everything resumed working correctly.

Author:
Gianni Bragante
Support Engineer - Microsoft CSS Forefront Security Edge Team

Reviewer:
Lars Bentzen
Escalation Engineer - Microsoft CSS Forefront Security Edge Team

Introduction:

When configuring TMG Reports to run at a Scheduled time, you can also configure it to send an email once the Report is generated. This can be useful for administrators to know that the reports have run and to let other people know that the reports are available. In this case the Reports were being generated but the emails were not being sent for some reason.

Scenario:

The TMG server was configured to generate Daily Reports at a scheduled time and to use the ISP’s SMTP server. When it failed we could see the following error on the Alerts tab:

Description: The report "DailyActivityReport" could not be generated. Report Server error information: The e-mail signaling that the report DailyActivityReport was generated could not be sent. Error information:

The error occurred on object 'Reports' of class 'Reports Configuration' in the scope of array 'TMG2010'.

This TMG alert tells us that the email could not be sent, let us determine why this failed.

Troubleshooting:

We collected a TMG Data Packager package and looking at the TMG Firewall logs and filtering on port 25 we could see that there was an issue with SMTP server connectivity. Here we found a Log Record that DENIED access to the SMTP server:

So we can see the SMTP traffic to this address is getting DENIED by the [Enterprise] Default rule. And if you see the text above its showing the SMTP server destination IP address is in the External Network (In an ideal scenario, SMTP server will be in the Internal Network).

We verified the name resolution from the TMG server for smtp.contoso.com. We did this by reviewing the TMG internal network trace and filtering the trace for DNS lookups to this record.

Filter:

(dns) && (dns.qry.name == "smtp.contoso.com")

Here we could see the response and as you can see the FQDN resolves to the IP Address that is DENIED in the above TMG Logs.

smtp.contoso.com: type A, class IN, addr 2.2.2.2

So it’s pretty clear that they don’t allow this traffic by the System Policy for SMTP from TMG server. By default we allow SMTP traffic from Localhost to Internal. And in this case the SMTP server was in the External Network of TMG.

We then checked the TMG configuration using ISAInfo and we could see the System Policy for SMTP was not modified.

So, to make this work we had to modify this System Policy rule and add a computer set with the SMTP server in it.

We then added the SMTP server's Computer Set in the System Policy Rule and that solved the issue.

Conclusion:

If you are doing something different to the default scenarios, then please make sure that you configure the TMG server accordingly so it matches the new requirements. Otherwise things may not work as expected as described in the above case.

Author:

Nitin Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Lars Bentzen

Security Sr. Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Billy Price

Security Sr. Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

From time to time we come across the question why are the values of the Blocked URL requests at URL Filtering increasing on the dashboard, although the URL Filtering feature is disabled.

In this post I would like to explain, what exactly we can see there.

The first value represents the number of the denied web requests in the last 24 hour.  This value equals the value of the Sites denied in last day (Forefront TMG Web Proxy) performance counter on a standalone TMG server. If you have an array the value shows the sum of the value of the Sites denied in last day (Forefront TMG Web Proxy) performance counters on the array members.

The second value represents the number of incoming web requests in the last 24 hour.  This value equals the value of the Total number of request in last day (Forefront TMG Web Proxy) performance counter on a standalone TMG server. If you have an array the value shows the sum of the value of the Total number of request in last day (Forefront TMG Web Proxy) performance counters on the array members.

The third value shows the rate of the values above as percentage.

The Total number of request in last day (Forefront TMG Web Proxy) counter will be incremented if a HTTP request hits the Web Proxy component.

Let’s have a closer look on what increases the Sites denied in last day (Forefront TMG Web Proxy) performance counter?

Well, there are different reasons behind this:

- Client authentication fails

- A rule does not allow accessing the web site

- User override scenario (http://technet.microsoft.com/en-us/library/ff685648.aspx)

- Error occurred on checking the URL categorization of the destination website

- At renegotiation of an SSL session, SSL certificate problem

- … etc.

As you can see the Sites denied in last day (Forefront TMG Web Proxy) counter covers more scenarios than just URL filtering.

Author:

Arpad Gulyas
Sr Support Enginner
Microsoft CSS Forefront Security Edge Team

Technical Reviewer:

Lars Bentzen
Sr. Escalation Engineer
Microsoft CSS Forefront Security Edge Team

When we are publishing OWA, or every web service through TMG and we are willing to make use of FBA we have the chance to change our password through the FBA web form. However this step is not always as straightforward as it seems and there are some possible pitfalls in the configuration on the TMG or on the DC.

One error you might see in a case of an issue in the configuration is the following generic error:

In this article we want to provide some guidance how to troubleshoot these problems and also how to identify specific issues that can prevent the FBA changing password from working as it should.

Of course the first point when you see the error message is to check if the “complexity requirements” are really met and if the user who sees the error is the only one affected by this issue.

Hence if we can meet the complexity requirements we should check the following steps:
http://technet.microsoft.com/en-us/library/cc984426.aspx

(Note that both Active Directory and an LDAP server use the LDAP protocol for communication)

· The connection to the LDAP server or Active Directory on the domain controller must be over secure LDAP (LDAPS). To use a secure LDAP connection, a server certificate must be installed on the domain controller. The common name on the certificate must match the fully qualified domain name (FQDN) that you specify for the authentication server.

· The Forefront TMG computer must have the root certificate of the certification authority (CA) that issues the server certificate in the Trusted Root Certification Authorities store for the local computer.

· When using LDAP authentication, you must create an LDAP server set containing the LDAP servers that will be used to authenticate users. Configure the following settings for the LDAP server set:

o Enable connecting to the LDAP server over a secure connection.

o Specify an FQDN for the LDAP server name. Ensure that the FQDN matches the common name specified on the server certificate installed on the LDAP server (domain controller).

o Disable querying of the global catalog (GC).

o Specify the domain in which user accounts can be identified and specify the details of an account that will be used to bind to the LDAP server and to query the credentials of logged-on users.

o An account is required to bind to the authentication server and verify user name and password status. In the case of domain authentication, this must be a domain account with privileges to make changes to Active Directory.

And we must check also if the http://support.microsoft.com/kb/957859 patch has been already installed (included in TMG RTM), and if you might need to run the script provided in this article.

The “Configuring and Troubleshooting the Password Change Feature in ISA 2006” is also a very good place to continue troubleshooting.

If the above steps are fine we should move forward in our analysis and as first thing check if the “root certificate” we are using to establish the LDAPS connection is trusted everywhere (TMGs and DCs).

If this is the case but still we are not able to make it working we have to move forward in our analysis and check for any possible error in the ISA/TMG tracing. Due to the very detailed information which can be found in the tracing, this can only be analyzed by Microsoft personnel.

Recently I was working on a case, where above steps didn’t resolve the issue. In this article I want to share how we resolved the issue, which was caused by a permission error on AD in my case.

When analyzing the TMG tracing we found that TMG tried to gather the account properties and failed:

… Info:CUserAccountTask:  User: domain\user, Operation: 1, Error code: 6, Internal (ADSI) error: HRESULT=8000500D

Where the error 8000500D is translated as:

# for hex 0x8000500d / decimal -2147463155
E_ADS_PROPERTY_NOT_FOUND

You can also use the TMG Diagnostic logging to verify if you are facing this issue. More information on how to use diagnostic logging can be found here. 

When you filter for the specific connection, you should be able to see the error code 2147463155 in the logging. You can of course also just filter for the error code itself, after collecting the diagnostic logging:

Under this case it is a good idea having a look at the user permissions, of the account where you cannot change the password. It is necessary to add the permission to read the attribute UserAccountTask to every account which should be able to change the password via ISA/TMG.

This attribute is used to gather information regarding the password as for example if it is expired or if it matches the complexity requirements.

This task can be accomplished simply adding the “authenticated users” group to the security tab if it is missing under AD as per following screenshot with the following attributes enabled as per our default Windows Server 2008 R2 installation:

Read, Read account restrictions, Read exchange information, Read exchange personal information, Read general information, Read Group membership, Read logon information, Read personal information, Read phone and mail options, Read private information, Read public information, Read remote access information, Read RTCPropertySet, Read RTCUserProvisioningPropertySet, Read RTCUserSearchPropertySet, Read Terminal Server license Server, Read web information, Special permissions.

Of course we can perform the same action directly on the “users and computers” console (it is the same).

The above guidelines should help in troubleshooting some of the most common issues under FBA when we are willing to implement the changing password feature.
See you next time!

Author
Andrea Vescovo
Support Engineer
Microsoft CSS Forefront Edge Team

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

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

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

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

The Build Number is: 7.0.9193.540

Thank you

Introduction:

It is a very common scenario where we use LDAP authentication for publishing web sites on ISA. We have seen some issues with LDAPS authentication when there are some Certificates on the ISA server which have both Client and Server Authentication Enabled in the “Enhanced Key Usage” section under “Details” Tab.

Scenario:

We had a web site published on ISA 2006 server. We were using LDAPS authentication for that Web Site on ISA in the listener.

We had different LDAP server sets configured on the web listener for different domains.

LDAPS authentication was working fine for all domains except for one child domain.

Troubleshooting:

We took ISA Data Packager and here is what we saw there:

Description: The LDAP server DC.domain.com did not respond. If the server is physically reachable and a secure (SSL) connection is required, this event may be caused by failure of the SSL handshake. This event may also occur when the credentials used to connect to the LDAP server to verify the status and change the password of an account are rejected by the server.

It was strange because we were able to connect to the DCs from ISA over port 636 using LDP.exe and we were also BIND to the DC as well.

We checked the network captures for the same communication and found the following:

A Server certificate being sent by the DC in SERVER HELLO…

Subject: US,WA,CONTOSO Inc.,DC.CONTOSO.com

But then we also saw the following Web Server certificate going back in reply from the ISA servers:

Subject: OWA.CONTOSO.com,Messaging,CONTOSO Inc.,WA,US

As mentioned in the Introduction section, we have seen some issues on Windows when the SSL Web Server certificates have both 'CLIENT' and 'SERVER' Authentication enabled. In the above situation, the certificate was ‘sent’ by the ISA server because it had Client Authentication enabled. However, this certificate was invalid for Client Authentication to the child domain in question. So, we went to all the Web Server certificates on all the ISA servers and disabled 'CLIENT' authentication on them. Then we restarted the ISA Firewall service on all the ISA servers.

NOTE:  The “Client Authentication” usage is typically not required on the SSL certificates used by ISA 2006 Web Listeners.  Please make sure you only disable “Client Authentication” on installed certificates that do not require the “Client Authentication” usage.  For example, do not disable the “Client Authentication” usage on the ISA server’s Computer Certificates.

For more information on this behavior and how to configure and install certificates for LDAPS authentication, please refer to the articles below:

http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

http://support.microsoft.com/kb/938703

With the above changes, we were now able to perform LDAPS authentication to the child domain in question.

Conclusion:

If you experience similar issues (i.e. authentication failing or slow authentication) while using LDAP server sets for authentication, check the Web Server certificates used by the ISA Web Listeners and make sure they only have “Server Authentication” enabled under the “Enhanced Key Usage” Section in the “Details” tab of the Certificate.

Author:

Nitin Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Richard Barker

Sr. Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Hello All! It’s Brett Crane from the Forefront Edge team here at Microsoft. I’ve noticed there have been a few questions regarding documentation on the best way to go from an Evaluation Version of TMG to the RTM version. I thought I would take a few moments to cover some scenarios in upgrading between the two products in the case they may be in a production environment.

* Please keep in mind that I am not suggesting that we recommend putting an Evaluation version of the TMG product into production environments. It is actually the exact opposite. It is meant for testing purposes only.

So all that said let’s assume that there is a configuration of TMG that is an Evaluation version that you would like to keep up and running. “What! Keep up and running! “ Yes… the Evaluation versions are time bombed. You will see issues in running the firewall service once you have passed your Evaluation time period. So, let’s talk about how you can minimize downtime and get these servers back up in a supportable RTM configuration.

What needs to be done? Well, first you need to ask yourself:

“What type of configuration am I in? Is it a Stand-alone server? Is it a Stand-alone Array with 2 or more Firewall nodes? Or is it an Enterprise Array with 2 or more Firewall nodes?”

Based on your answer just choose one of the following quick and easy steps:

Stand-alone Server:

This process is simple enough, and there’s no question about it…you have to reinstall the product. You can’t just go out and purchase the product codes and put them in. So, you should expect that an install is going to be needed. Here are the steps for a single server:

1. Export your server configuration (Make sure to include the confidential information as well as the user permission settings).

2. Uninstall the TMG product from the server by going into Programs and Features, highlighting Microsoft Forefront Threat Management Gateway, and choosing Uninstall.

3. Install Threat Management Gateway utilizing the RTM bits you have purchased.

4. Import your configuration you saved from step 1 above.

* Please keep in mind that you haven’t changed anything on the server itself. You haven’t removed any NICs, changed IP addresses, uninstalled certificates, etc. You have just uninstalled the TMG product and reinstalled it.

Stand-alone Array with 2 or more Firewall nodes:

Seeing that this is an actual Array configuration (even though not an enterprise array utilizing a separate EMS), you’ll notice a big difference in steps below versus the steps above. What’s nice is the steps I provide should keep you up and running as long as you are using NLB for load balancing purposes. For this example I will be using 2 nodes in an array.

1. Start by exporting a full configuration of your Array for backup purposes in case any problems occur.

2. Determine which Node is your Array Manager. This is important because you will need to begin all the work on the Firewall Node that is NOT the Array Manager. To determine which of the two servers is your Array Manager just open your TMG MMC, highlight system on the left, then scroll over to the far right on your Servers tab located in the middle of your MMC. You’ll see one server says “Array Manager” and the other says “Array Managed”.

3. Notate the version numbers that your servers are at.

* This is very important because you will need to make sure you install the proper updates to bring them back up to match. If you don’t have them at the same patch level you will see issues when you try to join back to the Array.

4. From the Managed server, highlight the Array name on the left side of the MMC and choose “Disjoin Server From Array” on the right.

5. Once the server is fully disjoined from the Array go ahead and uninstall the TMG product from the server by going into Programs and Features, highlighting Microsoft Forefront Threat Management Gateway, and choosing Uninstall.

6. Install Threat Management Gateway utilizing the RTM bits you have purchased. Once the product has been reinstalled make sure to install all the needed updates to bring it to the same version as the current Array Manager.

7. Once the server is back up highlight “Forefront TMG (Server_ name) on left side of the MMC and choose “Join Array” from the far right. Point to the Array Managers name.

8. Once you have fully joined back to the Array you will notice that all your rules have been pulled back over to your new RTM server and everything should begin working again.

9. On the new RTM server highlight the Array on the left. In the Tasks tab on the far right choose “Set as Array Manager”. This will make this new server take control of the Array Manager process from the Evaluation server that is still running.

10. Go over to the remaining Evaluation server and highlight the Array on the left side of the MMC and then choose “Disjoin Server From Array” on the right.

11. Once the server is fully disjoined from the Array go ahead and uninstall the TMG product from the server by going into Programs and Features, highlighting Microsoft Forefront Threat Management Gateway, and choosing Uninstall.

12. Install Threat Management Gateway utilizing the RTM bits you have purchased. Once the product has been reinstalled make sure to install all the needed updates to bring it to the same version as the current Array Manager.

13. Once the server is back up highlight “Forefront TMG (Server_ name) on left side of the MMC and choose “Join Array” from the far right. Point to the new Array Managers name. This will cause the server to join the Array and pull down all the needed configurations.

Enterprise Array with 2 or more Firewall nodes:

Believe it or not this is actually the easiest of the three different configurations. The thing is… you don’t have to worry about updating your EMS (Enterprise Management Server) to RTM, just your firewall nodes.

1. Start by exporting a full configuration of your Array for backup purposes in case any problems occur.

2. Notate the version numbers that your servers are at.

* This is very important because you will need to make sure you install the proper updates to bring them back up to match. If you don’t have them at the same patch level you will see issues when you try to join back to the Array.

3. Choose the firewall node that you want to start your update to RTM on. There is not a specific node that should go first.

4. From the server you chose in step 3… highlight the Array on the left side of the MMC and then choose “Disjoin Server From Array” from the far right.

5. Once the server is fully disjoined from the Array go ahead and uninstall the TMG product from the server by going into Programs and Features, highlighting Microsoft Forefront Threat Management Gateway, and choosing Uninstall.

6. Install Threat Management Gateway utilizing the RTM bits you have purchased. Once the product has been reinstalled make sure to install all the needed updates to bring it to the same version as the current Array Manager.

7. Once the server is back up highlight “Forefront TMG (Server_ name) on left side of the MMC and choose “Join Array” from the far right. You will be joining an EMS managed Array so you will need to point to the name of your existing EMS. This will cause the server to join the Array and pull down all the needed configurations.

8. Once this server is back up and functioning as expected go to the second Firewall node that is still utilizing Evaluation bits and go through steps 4, 5, 6, and 7 just above.

So… at this point you should be up and running with RTM bits! I hope the information I provided above helps out! Keep in mind, ALWAYS GET BACKUPS PRIOR TO ANY WORK! By backups I am referring to So… at this point you should be up and running with RTM bits! I hope the information I provided above helps out! Keep in mind, ALWAYS GET BACKUPS PRIOR TO ANY WORK! By backups I am referring to System State and TMG configuration backups (or exports). If you run into any issues going from Eval to RTM know that there are support processes that can help. In any case, you may still want to make sure this is all done in a maintenance window. No need to cause an outage if something goes wrong!

Author

Brett Crane - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

Reviewer

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

This post is about an issue I came across while working on a case and thought of sharing with all. It was not a straight forward issue; well a lot of them are not! J , Issue was with a certain website hosted on an external web server, when users in the internal network of TMG server try to access this website through TMG server, they get authentication prompt and after entering the user credentials, user gets page could not be displayed on the browser.

In this scenario the access rule on TMG, required users to authenticate. Customer had another network which was behind ISA server 2004 sp3 and same website for the user was working without issues.

Troubleshooting

After verifying that, all the basic settings were correct on the TMG server. I collected Network monitor on the client and TMG data packager as explained in this link simultaneously, http://blogs.technet.com/b/sooraj-sec/archive/2010/04/10/instructions-for-isa-data-packager-to-collect-data-in-repro-mode.aspx, for working and non-working scenario.

Data Analysis.

In the Network monitor traces taken on the client I saw a weird behavior, shown and discuss below. If we look at following snapshot, we can see few Get Requests/Responses marked. It is a get request for same URL.

If we look into the details of the network traces, After the TCP handshake we see first get request. In response to that we see proxy authentication required message back from the TMG server.

Details of the Proxy authentication message from the TMG server, which is status code 407, proxy authentication required.

Then client responds with credentials using Kerberos token shown below

Then we get reply from the TMG server with http status code 401, authentication required.

This response was actually coming from web server(we confirmed by looking at network traces taken on the external NIC of the TMG server) and TMG server was forwarding to client, that’s how user was getting authentication prompt on his browser. But in network traces we can see this was happening again and again i.e. first TMG sends 407 proxy authentication required and then forwards 401 status code and finally connection gets reset by client. In above 401 messages we can also see that web server who is hosting the web site is using NTLM authentication.

Research and Resolution

Found following explanation

*************************

AuthPersistence Usage in IIS 6.0

In earlier versions of IIS, the AuthPersistence metabase property had three possible settings. Two of the settings allowed administrators to enhance performance by specifying persistence based on the existence of a proxy server. Administrators could use either of those AuthPersistence settings to force IIS to negotiate one-time-per-client connections and then use those credentials for subsequent requests over the same connections. These two settings have been removed from IIS 6.0 for security reasons.

In IIS 6.0, the only valid setting for the AuthPersistence metabase property is AuthPersistSingleRequest, and NTLM is the only IIS 6.0 authentication protocol that honors this setting. The setting for AuthPersistSingleRequest is honored only in the following circumstances:

In either of these cases, AuthPersistSingleRequest is False — that is, not set — for backward compatibility with earlier versions of IIS. A value of False means that authentication persists for subsequent requests over the same connection.

In IIS 6.0, all other authentication protocols assume that the value of AuthPersistSingleRequest is True — that is, set — so authentication persists only for a single request over a connection. IIS 6.0 automatically resets authentication at the end of a request and forces each subsequent request over the same connection to authenticate.

From http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8feeaa51-c634-4de3-bfdc-e922d195a45e.mspx?mfr=true

****************************

As per above explanation AuthPersistSingleRequest should be False

( http://msdn.microsoft.com/en-us/library/dd447565.aspx ) in our scenario on TMG server and we can proxy NTLM authentication.

Then checked this property in ISAinfo, we found that customer had set its value to Boolean 1 as shown below on TMG server’s internal network.

This is a com property and we cannot set its value through GUI, We found that customer had imported an xml file to import configuration from another server and this setting was set to 1 in that xml, after changing its value to default 0 in that xml file and importing it again, issue got resolved and we were able to access the website through the TMG server.

As I mentioned in this scenario, customer modified this property unknowingly while importing and we were able to revert that. This property cannot be modified through GUI, so if you encounter similar issue and find this property changed to 1 then change tracking tool can be used to see what changes happened (any imports as discussed here) else engaging MS support would be the right thing to do to get it back to default.

Note: ISAInfo is one of the logs you can collect while collecting TMG data packager data, more about it and TMG data packager can be found in this link http://www.isaserver.org/tutorials/Advanced-Forefront-TMG-debugging.html, in short this log has ISA/TMG configuration information.

Author

Suraj Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team.

Technical Reviewers:

Richard Barker

Sr. Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Introduction:

I have seen people looking out in Public Forums on how to implement the functionality described in KB article http://support.microsoft.com/kb/2619987 (Update adds feature to lock out user accounts that use FBA with Active Directory or with LDAP authentication in a Forefront Threat Management Gateway 2010 environment).

The above KB article above just talks about the feature. This blog will help you in enabling this feature on Forefront TMG server. As mentioned in the article this feature gets enabled by installing SP2.

This feature would add a local account lockout feature which would help prevent a malicious user from locking out domain accounts.

Scenario:

I have an OWA published on TMG 2010 where the listener’s name is “OWA”. Active Directory Account Lockout Threshold value is 5.

What we want to achieve is when user enters a bad password 3 times, TMG 2010 would stop authenticating that user for 200 seconds.

Implementation:

Now let’s see how we would implement it.

Prerequisite: Install TMG SP2 to be able to utilize this feature.

There are two ways of implementing it:

1) One by editing WebListenerProperties object from adsiedit.msc.

2) Other by automating the process through a VBSCRIPT.

OPTION 1) Implementation through ADSIEDIT.MSC

1) Select the ‘Run’ command from the Start menu and type in ADSIEDIT.MSC

2) Click Action->Connect to

3) Browse to CN=fpc2->CN=Array_Root->CN=Arrays->Cn=RuleElements->CN=WebListener

4) Now under CN=Weblistener, you should find one or more GUIDs.  Each one represents a Web Listener configured in TMG 2010.

5) Next part is little tricky as we need to find out the listener’s name for which we are going to apply the account lockout feature.

6) To do that, right click a GUID and click properties. Now scroll down to find the attribute msFPCName which tells us the name of the Weblistener.

7) Now just match the listener’s name to the listener to which we need to make the changes.

8) Expand the particular GUID which represents our listener. We would see CN=WeblistenerProperties.

9) Right click CN=WeblistenerProperties and click properties.

10) Now, make changes to AccountLockoutResetTime

Make changes to EnableAccountLockout

Make changes to AccountLockoutThreshold

If the EnableAccountLockout property is set to True and the value for the AccountLockoutThreshold property for consecutive failed logon attempts for a user is exceeded, the account is locked based on the AccountLockoutResetTime value in seconds.
Note "Consecutive failed logon attempts" means that the time period between two failed logon attempts is no more than the AccountLockoutResetTime value in seconds, and there were no successful logons in between attempts.
Please also note that:

• The lockout counter for FBA described above is local to each TMG computer, and
• If configured for greater values than the Active Directory account lockout thresholds, AD account lockout will trigger before the FBA local lockout, which is likely to defeat the purpose of having this protection in place.

More reference http://support.microsoft.com/kb/2619987

OPTION 2) Implementation through a VBSCRIPT.

For implementation through a VBScript we can refer to a wonderful article by Christian Groebner…who is also an MVP.

Please NOTE: The article is in German Language.

http://www.msisafaq.de/Anleitungen/TMG/Konfiguration/ALP.htm

Author:

Kaustubh Dwivedi

Security Support Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Nitin Singh

Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Richard Barker

Security Sr. Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Recently I came across a situation where one of our customers using Forefront TMG could not add a static route in RRAS based on a newly added network adapter.

In this post, I will describe the steps required to get the adapter available in RRAS.

Symptom

After adding a new network adapter (called LAN2 in this blog) to a server with Forefront TMG 2010 installed, the new adapter is listed in “Control Panel\Network and Internet\Network Connections” but it does not appear in “Network Interfaces” of the Routing and Remote Access (RRAS) console.

Therefore, it is not possible to add a new static route using the new interface (LAN2) as it is not available in the Interface list box (Figure 1).

Figure 1

Any other setting using the new added interface will not be possible in the RRAS.

How to get the new network adapter to show up?

Here is an example (Windows 2008 R2 / TMG 2010 SP2)

1. Before adding the extra network adapter, we have 2 NICs (LAN and WAN) (Figure 2)

Figure 2

2. Right after adding the new LAN2 adapter and restarting the TMG server, LAN2 is showing up in the “Network Connections” (Figure 3) but not in the RRAS Network Interfaces (Figure 4).

Figure 3

Figure 4

Note that you can see the 3 NICS in the TMG console (Networking\Network adapters).

To make the new network adapter LAN2 available in RRAS, follow the steps below.

3. Disable Routing and Remote Access (Figure 5)

Figure 5

4. Configure and Enable the Routing and Remote Access (Figure 6)

Figure 6

5. Then choose “Custom configuration” and “LAN routing” (Figure 7)

Note: What you choose is actually not really important as it is going to be overwritten by TMG later on.

Figure 7

Figure 8

6. If prompted agree to Start the service

Figure 9

7. The new network interface LAN2 is now available in the RRAS (Figure 10)

Therefore, adding a static route using LAN2 is possible.

Figure 10

8. The Routing and Remote Access is back online but the RRAS configuration was reset. Therefore we have to reapply the stored TMG RRAS settings.

As you may know, Forefront TMG takes over the Routing and Remote Access settings with its own configuration. (To know more about this behavior: http://technet.microsoft.com/en-us/library/ee796231.aspx#hbsdfghserrty5)

The trick here is to modify any setting in TMG configuration and then apply the change. For instance, you can just add a description to an Access rule.

Forefront TMG will overwrite the Routing and Remote Access settings with its own “good” configuration.

Now we have the “good” RRAS configuration and the possibility to use the new added interface in RRAS.

Author

Olivier Bertin

Support Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewers

The “Escalation Engineers team”

Microsoft CSS Forefront Security Edge Team

As of early AM June 28th 2012, there have been many reports of TMG services stopping unexpectedly. We are primarily seeing the issues in an SSL Publishing scenario. You may expect to see the following in the Application Event Logs coinciding with the service stopping:

Source: Service Control Manager
Event ID: 7034
Level: Error
Description:
The Microsoft Forefront TMG Firewall service terminated unexpectedly. It has done this <times>.

And\Or

Source: Microsoft Forefront TMG Firewall
Event ID: 14057
Description:
The Firewall service stopped because an application filter module C:\Program Files\Microsoft Forefront Threat Management Gateway\w3filter.dll generated an exception code C0000005 in address <hex_address> when function CompleteAsyncIO was called. To resolve this error, remove recently installed application filters and restart the service.

It has been determined that applying TMG SP2 Rollup2 will resolve the issue. To install Rollup 2 please refer to the following link:

Rollup 2 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 2
http://support.microsoft.com/kb/2689195

More information will be provided as it comes available. Thank you for your patience in this matter.