مصادقة LDAP في OpenVPN تعمل لكن فحص المجموعة يفشل: أين تبحث

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

اعتبر الرفض إجابة تفويض

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

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

قرّر هل تسكن العضوية في المرشح أم في كتلة مجموعة

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

بهذا الشكل يقرّر المرشح كل شيء، لذلك يجب أن يكون RequireGroup مساويًا false وإلا بحثت الإضافة عن كائن مجموعة لم يذكره المرشح قط. ويجب أن تكون السمة في المرشح موجودة على كائن المستخدم ومملوءة، وهذا غير مضمون بمجرد أن تتشعّب المجموعات.

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

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

النقطة العمياء مشتركة: مقارنة العضوية المباشرة لا توسّع المجموعات المتشعّبة، لذا يفشل حساب يصل وصوله عبر مجموعة أب بينما تعرض وحدة التحكم العضوية بعد. يكشف Active Directory السمة member على المجموعة، وتستخدم مخططات أخرى uniqueMember، والإشارة إلى السمة الخاطئة تعيد نتيجة فارغة بدلًا من خطأ.

اختر نقطة نهاية تحمل كائن المجموعة

يحدّد عنوان URL أي دليل تسأله الإضافة، ووحدة تحكم مجال على المنفذ 389 تجيب فقط عن سياق التسمية الخاص بها. كتالوج عام على المنفذ 3268 يجيب عن الغابة بأكملها، للقراءة فقط ومع مجموعة سمات جزئية. عندما تكون الحسابات في نطاق واحد ومجموعة VPN في نطاق آخر، فقد يجد استعلام أحادي النطاق المستخدم ويظل يفوّت العضوية. هذه هي الحالة التي يحل فيها نقل عنوان URL إلى منفذ الكتالوج الرفض، وهي أيضًا الحالة التي يعمّم فيها الناس أكثر من اللازم.

مجموعة السمات الجزئية هي الحد: لا يمكن الترشيح على سمة لا يحتفظ بها الكتالوج، لذا قد يجعل التغيير نفسه نشرًا يعمل وآخر يعيد لا شيء. أكّد ما تعيده نقطة النهاية فعلًا للمستخدم والمجموعة الحقيقيين قبل إعادة كتابة الكتلة. الإحالات وTLS شأنان منفصلان مرة أخرى، إذ يجب تتبّع الإحالة، ونقطة النهاية التي تتطلب TLS تحتاج ملفات الثقة المطابقة.

أبقِ حالة الحساب ونطاق البحث في حقولهما

تنتمي علامة التعطيل إلى المرشح، لا إلى فحص المجموعة. في Active Directory هي البتة الثانية من userAccountControl، وبدون ذلك الشرط يصادق حساب معطّل بكلمة مرور صالحة ثم يفشل عند خطوة المجموعة، ما يبدو كخلل في التفويض. نطاق البحث ينتمي إلى الـ DN الأساسي، لأن البدء من جذر النطاق أبطأ وقد يطابق كائنات خارج الوحدة التنظيمية التي قصدت تغطيتها.

أبقِ صلاحيات حساب الربط ضيّقة أيضًا. صلاحيات الدليل الواسعة تحوّل مرشحًا خاطئ التكوين إلى استعلام ناجح وتخفي الخلل حتى يدقق أحدهم الحساب. غيّر العضوية في الدليل نفسه، لا في قائمة استثناءات محلية، حتى يكون تعطيل الحساب كافيًا لإزالة الوصول. وإذا كان فريق آخر يدير المجموعة، فاتفق معه على السمة التي يملؤها قبل كتابة مرشح عليها.

أثبت النتيجة بثلاثة حسابات

شغّل التكوين على ثلاث هويات: عضو مسموح به، وحساب صالح خارج المجموعة، وحساب عُطّل. إذا رُفضت الثلاثة، فالربط أو استعلام المجموعة معطوب؛ وإذا قُبلت الثلاثة، فلا يُطبَّق أي شرط مجموعة إطلاقًا. النتيجة المختلطة هي النتيجة الوحيدة التي تثبت أن التكوين يميّز الحالات التي تهمك.

اقرأ الإجابات الثلاث نفسها مباشرة من الدليل قبل لوم الإضافة. يعرض الاستعلام الأول سمة المجموعة التي يعتمد عليها المرشح، ويعرض الثاني قيمة التحكم بالحساب. استبدل بالـ DN الأساسي والحساب ونقطة النهاية ما يخصّك:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

المستخدم الذي يعود memberOf فارغًا له حالة دليل، لا خلل إضافة، والحساب الذي ما زال يصادق بعد تعطيله يعني أن المرشح يفتقد شرط التحكم بالحساب. أصلح ذلك الدليل أولًا، ثم أعد تشغيل اختبار الحسابات الثلاثة. أبقِ سطر السجل الذي سمّى الخطوة الفاشلة بجوار تغيير التكوين، حتى يستطيع الشخص التالي فصل التفويض عن المصادقة دون تكرار البحث.