How to Configure External LDAP Authentication for Zimbra

What external LDAP authentication changes in Zimbra

External LDAP authentication lets Zimbra verify a user’s password against another directory instead of the password stored in Zimbra’s internal LDAP. The current Zimbra Daffodil (v10) Administrator Guide states that external LDAP authentication is configured per domain and that the external method attempts to bind to the specified directory with the supplied user credentials. If the bind succeeds, the password is considered valid.

This does not automatically turn an external LDAP directory into Zimbra’s account database. Zimbra still stores Zimbra-specific account data in its own directory. The v10 guide explicitly notes that users normally need to exist in both Zimbra and the external directory unless you separately configure auto-provisioning.

For the current product documentation, see the Zimbra Daffodil v10 Administrator Guide and the Zimbra v10 Config Guide.

Quick planning checklist

• Confirm the Zimbra domain you want to change, for example example.com.
• Confirm that the same users already exist in Zimbra, or plan auto-provisioning separately.
• Know the external LDAP hostname, port, TLS method, and certificate chain.
• Know how a Zimbra login name maps to a user DN in LDAP.
• If the DN cannot be built directly from the login name, prepare a search base, search filter, and least-privilege search account.
• Keep a Zimbra administrator session open while testing so you can roll back quickly.

Choose the right mapping method first

The current v10 Config Guide still defines the search-base, search-bind, search-filter, and per-account external-DN attributes. Older official Zimbra Tech Center material explains how these mappings are used in practice. Because that material predates Daffodil, treat it as operational background and verify details against your installed release before applying a large migration. See the official Zimbra Tech Center external LDAP notes.

Step 1: Record the current domain authentication settings

Run administrative commands as the zimbra operating-system user. Before changing anything, capture the existing domain values:

su - zimbra

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthFallbackToLocal

احفظ المخرجات في سجل التغييرات. يسرد دليل التكوين v10 القيم الصالحة لـ zimbraAuthMech، بما في ذلك zimbra، ldapو ad، و Kerberos أو آليات مخصصة. في هذا الدليل، الآلية المستهدفة هي ldap.

الخطوة الثانية: التحقق من إمكانية الوصول إلى الشبكة وبروتوكول TLS قبل تغيير Zimbra

لا تقم باستكشاف أخطاء تعيينات المصادقة وإصلاحها حتى تتأكد من عمل الاتصال الأساسي. من خادم Zimbra، تأكد من حلّ أسماء النطاقات (DNS) وإمكانية الوصول إلى نقطة نهاية LDAP. بالنسبة لـ LDAPS، يمكنك فحص سلسلة الشهادات باستخدام OpenSSL.

openssl s_client -connect ldap.example.net:636 \
  -servername ldap.example.net -showcerts

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

ldapsearch -x -H ldap://ldap.example.net:389 -ZZ \
  -D "cn=zimbra-search,ou=svc,dc=example,dc=net" -W \
  -b "ou=people,dc=example,dc=net" \
  "(uid=alice)" dn

ينص دليل إدارة Zimbra الإصدار 10 على أن ldaps:نقطة النهاية تتطلب أن تكون شهادة خادم LDAP موثوقة لدى Zimbra. لا تتجاوز التحقق من الشهادة لمجرد اجتياز الاختبار. ثبّت المرجع المصدق أو سلسلة الشهادات المناسبة وفقًا لإجراءات مخزن الثقة الخاصة بإصدار Zimbra لديك.

الخطوة 3: تكوين قالب ربط مباشر لـ DN عندما تكون أسماء المستخدمين قابلة للتنبؤ

هذا هو النمط الأبسط. لنفترض أن الدليل الخارجي يخزن المستخدمين باسم ، uid=alice,ou=people,dc=example,dc=netوأن بيانات تسجيل الدخول إلى Zimbra هي alice@example.com. قم بتهيئة النطاق على النحو التالي:

zmprov md example.com zimbraAuthMech ldap

zmprov md example.com \
  zimbraAuthLdapURL "ldaps://ldap.example.net:636"

zmprov md example.com \
  zimbraAuthLdapBindDn "uid=%u,ou=people,dc=example,dc=net"

يصف دليل المسؤول zimbraAuthLdapBindDnسلسلة التنسيق المستخدمة لتحديد الاسم المميز (DN) المستخدم للربط الخارجي. وتوضح وثائق مركز زيمبرا التقني الرسمية قيم الاستبدال الشائعة، مثل %uقيمة للجزء المحلي من اسم تسجيل الدخول وقيمة %nلاسم تسجيل الدخول الكامل.

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

الخطوة 4: استخدم تعيين البحث والتصفية عندما يتعذر إنشاء الاسم المميز (DN) مباشرةً

تتيح خاصية تعيين مرشحات البحث لـ Zimbra تحديد موقع إدخال المستخدم أولاً، ثم التحقق من هويته باستخدام الاسم المميز (DN) المُعاد. ويحدد دليل التكوين v10 سمات النطاق المطلوبة المتعلقة بالبحث.

التكوين النموذجي على نمط OpenLDAP هو:

zmprov md example.com \
  zimbraAuthLdapSearchBase "ou=people,dc=example,dc=net"

zmprov md example.com \
  zimbraAuthLdapSearchFilter "(uid=%u)"

