لماذا أحصل على gssexception عند استخدام Active Directory SSO من Microsoft IE إلى خادم Java؟

Question

كنت أقوم ببناء نظام مصادقة لتوقيع SIGNATORY Active Directory لتطبيقات الويب Java (باستخدام Spnego/Kerberos) ، وكل شيء يعمل بشكل جيد مع Firefox أو (وبحسب ما يقال) Safari ، لكن Internet Explorer يتسبب في استثناء:

GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)

في الواقع ، اعتقدت أن IE عملت قبل تثبيت تصحيح Windows.

Answer 1

على ما يبدو ، تم تمكين Microsoft IE Patch KB974455 "الحماية الموسعة" لمصادقة Windows المتكاملة. عادةً ، مع مصادقة SPNEGO/Kerberos ، تحصل جهاز العميل على تذكرة Kerberos/Active Directory للخادم وتعرض هذه التذكرة أثناء التفاوض على مصادقة HTTP. اعتبارًا من Java 1.6 على الأقل ، فإن مكتبة Java JGSS-API قادرة على تفسير التفاوض على SPNEGO/Kerberos ومصادقة التذكرة.

مع ال الحماية الممتدة (أنظر أيضا الحماية الموسعة للمصادقة) ، أي يضيف قناة ملزمة لمفاوضات spnego ؛ ما هي البيانات التي تعتمد عليها الربط القناة غير معروفة حاليًا بالنسبة لي ، بخلاف أن معرف جلسة SSL يبدو جزءًا منه. تحاول مكتبة Java JGSS-API التحقق من صحة ربط القناة و canno دون البيانات التي يعتمد عليها الربط. ثم يرمي استثناء عدم تطابق القناة.

أسفرت القضية بعض إنترنت حركة المرور, ، بما فيها Sun Bug ID 6851973.

وفقًا للتعليقات المرتبطة بـ 6851973 ، RFC 4121, ، يقول ،

إذا كان المتصل إلى GSS_ACCEPT_SEC_CONTEXT [RFC2743] يمر في GSS_C_NO_CHANNEL_BINDINGS [RFC2744] كروابط للقناة ، فقد يتجاهل القبول أي روابط قناة يوفرها البادئ ، مع عودة النجاح حتى في الارتباطات في القناة.

و "جميع منفذي KRB5 الرئيسيين ينفذون هذا" مايو ". يبدو أن JGSS تتطلب من المتلقاة توفير ربط القناة إذا كان البادئ يقدمه. علاوة على ذلك ، يتوفر الإصلاح في Java 7 ، Build 64 وسيتم نقله إلى Java 5 و 6 ، على الرغم من Java 6u18 لا يبدو أنه كان كما ورد في 6851973.

عرض عمل كما هو موضح في الحماية الموسعة للمصادقة هو تعيين

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\SuppressExtendedProtection

إعداد السجل إلى 0x02. هذا يعطل الحماية الممتدة.