Éviter la réponse 401 pour chaque requête en utilisant NTLM
nous avons ici un asp.net 3.5 application utilisant L'authentification Windows basée sur NTLM. Le système fonctionne sur un réseau privé qui est distribué sur différents lieux géographiques (connectés via VPN).
nous essayons maintenant d'optimiser les performances du site. Parce que la façon dont fonctionne NTLM, chaque nouvelle requête à L'IIS est composée de 3 requêtes différentes alors que les 2 premières sont 401 réponses. Nous essayons de minimiser le montant de ces demandes doit être uniquement à le début de la session. Nous avons trouvé cette "solution . Malheureusement, cela n'a rien changé et nous continuons à recevoir cette réponse 401 (qui prend du temps).
afin de voir le trafic j'ai d'abord utilisé par le Violoniste app. 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 que je vérifie le trafic via WireShark, je vois que j'ai toujours cette réponse 401 pour chaque demande.
les clients utilisés sont IE6, IIS version 6.
Quelqu'un peut-il nous conseiller?
7 réponses
NTLM / Negotiate, contrairement à tous les autres systèmes D'authentification HTTP, sont des protocoles orientés connexion.
dans IIS, il existe différents paramètres qui contrôlent si l'authentification sera demandée pour toutes les requêtes sur une connexion préalablement authentifiée (par exemple AuthPersistSingleRequest). Indépendamment de ce réglage, je pense que IIS demandera automatiquement une réauthentification lors d'une requête POST.
si votre serveur nuit à la connexion réutiliser (par exemple en envoyant une connexion: fermer l'en-tête dans les réponses) vous devez corriger cela parce que sinon la réauthentication se produira. Vous pouvez facilement vérifier une telle authentification-réutiliser des en-têtes foiling en utilisant Fiddler.
la seule façon est D'utiliser NTLM sur la page de connexion seulement et utiliser cookie comme ici
avez-vous essayé cela dans votre domaine?
setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount
il permet au pool d'applications de servir les requêtes D'auth NTLM.
il pourrait être vos paramètres de sécurité sur IE6 pour le site. Essayez de passer à intranett local ou site de confiance.
sur un sujet apparenté; si vous utilisez IIS7.0 et kerberos authentification il apparaît AuthPersistNonNTLM=true peut être utilisé pour éviter 401 allers-retours pour chaque requête.
http://msdn.microsoft.com/en-us/library/aa347548 (VS.90).aspx
j'ai exactement le même problème! J'utilise le même environnement que vous. Sauf que je vois 2 401 dans Fiddler. J'avais passé quelques jours sur ce problème, et puis simplement abandonné. Authpersistance n'a pas fonctionné pour moi non plus. Mais voici les liens que j'avais trouvé, peut-être qu'ils vont travailler 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 mettre le drapeau à la fois au niveau du répertoire virtuel et du site Web, mais cela n'a pas aidé. Êtes-vous utiliser L'Explorateur Metabase IIS pour éditer ces propriétés? C'est la façon la plus propre d'éditer les propriétés et peut aider plus que l'édition directe du fichier XML.
une façon de contourner le problème est d'insérer l'en-tête Cache-Control dans la réponse HTTP pour les ressources qui ne vont pas changer fréquemment sur n'importe quelle page. Dans mon cas, j'ai mis en cache les fichiers css (utiliser des CSS externes autant que possible pour optimiser ceci), js et img. Depuis que j'ai environ 60 fichiers de ce type qui obtiennent chargé sur notre page d'accueil, nous avons été en mesure d'éliminer environ 120 401 erreurs tout de suite!
assurez-vous d'utiliser l'en-tête Cache-contrôle et non la mise en cache si-modifié ou basée sur une étiquette e où un 401 et un 304 seront encore 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 surtout les fichiers JS et CSS qui ont causé cela. Mon site (comme la plupart des sites) conserve des fichiers JS et CSS dans ses propres répertoires. Donc la solution pour moi était simplement d'aller dans ces répertoires dans IIS et de permettre à Anon Auth (je dis simplement mais il m'a fallu plus de deux ans pour y arriver; merci à ce post). Maintenant le site a toujours besoin de Windows auth mais les sous répertoires pour les fichiers JS et CSS ne le font pas. OIE, il semble être au travail parfaitement.
Je ne mettrais jamais d'informations sensibles dans un fichier JS (ou CSS d'ailleurs) et je suggérerais que vous ne le fassiez pas non plus. Si vous le faites, vous aurez évidemment voulez déplacer les informations sensibles dans ces fichiers de ces répertoires.