zmprov md example.com \
  zimbraAuthLdapSearchBindDn \
  "cn=zimbra-search,ou=svc,dc=example,dc=net"

لتجنب وضع كلمة مرور الدليل مباشرة في سجل الأوامر، اقرأها أولاً في متغير مؤقت للأوامر:

read -s LDAP_BIND_PASSWORD
zmprov md example.com \
  zimbraAuthLdapSearchBindPassword "$LDAP_BIND_PASSWORD"
unset LDAP_BIND_PASSWORD

يجب أن يقتصر حساب البحث على صلاحيات القراءة اللازمة للعثور على المستخدمين ضمن قاعدة البيانات المُهيأة. ولا يحتاج إلى صلاحيات إدارة دليل واسعة.

بالنسبة لـ Active Directory، قد يستخدم المرشح sAMAccountNameإما أو userPrincipalName، وذلك حسب اصطلاح تسجيل الدخول الخاص بك. كما توفر Zimbra آلية مصادقة خارجية لـ Active Directory، لذا استخدم الآلية الخاصة بـ AD عندما تتناسب بشكل أفضل مع بيئة النشر الخاصة بك بدلاً من فرض إعدادات LDAP العامة على جميع بيئات AD.

الخطوة 5: التحقق مما تم تخزينه فعليًا في زيمبرا

اقرأ سمات النطاق مرة أخرى بعد التغيير:

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthLdapSearchBindDn \
  zimbraAuthFallbackToLocal

تحقق من وجود أخطاء في الاقتباس، أو اسم قاعدة بيانات غير صحيح، أو اسم مضيف غير متوقع، أو تعيين قديم متبقٍ من محاولة سابقة. لا تقم بطباعة كلمة مرور البحث والربط في المستندات أو لقطات الشاشة أو التذاكر أو سجلات الأوامر.

الخطوة 6: الاختبار مع مستخدم واحد خاضع للتحكم قبل التعميم على نطاق واسع

اختر حساب اختبار غير إداري موجود في كل من Zimbra والدليل الخارجي. اختبر هذه الحالات عمدًا:

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

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

الخطوة 7: حدد ما إذا كنت تحتاج أيضًا إلى التزويد التلقائي

تختلف وظيفتا المصادقة الخارجية وتوفير الحسابات. إذا كان ينبغي لمستخدمي الدليل الجدد الحصول على حسابات Zimbra تلقائيًا، فقم بتكوين التوفير التلقائي لـ Zimbra بشكل منفصل. يوثق دليل المسؤول v10 الحالي أوضاع EAGER وLAZY وMANUAL وخصائصها zimbraAutoProv*.

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

أنماط الأعطال الشائعة وما يجب فحصه

خطة التراجع

إذا كان تكوين الدليل الخارجي يمنع مصادقة المستخدم العادية، فقم بتبديل المجال مرة أخرى إلى مصادقة Zimbra الداخلية باستخدام جلسة مسؤول مفتوحة بالفعل:

zmprov md example.com zimbraAuthMech zimbra

ثم تحقق من القيمة:

zmprov gd example.com zimbraAuthMech

لا تحذف سمات LDAP الخارجية أثناء عملية التراجع الطارئ إلا إذا كان لديك سبب وجيه لذلك. فالحفاظ عليها يُسهّل عليك تحديد سبب الفشل وإعادة المحاولة بعد تصحيح مشكلة الربط أو بروتوكول TLS.

ملخص المراجع العملية

• zimbraAuthMech: يحدد آلية المصادقة للنطاق.
• zimbraAuthLdapURL: نقطة نهاية LDAP خارجية؛ تُستخدم ldaps:لبروتوكول LDAP عبر SSL.
• zimbraAuthLdapBindDn: تنسيق يستخدم لإنشاء اسم المستخدم المميز (DN) للربط المباشر.
• zimbraAuthLdapSearchBase: الشجرة الفرعية التي يبحث فيها برنامج Zimbra عن المستخدم الخارجي.
• zimbraAuthLdapSearchFilter: مرشح LDAP المستخدم لتحديد موقع المستخدم.
• zimbraAuthLdapSearchBindDnو zimbraAuthLdapSearchBindPassword: بيانات الاعتماد المستخدمة للبحث عندما لا يكون البحث المجهول مناسبًا.
• zimbraAuthLdapExternalDn: تعيين اسم مميز خارجي صريح لحساب Zimbra واحد.
• zimbraAuthFallbackToLocal: يتحكم في ما إذا كان Zimbra سيعود إلى المصادقة المحلية في حالة فشل المصادقة الخارجية.

قائمة التحقق النهائية للتحقق من الصحة

• يمكن الوصول إلى نقطة نهاية LDAP الخارجية من خادم صندوق بريد Zimbra.
• تنجح عملية التحقق من صحة شهادة TLS دون اللجوء إلى حلول بديلة غير آمنة.
• يقوم قالب bind-DN ​​المختار أو عامل تصفية البحث بربط تسجيل دخول واحد بإدخال دليل واحد بالضبط.
• يوجد مستخدم الاختبار في Zimbra أو تم تكوين التزويد التلقائي عمدًا.
• تتصرف اختبارات كلمات المرور الصحيحة وغير الصحيحة كما هو متوقع.
• يتوافق سلوك التراجع مع سياسة الأمان الخاصة بك.
• تم توثيق إعدادات النطاق الأصلية وأمر التراجع.

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