Question

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és via un réseau privé virtuel).

Nous essayons maintenant d'optimiser les performances du site Web. En raison du fonctionnement de NTLM, chaque nouvelle requête adressée à IIS est composée de 3 requêtes différentes, tandis que les 2 premières correspondent à 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é la solution . Malheureusement, cela n'a rien changé et nous continuons à recevoir cette réponse 401 (qui prend 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 demande. .

Les clients utilisés sont IE6 et IIS version 6.

Quelqu'un peut-il conseiller?

Était-ce utile?

La solution

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 qu’IIS exigera automatiquement une nouvelle authentification lorsqu’une requête POST sera effectuée.

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 sont utilisés avec Fiddler.

Autres conseils

Le seul moyen consiste à utiliser NTLM sur la page de connexion uniquement et à 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 à chaque demande.

http://msdn.microsoft.com/ en-us / library / aa347548 (VS.90) .aspx

http://blogs.technet.com/b/configurationmgr/archive/2010/06/03/solution-you-may -experience-slow-performance-lors-d'utilisation de bits et de kerberos-authentification-sur-configmgr-2007-distribution-points.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 passer à 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://www.microsoft.com/technet/prodtechnol/WindowsServer2003 /Library/IIS/b0b4ec5c-74f8-43e9-ac64-d8b852568341.mspx?mfr=true

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 un moyen plus simple d’éditer les propriétés et d’aider davantage que de modifier directement le fichier XML.

Un moyen 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 if ou une modification si, 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 sont à l'origine de ce problème. 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 de consulter 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, il semble fonctionner parfaitement.

De plus, je ne mettrais jamais d’informations sensibles dans un fichier JS (ni dans un fichier CSS) et je vous suggérerais de ne pas le faire non plus. Si vous le faites, vous voudrez évidemment déplacer les informations sensibles de ces fichiers hors de ces répertoires.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top