كل شركة تشغّل Odoo إلى جانب Active Directory تصل عاجلاً أم آجلاً لنفس السؤال: لماذا نحتفظ بكلمات مرور في مكانين؟ الجواب غالباً "لأن أحداً لم يُكمل إعداد LDAP"، وهذا مؤسف، لأن الموديول المدمج يعمل بشكل ممتاز بمجرد أن تعرف أين يكمن الفخ. هذا الدليل يشرح الحقول بالتفصيل، سلوك إنشاء المستخدمين التلقائي، ومشكلة خاصة بـ Active Directory وقعت فيها أعداد كافية من المسؤولين لدرجة أن Odoo نفسها وثّقتها رسمياً.

لماذا توحّد المصادقة أصلاً

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

تفعيل الموديول

اذهب إلى Settings، مرر للأسفل إلى قسم Integrations، وفعّل LDAP Authentication. احفظ صفحة الإعدادات — هذه الخطوة يسهل نسيانها، ولن يعمل شيء بعدها قبل حفظها. بعد الحفظ، سيظهر خيار جديد "LDAP Server"؛ أنشئ واحداً واختر الشركة التي ينطبق عليها. إذا كانت قاعدة بياناتك متعددة الشركات، لاحظ أن لكل شركة قائمة خوادم LDAP خاصة بها، وهذا مهم لاحقاً عندما تقرر ترتيب الأولوية بين عدة خوادم دليل.

حقلاً بحقل: معلومات الخادم

في قسم معلومات الخادم ستدخل عنوان خادم LDAP والمنفذ. بالنسبة لـ LDAP النصي العادي، المنفذ الشائع هو 389؛ أما LDAP عبر SSL فهو 636. هناك أيضاً خانة "Use TLS" — فعّلها إذا كان خادمك يدعم StartTLS، والتي تطلب تشفير TLS/SSL للاتصال. لا تتجاوز هذه الخطوة في بيئة الإنتاج. إرسال بيانات اعتماد الدليل عبر اتصال غير مشفر داخل شبكتك الداخلية عادة سيئة تتحول إلى مسؤولية حقيقية بمجرد أن ينتهي جهاز لابتوب أحدهم على VLAN خاطئ.

حقلاً بحقل: حساب الربط (Bind)

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

حقلاً بحقل: القاعدة والفلتر

الـ LDAP base يحدد أين يبدأ Odoo البحث في شجرة الدليل — شيء مثل dc=yourdomain,dc=com. حدّد هذا النطاق بأضيق ما يمكن. توجيهه إلى جذر شجرة AD كبيرة يعني أن كل عملية بحث تمر عبر وحدات تنظيمية (OUs) غير ذات صلة، مما يبطئ كل محاولة تسجيل دخول.

فلتر LDAP هو الجزء الذي تخطئ فيه إعدادات Active Directory أكثر من غيره، لأن AD لا يستخدم نفس اصطلاحات الخصائص التي تستخدمها LDAP العامة أو OpenLDAP. فلتران يغطيان تقريباً كل الحالات الواقعية:

• sAMAccountName=%s — المصادقة باستخدام معرّف دخول AD (اسم المستخدم من ما قبل Windows 2000). هذا ما تريده معظم البيئات، لأنه يطابق ما يكتبه الناس فعلياً للدخول إلى Windows.
• mail=%s — المصادقة باستخدام البريد الإلكتروني للمستخدم بدلاً من ذلك، مفيد إذا وحّدت مؤسستك تسجيل الدخول على البريد الإلكتروني في كل مكان، بما في ذلك Odoo.

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

إنشاء المستخدمين تلقائياً عند أول تسجيل دخول

لست مضطراً لإنشاء كل مستخدم في Odoo يدوياً مسبقاً. فعّل "Create User" في إعداد خادم LDAP وسيقوم Odoo بإنشاء ملف مستخدم جديد تلقائياً في أول مرة يصادق فيها الشخص بنجاح. يمكنك توجيه هذا الإنشاء التلقائي نحو قالب مستخدم محدد، يتحكم في المجموعات الافتراضية، وصلاحيات الوصول، وتخصيص الشركة للحسابات الجديدة. إن لم تختر قالباً، سيلجأ Odoo إلى استنساخ ملف تعريف المسؤول (administrator) — وهذا يبدو مريحاً حتى تدرك أن كل موظف جديد يسجل دخوله لأول مرة سيحصل على صلاحيات مستوى admin. اضبط قالباً بصلاحيات محدودة قبل تفعيل هذا الخيار. تخطي هذه الخطوة هو أحد أسرع الطرق لتنتهي بعشرات المسؤولين العرضيين في شركة نامية.

خطأ referral chasing في Active Directory

