Symptoms
Consider the following scenario:
-
You have a server that is running Microsoft Forefront Threat Management Gateway (TMG) 2010.
-
The TMG server is configured as a web server.
-
The TMG web listener uses forms-based authentication together with NTLM delegation to the published web server.
-
There are POST requests to the TMG web server.
In this scenario, the POST requests may fail. This can cause various application issues that depend on the kind of POST requests that fail.
Cause
This issue occurs if the following conditions are true:
-
TMG forms-based authentication is being used.
-
NTLM delegation is configured in the TMG publishing rule to delegate authentication to the published web server.
-
ISA sends a request to the web server on an already authenticated connection.
-
The web server responds with a 401.
When NTLM delegation is being used, TMG authenticates a connection to the web server on the first request to the web server on that connection. The authentication is then persisted on the connection so that later requests do not have to have reauthentication.
If a request is sent to the web server on an already authenticated connection, the web server may respond with an unexpected 401 authentication request. This issue can occur when the requests are serviced by different application pools on the web server, because IIS does not persist authentication across application pools.
When forms-based authentication is being used, TMG will handle the unexpected 401 request by redirecting the user back to the originally requested resource and by adding an AuthResend tag to the URL. When the client makes the second request, TMG determines that the request needs reauthentication by the AuthResend tag and then removes the AuthResend tag before the request is sent to the web server.
However, a redirect does not include an HTTP method, and the client will make a GET request after a redirect. Therefore, the POST request and POST body are not sent to the web server.
A tool such as Strace, HTTPWatch, or Fiddler can be used on the client to determine whether TMG is sending redirects that have the AuthResend tag in response to POST requests. For example, a redirect for a request for the URL http://domain/test.asp would resemble the following: http://domain/test.asp&authResendNNN
The TMG web proxy logs do not show the AuthResend tag because the tag is removed from the URL before the URL is sent to the web server and is therefore also not logged.
This behavior may also be seen for GET requests. However, the behavior will not cause an issue, because the redirect will be resubmitted as a GET request, and this does not cause the same problem.
Resolution
There is an internal setting that can be set on a publishing rule to tell TMG to automatically reauthenticate non-GET requests. This avoids the unexpected 401 requests from the web server.
By default, in TMG Service Pack 2 this setting is enabled on web publishing rules that have forms-based authentication on the web listener and that use NTLM delegation.
To resolve this problem, install the service pack that is described in the following Microsoft Knowledge Base article:
2555840 Description of Service Pack 2 for Microsoft Forefront Threat Management Gateway 2010
Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
More Information
To work around this issue on ISA 2006 or on TMG without Service Pack 2, you can use the following script to set the internal parameter on a specified web publishing rule. By default, this is the setting that TMG Service Pack 2 enables.
To use the script, copy it into Notepad, and then save it as a .vbs file on one of the array members.
Edit the following line in the script, replacing ReplaceRuleNameHere with the name of the relevant web publishing rule:
argRuleName = "ReplaceRuleNameHere"
Then run the following script on one of the array members in an array:
argRuleName = "ReplaceRuleNameHere"
argParamName = "SendLogonOn401"
argVal = "true"
Set rule = CreateObject("FPC.Root").GetContainingArray.ArrayPolicy.PolicyRules.Item(argRuleName)
Set VendorSets = rule.VendorParametersSets
On Error Resume Next
Set VendorSet = VendorSets.Item( "{5e302ed5-f5d5-4fad-9b8a-01c72e1569f3}" )
If Err.Number <> 0 Then
Err.Clear
Set VendorSet = VendorSets.Add( "{5e302ed5-f5d5-4fad-9b8a-01c72e1569f3}" )
CheckError
WScript.Echo "No existing VendorSet."
Else
WScript.Echo "Existing VendorSet found. Values in it:"
for each name in VendorSet.allNames
WScript.Echo " ", name, "=", VendorSet.Value(name)
next
WScript.Echo "-------------------------------------"
End If
On Error GoTo 0
On Error Resume Next
valType = "Int" : Val = CInt(argVal)
If Err.Number <> 0 Then
Err.Clear
valType = "Boolean" : Val = CBool(argVal)
If Err.Number <> 0 Then
Err.Clear
valType = "String" : Val = CStr(argVal)
End If
End If
WScript.Echo "Setting", argParamName, "=", Val, "(type=" & valType & ")"
VendorSet.Value(argParamName) = Val
VendorSet.Save
Sub CheckError()
If Err.Number <> 0 Then
WScript.Echo "An error occurred: 0x" & Hex(Err.Number) & " " & Err.Description
Err.Clear
End If
End Sub
References
For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates
