البحث في الموقع

تعرفنا في الدرس السابق على كيفية تثبيت وضبط خادوم openldap على أوبنتو، سنتعرف في هذا الدرس على التناسخ في خادوم OpenLDAP. التناسختتزايد أهمية خدمة LDAP عندما تزداد أنظمة الشبكات المُعتَمِدة عليها؛ تكون الممارسات العملية القياسية -في مثل هذه البيئة- هي بناء redundancy في LDAP لمنع توقف الخدمات إذا لم يعد يستجيب خادوم LDAP؛ يتم ذلك باستخدام تناسخ LDAP؛ نصل إلى التناسخ باستخدام محرك Syncrepl؛ الذي يسمح بمزامنة التغيرات باستخدام موديل «مستهلك-مزود»؛ نوع التناسخ الذي سنستخدمه في هذا الدرس هو دمج للنوعين الآتيين: refreshAndPersist، و delta-syncrepl؛ الذي يُرسِل فيه المزود القيود إلى المستهلك عند إنشائهم مباشرةً؛ بالإضافة إلى أنه لا تُرسَل جميع القيود، وإنما التغيرات التي حصلت فقط. ضبط المزودسنبدأ بضبط المزود (Provider) أنشِئ ملف LDIF بالمحتويات الآتية وسمِّه provider_sync.ldif: # Add indexes to the frontend db. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryCSN eq - add: olcDbIndex olcDbIndex: entryUUID eq #Load the syncprov and accesslog modules. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov - add: olcModuleLoad olcModuleLoad: accesslog # Accesslog database definitions dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=example,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # Accesslog db syncprov. dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # syncrepl Provider for primary db dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE # scan the accesslog DB every day, and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00غيّر قيمة rootDN في ملف LDIF ليُطابِق الذي عندك في الدليل. لا يجب تعديل إعدادات apparmor لبرمجية slapd لتحديد موقع قاعدة بيانات accesslog، لأن الملف ‎/etc/apparmor/local/usr.sbin.slapd يحتوي على الأسطر الآتية: /var/lib/ldap/accesslog/ r, /var/lib/ldap/accesslog/** rwk,أنشِئ مجلدًا، وهيّء ملف ضبط قاعدة البيانات، وأعد تحميل apparmor: sudo -u openldap mkdir /var/lib/ldap/accesslog sudo -u openldap cp /var/lib/ldap/DB_CONFIG /var/lib/ldap/accesslog sudo service apparmor reloadأضف المحتويات الجديدة؛ وأعد تشغيل العفريت بسبب التعديل في apparmor: sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f provider_sync.ldif sudo service slapd restartلقد ضُبِطَ المزود بنجاح. ضبط المستهلكعليك الآن ضبط المستهلك. تثبيت البرمجية باتباع تعليمات قسم «التثبيت»؛ وتأكد أن قاعدة بيانات slapd-config مماثلة للمزود؛ وتحديدًا تأكد من أن المخططات ولاحقة قاعدة البيانات هي نفسها. أنشِئ ملف LDIF بالمحتويات الآتية وسمِّه consumer_sync.ldif: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID eq - add: olcSyncRepl olcSyncRepl: rid=0 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=admin,dc=exa credentials=secret searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog - add: olcUpdateRef olcUpdateRef: ldap://ldap01.example.comتأكد أن قيم الخاصيات الآتية صحيحة: provider (اسم مضيف المزود –ldap01.example.com في هذا المثال– أو عنوان IP).binddn (الاسم الفريد للمدير الذي تستخدمه).credentials (كلمة مرور المدير الذي تستخدمه).searchbase (لاحقة قاعدة البيانات التي تستخدمها).olcUpdateRef (اسم مضيف أو عنوان IP لخادوم المزود).rid عدد من ثلاثة أرقام يعرف النسخة، يجب أن يكون لكل مستهلك رقم rid واحد على الأقل).أضف المحتويات الجديدة: sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f consumer_sync.ldifلقد انتهيت، يجب أن يبدأ الآن تزامن قاعدتَيّ البيانات (ذاتَيّ اللاحقة dc=example,dc=com). الاختباربعد بدء الاستنساخ، تستطيع مراقبته بتشغيل الأمر: ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base contextCSN dn: dc=example,dc=com contextCSN: 20120201193408.178454Z#000000#000#000000عندما تتوافق المخرجات في المزود والمستهلك (20120201193408.178454Z#000000#000#000000 في المثال السابق) في كلا الجهازين؛ فستكون عملية الاستنساخ قد تمَّت؛ وفي كل مرة يُجرى فيها تعديل في المزود، فإن القيمة ستُعدَّل وكذلك يجب أن تُعدَّل قيمة ناتج الأمر السابق في المستهلك أو المستهلكين. إذا كان اتصالك ضعيفًا، أو كان حجم قاعدة بيانات ldap كبيرًا، فربما يحتاج contextCSN في المستهلك وقتًا ليطابق مثيله في المزود؛ لكنك تعلم أن العملية قيد الإجراء لأن contextCSN في المستهلك يزداد مع الزمن. إذا كان contextCSN في المستهلك مفقودًا، أو كان لا يطابق المزود؛ فعليك إيقاف العملية والبحث عن سبب المشكلة قبل الإكمال، جرب التحقق من سجلات slapd‏ (syslog) وملفات auth في المزود للتأكد فيما إذا كانت طلبات الاستيثاق من المستهلك قد نجحت أم لا؛ وفيما إذا أعادت طلبياته للحصول على بيانات (ستشبه عبارات ldapsearch كثيرًا) أيّة أخطاء. لاختبار إذا كان يعمل؛ جرب طلب DN في قاعدة البيانات في المستهلك: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com dnيجب أن تشاهد المستخدم «john» والمجموعة «miners» بالإضافة إلى عقدتَيّ «People» و «Groups». التحكم في الوصولإدارة أي نوع من الوصول (قراءة، أو كتابة ...إلخ.) التي يجب أن يحصل عليها المستخدمون للموارد تدعى «التحكم في الوصول» (access control)؛ تعليمات الضبط المستخدمة تسمى «قوائم التحكم في الوصول» (access control lists) أو ACL. عندما نُثبِّت حزمة slapd، فستُضبَط قوائم مختلفة للتحكم في الوصول؛ سنلقي نظرةً على بعض نتائج هذه القيم الافتراضية؛ وسنحصل بذلك على فكرة عن كيفية عمل قوائم التحكم بالوصول وكيفية ضبطها. لكي نحصل على ACL فعال لطلبية LDAP، فسنحتاج إلى أن ننظر إلى سجلات قوائم التحكم بالوصول لقاعدة البيانات التي تُجرى الطلبيات عليها، بالإضافة إلى واجهة أمامية (frontend) خاصة لقاعدة البيانات؛ قوائم التحكم بالوصول المتعلقة بالنقطة الأخيرة تسلك سلوكًا افتراضيًا في حالة لم تتطابق النقطة الأولى؛ الواجهة الأمامية لقاعدة البيانات هي ثاني ما «تنظر» إليه قوائم التحكم بالوصول؛ وأول ما ستُطبِّقه قوائم التحكم بالوصول هو أول ما سُيطابَق («first match wins») بين مصدرَيّ قوائم التحكم بالوصول السابقَين؛ ستعطي الأوامر الآتية، على التوالي وبالترتيب، قيم ACL لقاعدة بيانات hdb ‏(«dc=example,dc=com») والقيم المتعلقة بالواجهة الأمامية لقاعدة البيانات: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none lcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by * readملاحظة: يملك rootDN دائمًا جميع الحقوق لقاعدة بياناته؛ تضمينها في قوائم التحكم بالوصول يوفر توضيحًا للضبط؛ لكنه يؤدي إلى تخفيض في أداء slapd. sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAccess dn: olcDatabase={-1}frontend,cn=config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * readأول قائمة تحكم بالوصول هي مهمة ومحورية: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * noneيمكن أن يعبر عنها بطريقة أخرى لتسهيل فهمها: to attrs=userPassword by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none to attrs=shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * noneتركيبة قوائم التحكم بالوصول (هنالك قاعدتين) تجبر ما يلي: الوصول المجهول 'auth' موفر إلى خاصية userPassword لكي يتم الاتصال الابتدائي؛ ربما هذا عكس البديهي، نحتاج إلى 'by anonymous auth' حتى لو لم نكن نريد الوصول المجهول إلى شجرة بيانات الدليل. بعد أن تتصل النهاية البعيدة، فعندها يمكن أن يقع الاستيثاق (انظر النقطة الآتية).يمكن أن يحدث الاستيثاق لأن جميع المستخدمين لديهم وصول 'read' (بسبب 'by self write') لخاصية userPassword.عدا ذلك، فلا يمكن الوصول إلى خاصية userPassword من أي مستخدمين آخرين؛ مع استثناء rootDN، الذي يملك وصولًا كاملًا إليها.لكي يغير المستخدمون كلمات مرورهم، باستخدام passwd أو غيرها من الأدوات، فإن خاصية shadowLastChange يجب أن تكون متاحةً بعد الاستيثاق من المستخدم.يمكن البحث في شجرة DIT السابقة بسبب 'by * read' في: to * by self write by dn="cn=admin,dc=example,dc=com" write by * readإذا لم يكن هذا مرغوبًا فعليك تعديل ACL؛ ولكي يكون الاستيثاق جبريًا أثناء طلب bind، فيمكنك بشكل بديل (أو بالمشاركة مع ACL المعدلة) استخدام التعليمة 'olcRequire: authc'. وكما ذُكِر سابقًا، لا يوجد حساب إدارة مُنشَأ لقاعدة بيانات slapd-config. لكن هنالك هوية SASL التي تملك الوصول الكامل إليها؛ والتي تمثل root أو sudo؛ ها هي ذا: dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=authسيعرض الأمر الآتي قوائم التحكم بالوصول (ACLs) لقاعدة بيانات slapd-config: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess dn: olcDatabase={0}config,cn=config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * breakولما كانت هذه هوية SASL، فإننا نحتاج إلى استخدام آلية SASL عندما نستخدم أداة LDAP كما رأينا ذلك للعديد من المرات في هذا الكتاب؛ هذه الآلية خارجية؛ انظر إلى الأمر السابق كمثال، لاحظ أنه: يجب أن تستخدم sudo لكي تصبح بهوية الجذر لكي تطابق قوائم التحكم بالوصول.الآلية الخارجية (EXTERNAL) تعمل باستخدام IPC (مقابل نطاقات UNIX) الذي يعني أنه عليك استخدام صيغة ldapi URI.طريقة موجزة للحصول على جميع قوائم التحكم بالوصول: sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffixهنالك المزيد من الأمور التي يجب الحديث عنها في موضوع التحكم في الوصول؛ راجع صفحة الدليل man slapd.access. TLSعند الاستيثاق لخادوم OpenLDAP فمن الأفضل استخدام جلسة مشفرة؛ ويمكن أن يتم ذلك باستخدام أمن طبقة النقل (Transport Layer Security‏ [TLS]). هنا، سنكون «سلطة الشهادة» (Certificate Authority) الخاصة بنا وبعدها سنُنشِئ ونوقع شهادة خادوم LDAP؛ ولما كان slapd مُصَرَّفًا بمكتبة gnutls، فسنستخدم الأداة certtool لإكمال هذه المهام. ثبت حزمتَيّ gnutls-bin و ssl-cert: sudo apt-get install gnutls-bin ssl-certأنشِئ مفتاحًا خاصًا لسلطة الشهادة: sudo sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"أنشئ الملف/القالب ‎/etc/ssl/ca.info لتعريف سلطة الشهادة: cn = Example Company ca cert_signing_keyأنشِئ شهادة سلطة شهادات موقعة ذاتيًا: sudo certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile /etc/ssl/certs/cacert.pemاصنع مفتاحًا خاصًا للخادوم: sudo certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/ldap01_slapd_key.pemملاحظة: استبدل ldap01 في اسم الملف باسم مضيف خادومك؛ ستساعدك تسمية الشهادة والمفتاح للمضيف والخدمة التي تستخدمها في توضيح الأمور. أنشئ ملف المعلومات ‎/etc/ssl/ldap01.info الذي يحتوي: organization = Example Company cn = ldap01.example.com tls_www_server encryption_key signing_key expiration_days = 3650الشهادة السابقة صالحة لعشرة أعوام، عدِّل هذه القيمة وفقًا لمتطلباتك. أنشِئ شهادة الخادوم: sudo certtool --generate-certificate \ --load-privkey /etc/ssl/private/ldap01_slapd_key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load-ca-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ldap01.info \ --outfile /etc/ssl/certs/ldap01_slapd_cert.pemأنشئ الملف certinfo.ldif بالمحتويات الآتية (عدلها وفقًا لمتطلباتك؛ حيث اعتبرت أمثلتنا أن الشهادات مُنشَأة باستخدام https://www.cacert.org): dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pemاستخدم الأمر ldapmodify لإخبار slapd عن عمل TLS عبر قاعدة بيانات slapd-config: sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldifوعلى النقيض من الاعتقاد الشائع؛ لا تحتاج إلى استخدام ldaps‎://‎ في ‎/etc/default/slapd لكي تستخدم التشفير، كل ما عليك امتلاكه هو: SLAPD_SERVICES="ldap:/// ldapi:///"ملاحظة: أصبح LDAP عبر TLS/SSL‏ (dlaps://‎) مهجورًا لتفضيل StartTLS، يشير الأخير إلى جلسة LDAP (تستمع على منفذ TCP ذي الرقم 389) التي تصبح محميةً بواسطة TLS/SSl؛ حيث LDAPS -مثل HTTPS- هو بروتوكول منفصل مشفر منذ البداية (encrypted-from-the-start) الذي يعمل على منفذ TCP ذي الرقم 636. اضبط الملكية والأذونات: sudo adduser openldap ssl-cert sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem sudo chmod o-r /etc/ssl/private/ldap01_slapd_key.pemأعد تشغيل خدمة OpenLDAP: sudo service slapd restartتحقق من سجلات المضيف (‎/var/log/syslog) لترى إن بدأ تشغيل الخادوم بنجاح. التناسخ و TLSإذا ضبَطت التناسخ بين الخواديم، فمن الممارسات الشائعة هي تشفير (StartTLS) بيانات النسخ المارة في الشبكة لتفادي التنصت عليها؛ وهذا منفصل عن استخدام التشفير والاستيثاق كما فعلنا سابقًا؛ سنبني في هذا القسم على استيثاق TLS. سنفترض هنا أنك ضبطت الاستنساخ بين المزود والمستهلك وفقًا للقسم «التناسخ»؛ وضبطت TLS للاستيثاق في المزود وفقًا للقسم «TLS». وكما ذكر سابقًا؛ هدف التناسخ (بالنسبة لنا) هو أن تكون خدمة LDAP ذات إتاحية كبيرةً؛ ولمّا كنا نستخدم TLS للاستيثاق في المزود فإننا نحتاج إلى نفس الأمر في المستهلك؛ بالإضافة إلى ذلك، نريد أن تكون بيانات الاستنساخ المنقولة مشفرةً، وما بقي ليُفعَل هو إنشاء مفتاح وشهادة للمستهلك ثم الضبط وفقًا لذلك، وسنولد المفتاح/الشهادة في المزود؛ لكي نتجنب إنشاء شهادة أخرى لسلطة الشهادات، ثم سننقل ما يلزمنا إلى المستهلك. في المزود: أنشِئ مجلدًا (الذي سيستخدم في النقل النهائي)، ثم ولِّد مفتاح المستهلك الخاص: mkdir ldap02-ssl cd ldap02-ssl sudo certtool --generate-privkey \ --bits 1024 \ --outfile ldap02_slapd_key.pemأنشئ ملف المعلومات ldap02.info للخادوم المستهلك، وعدِّل قيمه وفقًا لمتطلباتك: organization = Example Company cn = ldap02.example.com tls_www_server encryption_key signing_key expiration_days = 3650أنشِئ شهادة المستهلك: sudo certtool --generate-certificate \ --load-privkey ldap02_slapd_key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load-ca-privkey /etc/ssl/private/cakey.pem \ --template ldap02.info \ --outfile ldap02_slapd_cert.pemاحصل على نسخة من شهادة سلطة الشهادات: cp /etc/ssl/certs/cacert.pem .لقد انتهينا الآن، انقل مجلد ldap02-ssl إلى المستهلك؛ حيث استخدمنا هنا scp (عدّل الأمر وفقًا لمتطلباتك): cd .. scp -r ldap02-ssl user@consumer:في المستهلك: ضبط استيثاق TLS: sudo apt-get install ssl-cert sudo adduser openldap ssl-cert sudo cp ldap02_slapd_cert.pem cacert.pem /etc/ssl/certs sudo cp ldap02_slapd_key.pem /etc/ssl/private sudo chgrp ssl-cert /etc/ssl/private/ldap02_slapd_key.pem sudo chmod g+r /etc/ssl/private/ldap02_slapd_key.pem sudo chmod o-r /etc/ssl/private/ldap02_slapd_key.pemأنشئ الملف ‎/etc/ssl/certinfo.ldif وفيه المحتويات الآتية (عدِّلها وفقًا لمتطلباتك): dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap02_slapd_cert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap02_slapd_key.pemاضبط قاعدة بيانات slapd-config: sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldifاضبط ‎/etc/default/slapd في المزود (SLAPD_SERVICES). في المستهلك: اضبط TLS للتناسخ من جهة المستهلك، وعدِّل خاصية olcSyncrepl الموجودة مسبقًا بتتبع بعض خيارات TLS؛ وبفعل ذلك، سنرى للمرة الأولى كيف نعدل قيمة خاصية ما. أنشئ الملف consumer_sync_tls.ldif بالمحتويات الآتية: dn: olcDatabase={1}hdb,cn=config replace: olcSyncRepl olcSyncRepl: rid=0 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demandالخيارات الإضافية تحدد، على التوالي وبالترتيب، أن على المستهلك استخدام StartTLS وأن شهادة CA مطلوبةٌ للتحقق من هوية المزود، ولاحظ أيضًا صيغة LDIF لتعديل قيم خاصية ما ('replace'). نفِّذ هذه التعديلات: sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_sync_tls.ldifثم أعد تشغيل slapd: sudo service slapd restartعلى المزود: تأكد من أن جلسة TLS قد بدأت؛ وذلك عبر السجل ‎/var/log/syslog، بافتراض أنك أعدت مستوى التسجيل إلى 'conns'، وعليه سترى رسائل شبيهة بالآتي: slapd[3620]: conn=1047 fd=20 ACCEPT from IP=10.153.107.229:57922 (IP=0.0.0.0:389) slapd[3620]: conn=1047 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[3620]: conn=1047 op=0 STARTTLS slapd[3620]: conn=1047 op=0 RESULT oid= err=0 text= slapd[3620]: conn=1047 fd=20 TLS established tls_ssf=128 ssf=128 slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 slapd[3620]: conn=1047 op=1 RESULT tag=97 err=0 textترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenLDAP Server.