Symptômes
Considérez le scénario suivant :
-
Vous disposez d’un serveur qui exécute Microsoft Forefront Threat Management Gateway (TMG) 2010.
-
Le serveur TMG est configuré comme un serveur web.
-
Le port d’écoute web TMG utilise l’authentification par formulaires avec la délégation NTLM sur le serveur web publié.
-
Il existe des demandes POST pour le serveur web TMG.
Dans ce scénario, les requêtes POST peuvent échouer. Cela peut entraîner divers problèmes des applications qui dépendent du type de demandes POST qui ont échoué.
Cause
Ce problème se produit si les conditions suivantes sont remplies :
-
L’authentification basée sur les formulaires TMG est utilisée.
-
Délégation NTLM est configurée dans la règle de publication de TMG à déléguer l’authentification au serveur web publié.
-
ISA envoie une demande au serveur web sur une connexion déjà authentifiée.
-
Le serveur web répond avec un 401.
Lorsque la délégation NTLM est utilisée, TMG authentifie une connexion vers le serveur web à la première demande au serveur web sur cette connexion. L’authentification est ensuite rendue persistante dans la connexion afin que les demandes ultérieures ne doivent pas avoir une réauthentification.
Si une demande est envoyée au serveur web sur une connexion déjà authentifiée, le serveur web peut répondre à une demande de 401 authentification inattendue. Ce problème peut se produire lorsque les requêtes sont traitées par les différents pools d’applications sur le serveur web, car IIS ne persiste pas d’authentification entre des pools d’applications.
Lorsque l’authentification basée sur les formulaires est utilisée, TMG gérera la demande inattendue de 401 rediriger l’utilisateur vers la ressource demandée à l’origine et en ajoutant une balise AuthResend à l’URL. Lorsque le client effectue la deuxième demande, TMG détermine que la demande doit être ré-authentification par la balise AuthResend et supprime ensuite la balise AuthResend avant que la demande est envoyée au serveur web.
Toutefois, une redirection ne comprend pas d’une méthode HTTP, et le client doit effectuer une demande GET après une redirection. Par conséquent, la demande POST et le corps de PUBLICATION ne sont pas envoyées au serveur web.
Un outil tel que Strace, HTTPWatch ou Fiddler peut servir à déterminer si TMG envoie des redirections qui ont la balise AuthResend en réponse à des demandes POST sur le client. Par exemple, une redirection d’une requête de l’URL http://domain/test.asp aurait l’aspect suivant : http://domain/test.asp&authResendNNN
Les journaux du proxy web TMG n’affichent pas la balise AuthResend car la balise est supprimée à partir de l’URL avant de l’URL est envoyée au serveur web et n’est par conséquent également pas enregistré.
Ce problème peut également se produire pour les requêtes GET. Toutefois, le comportement ne provoque pas de problème, étant donné que la redirection est renvoyée sous la forme d’une demande GET, et cela ne provoque pas le même problème.
Résolution
Il existe un paramètre interne qui peut être défini sur une règle de publication pour indiquer à TMG pour authentifier automatiquement les demandes non-GET. Cela permet d’éviter les 401 demandes inattendues à partir du serveur web.
Par défaut, dans le Service Pack 2 de TMG, ce paramètre est activé sur les règles dont l’authentification basée sur les formulaires sur le port d’écoute web et qui utilise la délégation NTLM de publication web.
Pour résoudre ce problème, installez le service pack qui est décrit dans l’article suivant de la Base de connaissances Microsoft :
2555840 description du Service Pack 2 pour Microsoft Forefront Threat Management Gateway 2010
État
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».
Plus d'informations
Pour contourner ce problème sur ISA 2006 ou TMG sans le Service Pack 2, vous pouvez utiliser le script suivant pour définir le paramètre interne sur une règle de publication web spécifiée. Par défaut, c’est le paramètre qui permet à TMG Service Pack 2.
Pour utiliser le script, copiez-le dans le bloc-notes, puis enregistrez-le sous un fichier .vbs sur l’un des membres du groupe.
Modifiez la ligne suivante dans le script, en remplaçant ReplaceRuleNameHere par le nom de la règle de publication web pertinentes :
argRuleName = "ReplaceRuleNameHere"
Puis, exécutez le script suivant sur l’un des membres du tableau dans un tableau :
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
Références
Pour plus d'informations sur la terminologie de mise à jour logicielle, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
Description 824684 terminologie standard utilisée pour décrire les mises à jour logicielles de Microsoft
