تجنب استجابة 401 لكل طلب باستخدام NTLM

Question

لدينا هنا تطبيق asp.net 3.5 يستخدم مصادقة Windows المستندة إلى NTLM.يعمل النظام على شبكة خاصة موزعة فعلياً على أماكن جغرافية مختلفة (متصلة عبر VPN).

نحن نحاول الآن تحسين أداء الموقع.نظرًا لأن الطريقة التي يعمل بها NTLM، فإن كل طلب جديد إلى IIS يتكون من 3 طلبات مختلفة بينما يكون الطلبان الأولان عبارة عن 401 استجابة.ونحاول تقليل كمية هذه الطلبات لتكون فقط في بداية الجلسة.وجدنا هذا حل.لسوء الحظ، لم يغير أي شيء وما زلنا نتلقى هذا الرد 401 (الذي يستهلك الوقت).

من أجل رؤية حركة المرور، استخدمت تطبيق Fiddler لأول مرة.بطريقة ما، عندما أستخدم Fiddler، هناك عملية مصادقة واحدة فقط في بداية الجلسة (تمامًا كما أريد)، ولكن عندما أغلق Fiddler وأتحقق من حركة المرور عبر WireShark، أستطيع أن أرى أنه لا يزال لدي استجابة 401 لكل طلب .

العملاء المستخدمون هم IE6 وIIS الإصدار 6.

يمكن للشخص أن ينصح؟

Answer 1

وNTLM / مفاوضة، خلافا لجميع أنظمة المصادقة HTTP الأخرى، بروتوكولات مهيأ للاتصال.

في IIS، وهناك العديد من الإعدادات التي تتحكم في ما إذا كان سيتم طالب المصادقة لكافة الطلبات على اتصال مصادق عليه من قبل (على سبيل المثال AuthPersistSingleRequest). مستقلة عن هذا الإعداد، وأعتقد أن IIS المطالبة إعادة المصادقة تلقائيا عند تقديم طلب POST.

إذا خادمك يلحق ضررا إعادة الاتصال (على سبيل المثال، عن طريق إرسال اتصال: رأس الوثيق في الردود) يجب إصلاح ذلك لأن خلاف ذلك سوف يحدث إعادة المصادقة. يمكنك التحقق بسهولة لرؤوس إفشال هذا التوثيق-إعادة استخدام عازف الكمان.

Answer 2

الطريقة الوحيدة هي استخدام NTLM في صفحة تسجيل الدخول فقط واستخدام ملفات تعريف الارتباط مثل هنا

Answer 3

في موضوع ذات الصلة؛ إذا كنت تستخدم IIS7.0 ومصادقة Kerberos يبدو AuthPersistNonNTLM = صحيح يمكن استخدامها لتجنب 401 رحلات ذهابا وإيابا لكل طلب.

http://msdn.microsoft.com/ أون لنا / مكتبة / aa347548 (VS.90) .aspx اتصال

<وأ href = "http://blogs.technet.com/b/configurationmgr/archive/2010/06/03/solution-you-may-experience-slow-performance-when-using-bits-and- كيربيروس المصادقة على اساس configmgr-2007-التوزيع-points.aspx "يختلط =" نوفولو noreferrer "> http://blogs.technet.com/b/configurationmgr/archive/2010/06/03/solution-you-may -خبرة بطيئة الأداء عندما بت باستخدام سنوات و-كيربيروس المصادقة على اساس configmgr-2007-التوزيع-points.aspx

Answer 4

هل حاولت هذه في المجال الخاص بك؟

setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount

وانها تسمح تجمع التطبيقات لخدمة طلبات NTLM المصادقة.

Answer 5

قد يكون من إعدادات الأمان على IE6 للموقع. حاول تغيير إلى intranett المحلية أو موقع موثوق به.

Answer 6

ولدي نفس المشكلة بالضبط! أنا أستخدم نفس البيئة كما كنت. إلا أن أرى 2 401 حتى في عازف الكمان. قضيت بضعة أيام على هذه المشكلة ثم قدم للتو على ذلك. لم AuthPersistence لا تعمل بالنسبة لي سواء. ولكن هنا هي الروابط التي كنت قد وجدت، وربما أنها سوف تعمل في قضيتك.

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

وحاولت تعيين علامة في كل من دليل ظاهري ومستوى الموقع، ولكن ذلك لم يساعد. هل تستخدم مستكشف IIS قاعدة التعريف لتحرير هذه الخصائص؟ هذه هي الطريقة الأكثر نظافة لتحرير خصائص ويمكن أن تساعد أكثر من تحرير ملف XML مباشرة.

وإحدى الطرق للتحايل على هذه المشكلة هو إدراج رأس ذاكرة التخزين المؤقت-تحكم في استجابة HTTP للموارد التي لن تتغير بشكل متكرر في أي صفحة. في حالتي، وأنا مؤقتا المغلق (استخدام المغلق الخارجي قدر الإمكان لتحسين هذا)، شبيبة وملفات IMG. منذ لدي حوالي 60 ملفات من هذه الأنواع التي تحصل تحميلها على موقعنا، تمكنا من القضاء على حوالي 120 401 الأخطاء على الفور!

تأكد من استخدام الرأس Cache-تحكم وليس إذا المعدلة أو العلامة البريد مقرها المؤقت حيث ستظل لدت 401 و 304 حتى عندما يتم التخزين المؤقت الملفات.

Answer 7

وكنت أعاني من هذه المشكلة أيضا إلا أنه، بالنسبة لي، كان معظمهم من ملفات JS و CSS التي تسبب هذا. موقعي (مثل معظم المواقع) يحتفظ JS وملفات CSS في وجود الدلائل الخاصة. لذلك كان الحل بالنسبة لي لمجرد الذهاب إلى هذه الدلائل في IIS وتمكين حالا مصادقة (أقول ببساطة ولكن الأمر استغرق أكثر من عامين بالنسبة لي للعمل من ذلك، بفضل هذه الوظيفة). الآن في موقع لا يزال يتطلب ويندوز المصادقة ولكن الدلائل الفرعية للشبيبة وملفات CSS لا. IOW، يبدو أن العمل على أكمل وجه.

وأنا أيضا لن تضع معلومات حساسة في ملف JS (أو ملف CSS لهذه المسألة) وأن أقترح عليك أن لا أحد. إذا قمت بذلك، سوف تريد من الواضح لنقل المعلومات الحساسة في هذه الملفات من هذه الدلائل.