خطأ ADFS V2.0: MSIS7042: قدمت جلسة متصفح العميل نفسها طلبات "6" في آخر ثانية "1"

Question

الناس ، لقد حصلت على تطبيق ASP.NET MVC الذي أحاول تأمينه باستخدام إصدار مرشح الإصدار من ADFS V2.0 (جنيف). لقد قمت بتكوين التطبيق باعتباره ثقة الطرف بالاعتماد ، وقد استخدمت fedutil.exe لتعديل الويب الخاص بالتطبيق.

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

قدمت جلسة متصفح العميل نفسها طلبات "6" في آخر ثواني "1". يمكن أن يكون هناك تكوين سيء محتمل. اتصل بمسؤولك للحصول على التفاصيل.

لا توجد أخطاء في سجلات الأحداث على جانب MVC أو على جنيف باستثناء حدث يحتوي على الرسالة أعلاه. إذا كان بإمكان شخص ما أن يعطيني بعض المعلومات حول كيفية المحاولة والتصحيح ، وتشخيص ، ونأمل في حل هذه المشكلة ، سأكون ممتنًا إلى الأبد.

مرة أخرى ، مربع جنيف هو مرشح إصدار ADFS V2.0 وتم تصميم موقع ASP.NET MVC باستخدام أحدث إصدار (أواخر '09) من Windows Identity Foundation SDK مع Web.Config المعدلة باستخدام fedutil.exe من wif sdk .

---

لذلك ستحصل على ركلة من هذا ... جربت هذا التطبيق نفسه من Firefox و ... إنه يعمل. لقد تمت مطالبتي ببيانات اعتماد المجال الخاصة بي ، يقوم خادم ADFS V2 بإعادة توجيه لي مرة واحدة ، ثم انتهى بي الأمر على الصفحة الرئيسية لتطبيقي ، مع اسمك مع اسم حسابي وتحية مخصصة. والآن القضية الحقيقية هي: لماذا الجحيم يتم القبض على IE8 في حلقة إعادة توجيه لا حصر لها و Firefox ليست؟ بعد إجراء مزيد من الاختبارات ، تمكنت من عمل هذا السيناريو ، خارج الصندوق ، دون تعديل أي من الأشياء الافتراضية لخطوط الأنابيب من ADFS V2 (RC) أو من WIF (RTW) على كل من Safari و Firefox. IE8 هو المتصفح الوحيد الذي يظهر أي مشكلة في التعامل مع سيناريو المصادقة هذا. لقد جربت كل شيء ، بما في ذلك تثبيت والثقة في الشركات الموقعة ذاتيا ، وإضافة المواقع إلى منطقة إنترانت المحلية الخاصة بي وإسقاط الأمان إلى ملفات تعريف الارتباط ذات الجهات الأولى والثالثة للسماح دائمًا.

Answer 1

تبين أن الاسم المضيف للحزب الاعتماد كان له سطحي في ذلك (khoffman_2). على ما يبدو ، فإن السطح السفلي هو شخصية DNS غير قانونية ، وسوف يرفض IE فقط المعلومات مع السطح السفلي فيه.

أعيدت تسمية جهازي من Khoffman_2 إلى Koffman2 و ADFS V2/MVC تعتمد مجموعة الحفلات على العمل بشكل لا تشوبه شائبة على Firefox و Safari و IE.

Answer 2

لقد واجهت نفس المشكلة مع ADFS 1.0 ولحلها ، تأكدت من أن عنوان URL كان لديه مقطع زائد للأمام "/" الذي سيعمل دائمًا في Firefox وكذلك أي

على سبيل المثال: https://somedomain.com/application_2/

Answer 3

على الرغم من أن هذه ليست مشكلتك ، فقد واجهنا مشاكل مماثلة لما وصفته. كان حلنا هو:

1. مصادقة أساسية ممكّنة في IIS (لم يكن هذا مطلوبًا للخطوات الثانية التالية)
2. تعطيل مصادقة Windows في IIS (هذا حل المشكلة لبعض متصفحات IE ولكن ليس كل شيء)
3. تعطيل الوصول المجهول في IIS (هذا حل المشكلة لبقية متصفحات IE)

Answer 4

إجابة جاكسيديان قريبة.

في حالتي ، كان علي فقط أن:

• مصادقة Windows -> معطل

• Auth مجهول -> ممكّن

• انتحال شخصية ASP.NET -> معطل

• Forms Auth -> معطل

• Auth Windows -> معطل

Answer 5

يمكن أن تحدث هذه الحلقة عندما لا يُسمح للمستخدم بالوصول إلى صفحة.

كان لدينا سمة تفويض مخصصة على وحدة تحكم MVC الخاصة بنا والتي تتحقق لمعرفة ما إذا كان المستخدم في دور بناءً على المطالبات المقدمة إذا كان الإعداد لـ USEADFS صحيحًا في ملفات التكوين. اعتقدت أن هذا الإعداد قد تم ضبطه على True وكان مرتبكًا أنني ظللت أحصل على حلقة ADFS عند الوصول إلى الصفحة لأنني كنت في المجموعات التي تم تفويضها بالوصول إلى الصفحة.

كان مفتاح استكشاف الأخطاء وإصلاحها هو إنشاء صفحة ويب تعرض مطالبات ADFS الخاصة بي دون أن تتطلب المصادقة بالضرورة.

@if (User.Identity.IsAuthenticated)
{
    <div>UserName: @User.Identity.Name;</div>

    var claimsIdentity = User.Identity as System.Security.Claims.ClaimsIdentity;
    <table>
        @foreach (var claim in claimsIdentity.Claims)
        {
        <tr><td>@claim.Type</td><td>@claim.Value</td></tr>
        }
    </table>


}

لقد لاحظت أنني كنت أحصل على تسجيل الدخول إلى ADFs ، وكانت مطالباتي محددة ، لذلك كانت ADFs تعمل. كانت المشكلة الفعلية هي أن ملف التكوين الخاص بي كان يستخدم userAdfs = "true" بدلاً من USEADFS = "True" الذي تسبب بشكل أساسي في إرجاع رمز التفويض المخصص الخاص بي على التفويض. لذلك ، استمرت الصفحة في إعادة توجيهي إلى ADFs للمصادقة مرة أخرى.

على أي حال ، إذا لم يكن لدى المستخدم المطالبات الصحيحة للوصول إلى الصفحة ، فيمكن أن تحدث حلقة تسجيل الدخول إلى ADFS هذه أيضًا.

أيضًا ، إذا كتبت سمة تفويض مخصصة ، فتأكد من مراجعة الرابط التالي الذي يصف كيفية منع الحلقة.

إعادة توجيه حلقة مع .NET MVC تفويض السمة مع مطالبات ADFS

Custom GealuteUnauthorizedRequest Code Code for SuperizeAttribute من هذا الرابط:

 protected override void HandleUnauthorizedRequest System.Web.Mvc.AuthorizationContext filterContext)
    {
        if (filterContext.HttpContext.Request.IsAuthenticated)
        {
            //One Strategy:
            //filterContext.Result = new System.Web.Mvc.HttpStatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);

            //Another Strategy:
            filterContext.Result = new RedirectToRouteResult(
                new RouteValueDictionary(
                    new
                    {
                        controller = "u",
                        action = "LoginStatus",
                        errorMessage = "Error occurred during authorization or you do not have sufficient priviliges to view this page."
                    })
                );
        }
        else
        {
            base.HandleUnauthorizedRequest(filterContext);
        }
    }