Éviter la réponse 401 pour chaque demande à l'aide de NTLM
Nous avons ici une application asp.net 3.5 utilisant l’authentification Windows basée sur NTLM . Le système fonctionne sur un réseau privé qui est effectivement réparti sur différents emplacements géographiques (connecté via un réseau privé virtuel (VPN)).
Nous essayons maintenant d'optimiser les performances du site. En raison du fonctionnement de NTLM, chaque nouvelle requête adressée à IIS est composée de 3 requêtes différentes, tandis que la première 2 correspond à 401 réponses. Nous essayons de minimiser le nombre de ces demandes pour qu’elles ne se produisent qu’au début de la session. Nous avons trouvé ceci solution. Malheureusement, cela n'a rien changé et nous continuons à recevoir cette réponse 401 (ce qui consomme du temps).
Pour voir le trafic, j'ai d'abord utilisé l'application Fiddler. D'une manière ou d'une autre, lorsque j'utilise Fiddler, il n'y a qu'un seul processus d'authentification au début de la session (exactement comme je le souhaite), mais lorsque je ferme Fiddler et vérifie le trafic via WireShark, je constate que j'ai toujours cette réponse 401 pour chaque requête .
Les clients utilisés sont IE6, IIS version 6.
Quelqu'un peut-il conseiller?
NTLM/Negotiate, contrairement à tous les autres schémas d'authentification HTTP, sont des protocoles en mode connexion.
Dans IIS, divers paramètres permettent de contrôler si une authentification sera demandée pour toutes les demandes sur une connexion précédemment authentifiée (par exemple, AuthPersistSingleRequest). Indépendamment de ce paramètre, je pense que IIS demandera automatiquement une nouvelle authentification lors de la demande de POST.
Si votre serveur empêche la réutilisation de la connexion (par exemple en envoyant un en-tête Connection: close dans les réponses), vous devez résoudre ce problème car sinon la réauthentification se produira. Vous pouvez facilement vérifier que de tels en-têtes de duplication d’authentification-réutilisation sont utilisés avec Fiddler.
Le seul moyen est d’utiliser NTLM sur la page de connexion uniquement et d’utiliser un cookie tel que ici
Sur un sujet connexe; Si vous utilisez l'authentification IIS7.0 et Kerberos, il apparaît que AuthPersistNonNTLM = true peut être utilisé pour éviter 401 allers-retours pour chaque demande.
http://msdn.Microsoft.com/en-us/library/aa347548(VS.90).aspx
Avez-vous essayé cela dans votre domaine?
setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount
Il permet au pool d'applications de répondre aux demandes d'authentification NTLM.
Cela pourrait être vos paramètres de sécurité sur IE6 pour le site. Essayez de changer pour un site intranett local ou de confiance.
J'ai exactement le même problème! J'utilise le même environnement que vous. Sauf que je vois 2 401 même dans Fiddler. J'avais passé deux jours sur ce problème, puis je l'avais abandonné. AuthPersistence n'a pas fonctionné pour moi non plus. Mais voici les liens que j'ai trouvés, peut-être qu'ils fonctionneront dans votre cas.
http://msdn.Microsoft.com/en-us/library/ms525244.aspx
http://technet.Microsoft.com/en-us/library/cc786094.aspx
http://technet.Microsoft.com/en-us/library/cc781339(WS.10).aspx
J'ai essayé de définir l'indicateur au niveau du répertoire virtuel et du site Web, mais cela n'a pas aidé. Utilisez-vous l'explorateur de métabase IIS pour modifier ces propriétés? C'est la manière la plus simple de modifier les propriétés et peut aider davantage que la modification directe du fichier XML.
Une façon de contourner le problème consiste à insérer l'en-tête Cache-Control dans la réponse HTTP pour les ressources qui ne vont pas changer fréquemment sur aucune page. Dans mon cas, j'ai mis en cache les fichiers css (utilisez autant que possible css externe pour l'optimiser), les fichiers js et img. Comme j'ai environ 60 fichiers de ce type qui sont chargés sur notre page d'accueil, nous avons pu éliminer environ 120 401 erreurs immédiatement!
Assurez-vous que vous utilisez l'en-tête Cache-Control et non la mise en cache basée sur une balise e ou si-modifiée, où un 401 et un 304 seront toujours générés même lorsque les fichiers sont mis en cache.
J'avais aussi ce problème sauf que, pour moi, ce sont principalement les fichiers JS et CSS qui ont causé cela. Mon site (comme la plupart des sites) conserve les fichiers JS et CSS dans leurs propres répertoires. La solution pour moi était donc simplement d'aller dans ces répertoires dans IIS et d'activer Anon Auth (je dis simplement, mais il m'a fallu plus de deux ans pour résoudre ce problème; grâce à cet article). Maintenant, le site nécessite toujours une autorisation Windows, mais pas les sous-répertoires des fichiers JS et CSS. IOW, cela semble fonctionner parfaitement.
De plus, je ne mettrais jamais d’informations sensibles dans un fichier JS (ni dans un fichier CSS) et je suggérerais que vous ne le fassiez pas non plus. Si vous le faites, vous souhaiterez évidemment déplacer les informations sensibles de ces fichiers hors de ces répertoires.