Síntomas
Imagine el siguiente escenario:
-
Dispone de un servidor que está ejecutando Microsoft Forefront Threat Management Gateway (TMG) 2010.
-
El servidor TMG está configurado como un servidor web.
-
La escucha de web TMG utiliza autenticación basada en formularios junto con la delegación de NTLM en el servidor web publicado.
-
Hay solicitudes POST al servidor web TMG.
En este escenario, pueden fallar las solicitudes POST. Esto puede causar diversos problemas de aplicación que dependen del tipo de las solicitudes POST que fallan.
Causa
Este problema se produce si se cumplen las condiciones siguientes:
-
Se utiliza la autenticación basada en formularios TMG.
-
Delegación de NTLM está configurada en la regla de publicación de TMG de delegar la autenticación al servidor web publicado.
-
ISA envía una solicitud al servidor web en una conexión ya autenticada.
-
El servidor web responde con un 401.
Cuando se utiliza la delegación de NTLM, TMG autentica una conexión con el servidor web en la primera solicitud al servidor web en esa conexión. La autenticación se conserva en la conexión para que las solicitudes posteriores no tiene que tener la reautenticación.
Si se envía una solicitud al servidor web en una conexión ya autenticada, el servidor web puede responder con una solicitud de 401 autenticación inesperado. Este problema puede ocurrir cuando las solicitudes son atendidas por grupos de aplicaciones diferentes en el servidor web, dado que IIS no conserva la autenticación a través de grupos de aplicaciones.
Cuando se utiliza la autenticación basada en formularios, TMG controlará la solicitud 401 inesperado al redirigir al usuario al recurso solicitado originalmente y agregando una etiqueta AuthResend a la dirección URL. Cuando el cliente realiza la segunda solicitud, TMG determina que la solicitud necesita una nueva autenticación mediante la etiqueta AuthResend y, a continuación, quita la etiqueta de AuthResend antes de enviar la solicitud al servidor web.
Sin embargo, una redirección no incluye un método HTTP y el cliente realizará una solicitud GET después de una redirección. Por lo tanto, la solicitud POST y cuerpo POST no se envían al servidor web.
Una herramienta como Strace, HTTPWatch o Fiddler puede utilizarse en el cliente para determinar si TMG está enviando redirecciones que tienen la etiqueta AuthResend en respuesta a las solicitudes POST. Por ejemplo, una redirección de una solicitud de la dirección URL de http://domain/test.asp sería similar a lo siguiente: http://domain/test.asp&authResendNNN
Los registros de proxy web TMG no muestra la etiqueta AuthResend porque se quita la etiqueta de la dirección URL antes de que la dirección URL se envía al servidor web y, por tanto, también no se registra.
Este comportamiento también puede aparecer para las solicitudes GET. Sin embargo, el comportamiento no provocará un problema, ya que la redirección se volverán a enviar como una solicitud GET, y esto no produce el mismo problema.
Solución
Hay una configuración interna que puede establecerse en una regla de publicación para indicar a TMG a autenticar automáticamente las solicitudes GET no. Esto evita las 401 solicitudes inesperadas desde el servidor web.
De forma predeterminada, TMG Service Pack 2 de esta configuración está habilitada en reglas que tienen la autenticación basada en formularios en la escucha de web y que utilizar la delegación de NTLM de publicación de web.
Para resolver este problema, instale el service pack que se describe en el siguiente artículo de Microsoft Knowledge Base:
2555840 descripción del Service Pack 2 para Microsoft Forefront Threat Management Gateway 2010
Estado
Microsoft ha confirmado que se trata de un problema de los productos de Microsoft que se enumeran en la sección "Aplicable a".
Más información
Para evitar este problema en ISA 2006 o en TMG sin Service Pack 2, puede utilizar la siguiente secuencia de comandos para establecer el parámetro interno en una regla de publicación web especificada. De forma predeterminada, esta es la opción que habilita TMG Service Pack 2.
Para utilizar la secuencia de comandos, cópielo en el Bloc de notas y, a continuación, guárdelo como un archivo .vbs en uno de los miembros de la matriz.
Modifique la línea siguiente en la secuencia de comandos, sustituyendo ReplaceRuleNameHere por el nombre de la regla de publicación web correspondiente:
argRuleName = "ReplaceRuleNameHere"
A continuación, ejecute el siguiente script en uno de los miembros de la matriz en una matriz:
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
Referencias
Para obtener más información acerca de la terminología de la actualización de software, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
824684 descripción de la terminología estándar que se utiliza para describir las actualizaciones de software de Microsoft