هذه هي المشكلة التي تولّد أكبر عدد من تذاكر الدعم: بيانات الاعتماد صحيحة، حساب الربط يعمل، الفلتر سليم — ومع ذلك لا يستطيع المستخدم تسجيل الدخول. توثيق Odoo الرسمي عبر الإصدارات 17 و18 و19 وفرع master الحالي يشير إلى هذه المشكلة تحديداً مع Microsoft Active Directory. السبب هو referral chasing في مكتبة عميل LDAP: عندما يرجع AD استجابة إحالة (referral) أثناء البحث (وهو شائع في إعدادات متعددة domain controllers)، تحاول المكتبة الأساسية تتبع تلك الإحالة، وتفشل هذه المحاولة بصمت، فيُرفض تسجيل دخول كان في الأصل صحيحاً تماماً.

الحل الموثّق هو معامل نظام (system parameter)، وليس تعديل كود. فعّل developer mode، ثم اذهب إلى Settings → Technical → System Parameters وأنشئ إدخالاً جديداً:

• Key: auth_ldap.disable_chase_ref
• Value: True

احفظ، وأعد محاولة تسجيل الدخول. إذا كان مستخدموك المرتبطون بـ AD يُرفضون رغم التحقق من بيانات الاعتماد مرتين وثلاثاً، تحقق من هذا المعامل قبل أن تُضيّع مزيداً من الوقت في إعادة اختبار bind DN والفلاتر — إنه أشهر خطأ خاص بـ AD في هذا الربط بأكمله.

قائمة تحقق لتعزيز الأمان

اتصال يعمل ليس نفسه اتصال آمن. قبل أن تعتبر هذا الربط جاهزاً للإنتاج، تأكد مما يلي:

• TLS أو StartTLS مفعّل في إعداد خادم LDAP، وأن خادم الدليل يدعمه فعلياً — لا تكتفِ بتفعيل الخانة والافتراض أنها تعمل.
• bind DN يستخدم حساب خدمة مخصصاً بأقل صلاحيات ممكنة، وليس حساب domain admin أو حساباً شخصياً أبداً.
• الربط المجهول (anonymous bind) معطّل من جهة الدليل حيثما تسمح سياسة AD لديك، حتى لا يُستغل حقل bind DN الفارغ ولو عن طريق الخطأ.
• الـ LDAP base محصور في الوحدة التنظيمية (OU) التي يقيم فيها مستخدمو Odoo فعلياً، وليس شجرة النطاق بأكملها.

الشركات المتعددة وخوادم LDAP المتعددة

إذا كانت قاعدة بياناتك تخدم أكثر من شركة واحدة، تذكّر أن إعدادات خادم LDAP تُضبط لكل شركة على حدة — أنشئ إدخالاً منفصلاً لكل شركة تحتاج تسجيل دخول عبر الدليل. عندما ينطبق أكثر من خادم LDAP واحد (مثلاً domain controller رئيسي وآخر احتياطي، أو دليلان منفصلان لوحدتي أعمال)، فإن ترتيب التسلسل مهم: يفحص Odoo الخوادم بالترتيب المدرج ويستخدم أول خادم ينجح في مصادقة المستخدم. ضع أسرع وأكثر خوادم الدليل موثوقية أولاً، واستخدم حقل sequence للتحكم في هذا الترتيب بشكل متعمد بدلاً من تركه لترتيب إنشاء الإدخالات العشوائي.

قائمة تحقق قبل الإطلاق الفعلي

راجع هذه النقاط قبل أن تخبر أي أحد أن طريقة تسجيل الدخول الجديدة أصبحت مفعّلة:

• تأكد من تطابق المنفذ 389 أو 636 مع حالة تفعيل TLS — منفذ غير متطابق مع إعداد TLS طريق مسدود شائع ويمكن تجنبه.
• اختبر نطاق LDAP base DN بأداة بحث فعلية (مثل ldapsearch) قبل أن تثق به داخل واجهة Odoo، حيث تكون رسائل الخطأ أقل وضوحاً.
• تحقق من صياغة الفلتر مقابل حساب AD حقيقي — أكد ما إذا كانت اصطلاح تسجيل الدخول في مؤسستك يعتمد على sAMAccountName أو البريد الإلكتروني قبل الالتزام بواحد منهما.
• اضبط auth_ldap.disable_chase_ref استباقياً في بيئات AD بدلاً من انتظار أول تذكرة دعم فني.
• اختر قالب مستخدم محدود الصلاحيات للإنشاء التلقائي قبل تفعيل "Create User" — لا تتركه أبداً على الوضع الافتراضي لصلاحيات المسؤول.

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

المصادر

• LDAP authentication — Odoo 18.0 documentation
• LDAP authentication — Odoo 19.0 documentation
• LDAP authentication — Odoo 17.0 documentation
• Sign in with LDAP — Odoo 16.0 documentation
• LDAP Authentication - How to configure? (Odoo Forum)
• LDAP authentication — Odoo 18.0 documentation mirror (auth_ldap.disable_chase_ref detail)

مصدر الصورة: DeclanTM — BY