تعيين مجموعات LDAP في ASA مقابل DAP لسياسة مجموعة VPN
خريطة سمات LDAP وسياسة DAP كلتاهما تختار سياسة مجموعة، لكنهما تعملان في نقطتين مختلفتين. تتبّع أيّهما استخدمته جلسة ASA فعليًا.
سجلّان منفصلان يحدّدان سياسة المجموعة التي تتلقّاها جلسة AnyConnect، وهما يعيشان في موضعين مختلفين من الإعداد وبنمطي فشل مختلفين. خريطة سمات LDAP تترجم قيمة من الدليل إلى سمة تخويل في ASA أثناء المصادقة؛ وسجل DAP يقيّم الشروط بعد ذلك ويمكنه إضافة السمات أو تجاوزها. كلاهما يمكن أن ينتهي إلى اسم السياسة نفسه، لذا فإن تسجيل دخول ناجح لا يخبرك أيّ آلية أنتجته. الهدف من المقارنة بينهما هو اختيار إحداهما عن قصد بدلًا من ترك الثانية تتجاوز الأولى بهدوء.
آليتان ونقطتا قرار
يتلخّص الاختيار في ثلاثة أسئلة: هل يعتمد القرار على قيمة سمة واحدة في الدليل، وهل يحتاج أكثر من تلك القيمة، وأي آلية يُسمح لها بالفوز عندما يتطابق الاثنان؟
إذا كان المدخل الوحيد هو عضوية المجموعة، فإن خريطة السمات هي الأداة الأصغر والأسهل في التدقيق: خريطة واحدة مرتبطة بخادم AAA واحد، بسطر واحد لكل مجموعة. وإذا كان الاختيار يجب أن يراعي حالة الجهاز وهوّيته أو سمة ثانية أو نافذة زمنية، فستنفد مدخلات الخريطة وتصبح DAP هي الآلية القادرة على التعبير عن القاعدة. وإذا كان الاثنان قيد الاستخدام، فاعرف الأسبقية في إصدارك قبل كتابة أي منهما، لأن الجلسة التي تطابق سجل DAP قد لا تحتفظ بالسياسة التي أعادتها الخريطة. وما تبقى كله أعمال تسجيل.
مسار خريطة السمات، بترتيب الإعداد
يبدأ مسار الخريطة عند تعريف خادم AAA. يجب ربط خريطة السمات بمدخل خادم LDAP الذي يستخدمه ملف تعريف الاتصال فعليًا؛ والخريطة الموجودة في الإعداد العامل دون أن يشير إليها ذلك الخادم لا تغيّر شيئًا. سطر الربط ذلك هو ما يجعل بقية الإعداد فعّالة. ودليل تعيين LDAP في ASA هو المرجع لصيغة الخريطة في إصدارات 9.x.
داخل الخريطة، يسمّي أحد الأسطر سمة الدليل والسمة في ASA التي تغذّيها، وتترجم أسطر أخرى قيمًا محددة. map-name memberOf Group-Policy متبوعًا بـ map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly هو الشكل: الجانب الأيسر هو ما أعاده الدليل، والجانب الأيمن هو اسم سياسة مجموعة يجب أن تكون موجودة مسبقًا. الاسم المميّز واسم عرض السياسة ليسا قابلين للتبادل، وخطأ بسيط في أي من السلسلتين لا ينتج عنه خطأ عند تسجيل الدخول.
هناك تفصيلان مؤلمان هنا: memberOf يعيد كل مجموعة ينتمي إليها الحساب، لذا فالمستخدم الموجود في مجموعتين معيّنتين يمنح الخريطة قيمتين مرشحتين، والقاعدة الأبجدية في الدليل هي الحل الوحيد للتعادل الذي يمكن الاعتماد عليه بدلًا من ترتيبك الخاص للأولوية. والقيمة غير المعيّنة لا تعطي شيئًا على الإطلاق، فتعود بصمت إلى السياسة الافتراضية للملف التعريفي.
مسار DAP، وما يضيفه
تقيّم DAP الشروط وتطبّق السمات فوق نتيجة AAA. يحمل السجل أولوية وإجراءً ومجموعة شروط؛ وتُقيَّم السجلات بترتيب الأولوية ويقرّر الإجراء ما إذا كان التقييم يستمر أو يتوقف. هذا نموذج تنفيذ مختلف عن البحث عن قيمة، ولهذا تحديدًا يستطيع التعبير عن قواعد لا تستطيعها الخريطة.
ما تضيفه DAP هو المدخلات. يمكن للشروط أن تشير إلى سمات الدليل وسمات الجهاز وحالة الوضع الأمني، ويمكن للسجل المطابق أن يحمل قوائم تحكم وقوائم عناوين URL أو مرشّحات لتلك الجلسة. لذا فقاعدة مثل حصول فريق الدعم على حاسوب مُدار على سياسة القراءة فقط، بينما يحصل الفريق نفسه على جهاز غير مُدار على سياسة مقيّدة، قابلة للتعبير في DAP وليس في خريطة سمات. أما الخريطة فلديها مدخل واحد بالضبط: القيمة التي أعادها الدليل للسمة التي سمّيتها.
تضيف DAP أيضًا موضعًا ثانيًا للبحث عندما تنتهي الجلسة إلى سياسة خاطئة. فالسجل الذي يطابق بإجراء متابعة لا ينهي التقييم، ويمكن لسجل لاحق أن يغيّر النتيجة، لذا فما تراه هو حصيلة تسلسل وليس بحثًا واحدًا. اقرأ أرقام الأولوية بالترتيب، وتذكّر أن سجل الاحتياط قد يكون هو من يقوم بالعمل. أما الخريطة فلا تسلسل لها: سمة واحدة، وقيمة واحدة، وجواب واحد.
حيث تختلف الآليتان
الأسبقية هي الجزء الذي يكسر التصاميم. عندما تطابق الجلسة كلا من مدخل الخريطة وسجل DAP، تعتمد النتيجة على الإصدار وعلى إجراء السجل، لذا تحقّق منها على ASA خاصتك بدلًا من افتراض أن أيًا من الآليتين تملك النتيجة.
ثلاثة أنماط فشل تفسّر معظم الالتباس. خريطة معرّفة لكنها غير مرتبطة أبدًا بوسم الخادم الذي يستخدمه الملف التعريفي تنتج السياسة الافتراضية دون أي خطأ في أي مكان. وسلسلة شرط DAP التي تختلف عن قيمة الدليل في حالة الأحرف أو المسافات لا تطابق أبدًا، فيُطبَّق سجل الاحتياط بهدوء. وسياسة مجموعة غير موجودة بعد تقبلها الخريطة، لأن الخريطة تعيد اسمًا فقط، فتحصل الجلسة على لا شيء من الأذونات المقصودة دون أن يشير شيء في السجل إلى الكائن المفقود. تحقّق من الثلاثة قبل لمس عضوية المجموعة.
قراءة الأدلة من جلسة حيّة
اقرأ الجواب من جلسة جديدة لا من الإعداد. show vpn-sessiondb detail anyconnect filter name jdoe يطبع سياسة المجموعة التي تلقتها الجلسة فعليًا، وshow running-config ldap attribute-map يؤكّد القيم التي كان يمكن أن تعيدها الخريطة. وعلى جانب الدليل، يعرض test aaa-server authentication LDAP-AD username jdoe password <password> السمات التي أعادها ASA، ويعرض debug ldap 255 التبادل عندما يخالف الاختبار ما توقّعته.
ثم طابق أربعة سجلات كتابةً: قيمة الدليل، والخريطة أو شرط DAP المهيّأ، وسياسة المجموعة المحلية، والمورد الذي استطاع المستخدم الوصول إليه فعلًا. فإذا توافقت الثلاثة الأولى ولم يتوافق الرابع، فالمشكلة في متن السياسة لا في الاختيار. وإذا أظهرت الجلسة اسم السياسة الصحيح لكن قائمة التحكم الخاطئة، فتوقف عن النظر إلى LDAP تمامًا. غيّر سجلًا واحدًا في كل مرة وأعد فحص جلسة جديدة، لأن الجلسة المعاد اتصالها هي الدليل الوحيد الذي يعكس الإعداد الذي كتبته للتو.