بروتوكول الوصول إلى الدليل الخفيف

الموسوعة الحرة

بروتوكول الوصول إلى الدليل الخفيف ( LDAP / ˈɛldæp / ) هو بروتوكول إنترنت للوصول إلى خدمات معلومات الدليل التي تعمل وفقًا لنماذج بيانات وخدمة X.500 . [ 1 ] يمكن العثور على وصف كامل للبروتوكول في "خارطة طريق المواصفات الفنية لبروتوكول الوصول إلى الدليل الخفيف (LDAP)" RFC 4510 ومراجعها. 

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

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

يُستخدم بروتوكول LDAP بشكل شائع لتوفير مكان مركزي لتخزين أسماء المستخدمين وكلمات المرور. وهذا يسمح للعديد من التطبيقات والخدمات المختلفة بالاتصال بخادم LDAP للتحقق من صحة المستخدمين. [ 3 ]

يُعدّ بروتوكول LDAP مجموعة فرعية أبسط ( أخف وزنًا ) من معايير سلسلة X.500 ، وتحديدًا بروتوكول الوصول إلى الدليل X.511 . [ 4 ] [ 5 ] وبسبب هذه العلاقة، يُطلق على LDAP أحيانًا اسم X.500 Lite . [ 6 ]

المكونات الرئيسية لـ LDAP هي:

  • بروتوكول ( RFC 4511 ): بروتوكول تطبيق يعمل عبر شبكة بروتوكول الإنترنت (IP) ويستخدم للتواصل مع خدمة الدليل 
  • نماذج معلومات الدليل ( RFC 4512 ): مواصفات للأنظمة التي تنفذ خدمات الدليل، أي "مجموعة من الأنظمة المفتوحة التي تتعاون لتقديم خدمات الدليل" [ 7 ] 
  • مخطط تطبيقات المستخدم ( RFC 4519 ): مخطط بيانات قياسي وقابل للتوسيع للمعلومات التي سيتم استخدامها في خدمة الدليل - "مواصفات لأنواع السمات وفئات الكائنات المخصصة للاستخدام بواسطة LDAP" [ 8 ] 

تاريخ

تطور فهم شركات الاتصالات لمتطلبات الدليل بشكل كبير بعد نحو سبعين عاماً من إنتاج وإدارة أدلة الهاتف. وقد أدخلت هذه الشركات مفهوم خدمات الدليل إلى تكنولوجيا المعلومات وشبكات الحاسوب ، وبلغت مساهمتها ذروتها في مواصفات X.500 الشاملة ، [ 9 ] وهي مجموعة من البروتوكولات التي أصدرها الاتحاد الدولي للاتصالات (ITU) في ثمانينيات القرن الماضي.

كانت خدمات دليل X.500 تُتاح تقليديًا عبر بروتوكول الوصول إلى الدليل X.511 (DAP)، الذي كان يتطلب حزمة بروتوكولات الربط البيني للأنظمة المفتوحة (OSI) . وكان الهدف الأصلي من LDAP هو أن يكون بروتوكولًا بديلًا خفيفًا للوصول إلى خدمات دليل X.500 عبر حزمة بروتوكولات TCP/IP الأبسط (والتي أصبحت الآن واسعة الانتشار) . وقد استُعير نموذج الوصول إلى الدليل هذا من بروتوكولي DIXIE وخدمة المساعدة في الدليل .

تم إنشاء البروتوكول في الأصل [ 10 ] بواسطة تيم هاوز من جامعة ميشيغان ، وستيف كيل من شركة إيسود المحدودة، وكولين روبنز من شركة نيكسور ، ووينجيك يونغ من شركة بيرفورمانس سيستمز إنترناشونال ، حوالي عام 1993، كخليفة [ 11 ] لبروتوكولي DIXIE و DAS . بدأ مارك وال من شركة كريتيكال أنجل، وتيم هاوز، وستيف كيل العمل في عام 1996 على إصدار جديد من LDAP، وهو LDAPv3، تحت إشراف فريق عمل هندسة الإنترنت (IETF). حلّ LDAPv3، الذي نُشر لأول مرة في عام 1997، محل LDAPv2 وأضاف دعمًا للتوسعة، ودمج طبقة المصادقة والأمان البسيطة ، وحسّن توافق البروتوكول مع إصدار 1993 من معيار X.500. وقد جاء المزيد من التطوير لمواصفات LDAPv3 نفسها، بالإضافة إلى العديد من الإضافات التي تُضيف ميزات جديدة إلى LDAPv3، من خلال فريق عمل هندسة الإنترنت (IETF) .

في المراحل الهندسية الأولى لبروتوكول LDAP، كان يُعرف باسم بروتوكول تصفح الدليل الخفيف ( LDBP ). أُعيد تسميته مع توسع نطاق البروتوكول ليشمل وظائف تحديث الدليل، بالإضافة إلى تصفح الدليل والبحث فيه. وقد سُمّي بالخفيف لأنه لم يكن يستهلك موارد الشبكة بكثافة مثل سلفه DAP، وبالتالي كان من الأسهل تنفيذه عبر الإنترنت نظرًا لاستهلاكه المتواضع نسبيًا لعرض النطاق الترددي.

أثر بروتوكول LDAP على بروتوكولات الإنترنت اللاحقة، بما في ذلك الإصدارات الأحدث من X.500، ودليل XML المُمكّن (XED)، ولغة ترميز خدمة الدليل (DSML)، ولغة ترميز توفير الخدمة (SPML)، وبروتوكول تحديد موقع الخدمة (SLP). كما يُستخدم كأساس لدليل Active Directory من مايكروسوفت .

نظرة عامة على البروتوكول

يبدأ العميل جلسة LDAP بالاتصال بخادم LDAP، يُسمى وكيل نظام الدليل (DSA)، افتراضيًا عبر منفذ 389 لبروتوكولي TCP و UDP ، أو عبر المنفذ 636 لبروتوكول LDAPS (LDAP عبر TLS/SSL، انظر أدناه). [ 12 ] ثم يرسل العميل طلب عملية إلى الخادم، ويرسل الخادم ردودًا. باستثناء بعض الحالات، لا يحتاج العميل إلى انتظار رد قبل إرسال الطلب التالي، ويجوز للخادم إرسال الردود بأي ترتيب. تُنقل جميع المعلومات باستخدام قواعد التشفير الأساسية (BER).

قد يطلب العميل العمليات التالية:

  • StartTLS – استخدم امتداد أمان طبقة النقل (TLS) الخاص بـ LDAPv3 للحصول على اتصال آمن
  • الربط – المصادقة وتحديد إصدار بروتوكول LDAP
  • البحث – البحث عن مدخلات الدليل و/أو استرجاعها
  • قارن – اختبر ما إذا كان إدخال مُسمى يحتوي على قيمة سمة معينة
  • أضف مدخلاً جديداً
  • حذف إدخال
  • تعديل إدخال
  • تعديل الاسم المميز (DN) - نقل أو إعادة تسمية إدخال
  • إلغاء – إلغاء طلب سابق
  • عملية موسعة – عملية عامة تُستخدم لتعريف عمليات أخرى
  • إلغاء الربط – إغلاق الاتصال (وليس عكس الربط)

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

إحدى الطرق البديلة الشائعة لتأمين اتصال LDAP هي استخدام نفق SSL . المنفذ الافتراضي لـ LDAP عبر SSL هو 636. كان استخدام LDAP عبر SSL شائعًا في الإصدار الثاني من LDAP (LDAPv2)، ولكنه لم يُعتمد رسميًا في أي مواصفات. وقد تم التخلي عن هذا الاستخدام مع LDAPv2، الذي أُوقف دعمه رسميًا في عام 2003. [ 13 ]

هيكل الدليل

يوفر البروتوكول واجهة مع الدلائل التي تتبع إصدار عام 1993 من نموذج X.500 :

  • يتكون المدخل من مجموعة من السمات.
  • لكل سمة اسم ( نوع السمة أو وصفها ) وقيمة واحدة أو أكثر. تُعرَّف السمات في مخطط (انظر أدناه).
  • لكل عنصر مُعرِّف فريد: اسمه المميز (DN). يتكون هذا الاسم من اسمه المميز النسبي (RDN)، المُستمد من سمة أو أكثر في العنصر، متبوعًا باسم العنصر الأصل المميز (DN). تخيّل أن DN هو مسار الملف الكامل ، وRDN هو اسم الملف النسبي في المجلد الأصل (على سبيل المثال، إذا /foo/bar/myfile.txtكان DN، فسيكون myfile.txtRDN).

قد يتغير اسم النظام المميز (DN) خلال فترة وجود المدخل، على سبيل المثال، عند نقل المدخلات داخل الشجرة. ولتحديد المدخلات بشكل موثوق ودقيق، يمكن توفير معرّف فريد عالمي (UUID) ضمن مجموعة السمات التشغيلية للمدخل .

يمكن أن يبدو الإدخال على هذا النحو عند تمثيله بتنسيق تبادل بيانات LDAP (LDIF)، وهو تنسيق نص عادي (على عكس بروتوكول ثنائي مثل LDAP نفسه):

dn : cn = John Doe , dc = example , dc = com cn : John Doe givenName : John sn : Doe telephoneNumber : +1 888 555 6789 telephoneNumber : +1 888 555 1232 mail : john@example.com manager : cn=Barbara Doe,dc=example,dc=com objectClass : inetOrgPerson objectClass : organizationalPerson objectClass : person objectClass : top

" dn" هو الاسم المميز للإدخال؛ وهو ليس سمة ولا جزءًا منه. " cn=John Doe" هو الاسم المميز النسبي (RDN) للإدخال، و" dc=example,dc=com" هو الاسم المميز (DN) للإدخال الأصل، حيث " dc" يشير إلى " مكون النطاق ". تُظهر الأسطر الأخرى سمات الإدخال. عادةً ما تكون أسماء السمات عبارة عن سلاسل تذكيرية، مثل " cn" للاسم الشائع، و" dc" لمكون النطاق، و" mail" لعنوان البريد الإلكتروني، و" sn" للقب العائلة. [ 14 ]

يحتفظ الخادم بشجرة فرعية تبدأ من مدخل محدد، مثل " dc=example,dc=com" وأبنائه. قد يحتفظ الخادم أيضًا بمراجع لخوادم أخرى، لذا فإن محاولة الوصول إلى " ou=department,dc=example,dc=com" قد تُعيد مرجعًا أو إشارة استمرار إلى خادم يحتفظ بهذا الجزء من شجرة الدليل. يمكن للعميل حينها الاتصال بالخادم الآخر. تدعم بعض الخوادم أيضًا التسلسل ، ما يعني أن الخادم يتصل بالخادم الآخر ويعيد النتائج إلى العميل.

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

العمليات

يضيف

تُضيف عملية الإضافة (ADD) مدخلاً جديداً إلى قاعدة بيانات خادم الدليل. [ 15 ] إذا كان الاسم المميز في طلب الإضافة موجوداً بالفعل في الدليل، فلن يُضيف الخادم مدخلاً مكرراً، بل سيُعيّن رمز النتيجة في نتيجة الإضافة إلى 68 عشرياً، "entryAlreadyExists". [ 16 ]

  • لن تقوم الخوادم المتوافقة مع LDAP أبدًا بإلغاء الإشارة إلى الاسم المميز المرسل في طلب الإضافة عند محاولة تحديد موقع الإدخال، أي أن الأسماء المميزة لا يتم إلغاء تسميتها أبدًا.
  • ستضمن الخوادم المتوافقة مع بروتوكول LDAP أن الاسم المميز وجميع السمات تتوافق مع معايير التسمية.
  • يجب ألا يكون المدخل المراد إضافته موجودًا، ويجب أن يكون المدخل الأعلى منه مباشرةً موجودًا.
dn : uid = user , ou = people , dc = example , dc = com changetype : add objectClass : top objectClass : person uid : user sn : last-name cn : common-name userPassword : password

في المثال أعلاه، uid=user,ou=people,dc=example,dc=comيجب ألا يكون موجوداً، ويجب ou=people,dc=example,dc=comأن يكون موجوداً.

ربط (مصادقة)

عند إنشاء جلسة LDAP، أي عند اتصال عميل LDAP بالخادم، يتم ضبط حالة مصادقة الجلسة على "مجهول". وتُحدد عملية BIND حالة المصادقة للجلسة.

يمكن لبروتوكولي Simple BIND وSASL PLAIN إرسال اسم المستخدم وكلمة المرور كنص عادي ، لذا يجب تشفير الاتصالات التي تستخدم أيًا منهما باستخدام بروتوكول أمان طبقة النقل (TLS). يتحقق الخادم عادةً من كلمة المرور مقابل userPassword السمة الموجودة في سجل الاسم. أما بروتوكول Anonymous BIND (مع اسم مستخدم وكلمة مرور فارغين) فيعيد الاتصال إلى حالة مجهولة.

يوفر بروتوكول SASL (طبقة المصادقة والأمان البسيطة) BIND خدمات المصادقة من خلال مجموعة واسعة من الآليات، مثل Kerberos أو شهادة العميل المرسلة مع TLS. [ 17 ]

يُحدد BIND أيضًا إصدار بروتوكول LDAP عن طريق إرسال رقم الإصدار كعدد صحيح. إذا طلب العميل إصدارًا لا يدعمه الخادم، فيجب على الخادم تعيين رمز النتيجة في استجابة BIND إلى رمز خطأ البروتوكول. عادةً ما يستخدم العملاء LDAPv3، وهو الإصدار الافتراضي في البروتوكول، ولكنه ليس كذلك دائمًا في مكتبات LDAP.

كان من الضروري أن تكون عملية الربط (BIND) هي العملية الأولى في الجلسة في بروتوكول LDAPv2، ولكنها لم تعد مطلوبة في بروتوكول LDAPv3. في بروتوكول LDAPv3، يؤدي كل طلب ربط ناجح إلى تغيير حالة المصادقة للجلسة، بينما يؤدي كل طلب ربط فاشل إلى إعادة ضبط حالة المصادقة للجلسة.

يمسح

لحذف إدخال، يقوم عميل LDAP بإرسال طلب حذف مُصاغ بشكل صحيح إلى الخادم. [ 18 ]

  • يجب أن يتضمن طلب الحذف الاسم المميز للإدخال المراد حذفه
  • يمكن أيضًا إرفاق عناصر التحكم في الطلب بطلب الحذف
  • لا تقوم الخوادم بإلغاء مرجعية الأسماء المستعارة عند معالجة طلب الحذف
  • لا يمكن حذف سوى المدخلات الطرفية (المدخلات التي لا تحتوي على مدخلات تابعة) عن طريق طلب الحذف. تدعم بعض الخوادم سمة تشغيلية hasSubordinatesتشير قيمتها إلى ما إذا كان للمدخل أي مدخلات تابعة، كما تدعم بعض الخوادم سمة تشغيلية أخرى numSubordinates[ 19 ] تشير إلى عدد المدخلات التابعة للمدخل الذي يحتوي على numSubordinatesالسمة.
  • تدعم بعض الخوادم التحكم في طلبات حذف الشجرة الفرعية، مما يسمح بحذف الاسم المميز (DN) وجميع الكائنات التابعة له، وذلك وفقًا لضوابط الوصول. وتخضع طلبات الحذف لضوابط الوصول، أي أن السماح لاتصال بحالة مصادقة معينة بحذف إدخال معين يخضع لآليات التحكم في الوصول الخاصة بالخادم.

ابحث وقارن

تُستخدم عملية البحث للبحث عن المدخلات وقراءتها. وتشمل معاييرها ما يلي:

الكائن الأساسي
اسم إدخال الكائن الأساسي (أو ربما الجذر) الذي سيتم إجراء البحث بالنسبة إليه.
نِطَاق
ما هي العناصر الموجودة أسفل الكائن الأساسي التي سيتم البحث فيها؟ يمكن أن يكون هذا BaseObject(البحث في الإدخال المسمى فقط، والذي يُستخدم عادةً لقراءة إدخال واحد)، أو singleLevel(الإدخالات الموجودة أسفل الاسم المميز الأساسي مباشرةً)، أو wholeSubtree(الشجرة الفرعية بأكملها بدءًا من الاسم المميز الأساسي).
فلتر
معايير اختيار العناصر ضمن النطاق. على سبيل المثال، (&(objectClass=person)(|(givenName=John)(mail=john*)))سيختار عامل التصفية "الأشخاص" (عناصر من فئة الكائن person) حيث تتطابق قواعد المطابقة مع قيم السمات، givenNameويحدد mailما إذا كانت هذه القيم تتطابق مع شرط عامل التصفية. تجدر الإشارة إلى أن الاعتقاد السائد بأن بيانات LDAP حساسة لحالة الأحرف هو اعتقاد خاطئ، بينما في الواقع، تحدد قواعد المطابقة وقواعد الترتيب عمليات المطابقة والمقارنات وعلاقات القيم النسبية. إذا تطلبت عوامل التصفية في المثال مطابقة حالة الأحرف في قيمة السمة، فيجب استخدام عامل تصفية قابل للتوسيع ، على سبيل المثال،(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))
أسماء مستعارة
ما إذا كان ينبغي اتباع المدخلات البديلة (المدخلات التي تشير إلى مدخلات أخرى) وكيفية ذلك،
صفات
ما هي السمات التي يجب إرجاعها في نتائج البحث؟
الحد الأقصى للحجم، الحد الزمني
الحد الأقصى لعدد النتائج المطلوب إرجاعها، والحد الأقصى للوقت المسموح به لإجراء البحث. مع ذلك، لا يمكن لهذه القيم تجاوز أي قيود يفرضها الخادم على حجم النتائج والوقت.
أنواع فقط
قم بإرجاع أنواع السمات فقط، وليس قيم السمات.

يُعيد الخادم النتائج المطابقة، وربما مراجع المتابعة. ويمكن إرجاعها بأي ترتيب. وستتضمن النتيجة النهائية رمز النتيجة.

تأخذ عملية المقارنة اسمًا مميزًا واسم سمة وقيمة سمة، وتتحقق مما إذا كان الإدخال المسمى يحتوي على تلك السمة بتلك القيمة.

يُعدِّل

تستخدم عملاء LDAP عملية MODIFY لطلب إجراء تغييرات على الإدخالات الموجودة من خادم LDAP. [ 20 ] ستفشل محاولات تعديل الإدخالات غير الموجودة. تخضع طلبات MODIFY لضوابط الوصول التي يطبقها الخادم.

تتطلب عملية التعديل تحديد الاسم المميز (DN) للإدخال، وتسلسل التغييرات. يجب أن يكون كل تغيير في التسلسل أحد ما يلي:

  • أضف (أضف قيمة جديدة، والتي يجب ألا تكون موجودة بالفعل في السمة)
  • حذف (حذف قيمة موجودة)
  • استبدال (استبدال قيمة موجودة بقيمة جديدة)

مثال على إضافة قيمة إلى سمة باستخدام ملف LDIF :

dn : dc = example , dc = com changetype : modify add : cn cn : the-new-cn-value-to-be-added -

لاستبدال قيمة سمة موجودة، استخدم الكلمة replaceالمفتاحية. إذا كانت السمة متعددة القيم، فيجب على العميل تحديد قيمة السمة المراد تحديثها.

لحذف سمة من سجل، استخدم الكلمة المفتاحية deleteومحدد نوع التغيير modify. إذا كانت السمة متعددة القيم، فيجب على العميل تحديد قيمة السمة المراد حذفها.

يوجد أيضًا امتداد "تعديل الزيادة" [ 21 ] الذي يسمح بزيادة قيمة السمة القابلة للزيادة بمقدار محدد. المثال التالي باستخدام LDIF يزيد employeeNumberبمقدار 5:

dn : uid = user.0 , ou = people , dc = example , dc = com changetype : modify increment : employeeNumber employeeNumber : 5-​

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

تعديل الاسم المميز

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

عملية التحديث عملية ذرية: ستشاهد العمليات الأخرى إما الإدخال الجديد أو القديم. من ناحية أخرى، لا يُعرّف بروتوكول LDAP معاملات العمليات المتعددة: إذا قرأتَ إدخالًا ثم عدّلته، فقد يكون عميل آخر قد حدّث الإدخال في هذه الأثناء. مع ذلك، قد تُطبّق الخوادم امتدادات [ 23 ] تدعم هذا.

عمليات موسعة

العملية الموسعة هي عملية عامة في بروتوكول LDAP تُتيح تعريف عمليات جديدة لم تكن جزءًا من مواصفات البروتوكول الأصلية. تُعدّ عملية بدء TLS إحدى أهم هذه التوسعات، ومن الأمثلة الأخرى عليها عملية الإلغاء وتعديل كلمة المرور.

StartTLS

تُنشئ عملية StartTLS بروتوكول أمان طبقة النقل (TLS) (المشتق من SSL ) على الاتصال. يوفر هذا البروتوكول سرية البيانات (لحمايتها من اطلاع أطراف ثالثة) وحماية سلامتها (لحمايتها من التلاعب). أثناء عملية التفاوض على TLS، يُرسل الخادم شهادة X.509 الخاصة به لإثبات هويته . كما يُمكن للعميل إرسال شهادة مماثلة لإثبات هويته. بعد ذلك، يُمكن للعميل استخدام SASL /EXTERNAL. باستخدام SASL/EXTERNAL، يطلب العميل من الخادم استخلاص هويته من بيانات اعتماد مُقدمة على مستوى أدنى (مثل TLS). مع أن الخادم نظريًا يُمكنه استخدام أي معلومات هوية مُحددة على أي مستوى أدنى، إلا أنه عادةً ما يستخدم معلومات الهوية المُحددة بواسطة TLS.

تدعم الخوادم أيضًا في كثير من الأحيان بروتوكول "LDAPS" غير القياسي ("Secure LDAP"، والمعروف باسم "LDAP عبر SSL") على منفذ منفصل، وهو 636 افتراضيًا. يختلف LDAPS عن LDAP في جانبين: 1) عند الاتصال، يقوم العميل والخادم بإنشاء TLS قبل نقل أي رسائل LDAP (بدون عملية StartTLS) و2) يجب إغلاق اتصال LDAPS عند إغلاق TLS.

بعض مكتبات عملاء "LDAPS" تقوم فقط بتشفير الاتصالات؛ فهي لا تتحقق من اسم المضيف مقابل الاسم الموجود في الشهادة المقدمة. [ 24 ]

يتخلى عن

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

فك الارتباط

تتخلى عملية فك الربط عن أي عمليات معلقة وتغلق الاتصال. ولا تتلقى أي استجابة. الاسم ذو أصل تاريخي، وليس عكس عملية الربط. [ 25 ]

يمكن للعملاء إنهاء الجلسة ببساطة عن طريق إغلاق الاتصال، ولكن يُنصح باستخدام أمر Unbind. [ 26 ] يسمح Unbind للخادم بإغلاق الاتصال بسلاسة وتحرير الموارد التي كان سيحتفظ بها لفترة من الوقت حتى يكتشف أن العميل قد قطع الاتصال. كما يُوجه الخادم لإلغاء العمليات التي يمكن إلغاؤها، وعدم إرسال استجابات للعمليات التي لا يمكن إلغاؤها. [ 27 ]

مخطط URI

يوجد مخطط معرف الموارد الموحد (URI) الخاص بـ LDAP ، والذي يدعمه العملاء بدرجات متفاوتة، وتعيده الخوادم في الإحالات ومراجع الاستمرارية (انظر RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions

معظم المكونات الموضحة أدناه اختيارية.

  • المضيف هو اسم المجال المؤهل بالكامل أو عنوان IP لخادم LDAP المراد البحث فيه.
  • المنفذ هو منفذ الشبكة (المنفذ الافتراضي 389) لخادم LDAP.
  • DN هو الاسم المميز الذي يجب استخدامه كأساس للبحث.
  • السمة عبارة عن قائمة سمات مفصولة بفواصل لاستردادها.
  • يحدد النطاق نطاق البحث ويمكن أن يكون "أساسي" (الافتراضي)، أو "واحد" أو "فرعي".
  • الفلتر هو فلتر بحث. على سبيل المثال، (objectClass=*)كما هو محدد في RFC 4515.
  • الامتدادات هي امتدادات لتنسيق عنوان URL الخاص بـ LDAP.

على سبيل المثال، ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=comيشير الرمز " " إلى جميع سمات المستخدم في سجل جون دو في ldap.example.com، بينما ldap:///dc=example,dc=com??sub?(givenName=John)يبحث الرمز " " عن السجل في الخادم الافتراضي (لاحظ الشرطات الثلاث، التي تحذف اسم المضيف، وعلامة الاستفهام المزدوجة، التي تحذف السمات). وكما هو الحال في عناوين URL الأخرى، يجب ترميز الأحرف الخاصة باستخدام النسبة المئوية .

يوجد ldapsنظام URI غير قياسي مماثل لبروتوكول LDAP عبر SSL. يجب عدم الخلط بينه وبين بروتوكول LDAP مع TLS، والذي يتم تحقيقه باستخدام عملية StartTLS وفقًا للنظام القياسي ldap.

مخطط

يتم التحكم في محتويات الإدخالات في الشجرة الفرعية بواسطة مخطط الدليل ، وهو مجموعة من التعريفات والقيود المتعلقة ببنية شجرة معلومات الدليل (DIT).

يُحدد مخطط خادم الدليل مجموعة من القواعد التي تحكم أنواع المعلومات التي يمكن للخادم تخزينها. ويتضمن هذا المخطط عددًا من العناصر، منها:

  • صيغ السمات - توفير معلومات حول نوع المعلومات التي يمكن تخزينها في السمة.
  • قواعد المطابقة - توفير معلومات حول كيفية إجراء المقارنات مع قيم السمات.
  • استخدامات قاعدة المطابقة - حدد أنواع السمات التي يمكن استخدامها بالاقتران مع قاعدة مطابقة معينة.
  • أنواع السمات - تحديد معرف الكائن (OID) ومجموعة من الأسماء التي قد تشير إلى سمة معينة، وربط تلك السمة بصيغة ومجموعة من قواعد المطابقة.
  • فئات الكائنات - قم بتعريف مجموعات مسماة من السمات وتصنيفها إلى مجموعات من السمات المطلوبة والاختيارية.
  • نماذج الأسماء - تحديد قواعد مجموعة السمات التي يجب تضمينها في RDN لإدخال ما.
  • قواعد المحتوى - تحديد قيود إضافية حول فئات الكائنات وسماتها التي يمكن استخدامها بالتزامن مع إدخال ما.
  • قاعدة الهيكل - تحديد القواعد التي تحكم أنواع الإدخالات الفرعية التي قد يحتوي عليها إدخال معين.

السمات هي العناصر المسؤولة عن تخزين المعلومات في الدليل، ويحدد المخطط القواعد المتعلقة بالسمات التي يمكن استخدامها في الإدخال، وأنواع القيم التي قد تحتويها تلك السمات، وكيف يمكن للعملاء التفاعل مع تلك القيم.

يمكن للعملاء التعرف على عناصر المخطط التي يدعمها الخادم من خلال استرداد إدخال فرعي مناسب للمخطط الفرعي.

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

على سبيل المثال، قد ينتمي إدخال يُمثل شخصًا إلى الفئتين "top" و"person". يتطلب الانتماء إلى فئة "person" احتواء الإدخال على السمتين "sn" و"cn"، ويسمح أيضًا باحتواء الإدخال على سمات أخرى مثل "userPassword" و"telephoneNumber". نظرًا لأن الإدخالات قد تحتوي على قيم متعددة من فئة ObjectClasses، فإن لكل إدخال مجموعة معقدة من مجموعات السمات الاختيارية والإلزامية المُشكّلة من اتحاد فئات الكائنات التي يُمثلها. يمكن توريث فئات ObjectClasses، ويمكن أن يحتوي إدخال واحد على قيم متعددة من فئة ObjectClasses تُحدد السمات المتاحة والمطلوبة للإدخال نفسه. يُشابه مخطط فئة ObjectClass تعريف الفئة ومثيلها في البرمجة كائنية التوجه ، حيث يُمثلان فئة LDAP وإدخال LDAP على التوالي.

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

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

الثغرات الأمنية

حقن LDAP

يُعدّ حقن LDAP هجومًا أمنيًا حاسوبيًا مشابهًا لحقن SQL ، ويمكن أن يحدث عندما يفشل تطبيق يستخدم LDAP في تنظيف مدخلات المستخدم بشكل صحيح. [ 28 ]

على سبيل المثال، لنفترض استعلام بحث في LDAP يسمح للمستخدم بالبحث عن الأشخاص باستخدام أسمائهم، وهي cnالسمة. قد يقوم مستخدم خبيث باستبدال اسم صحيح بالحرف *الذي يطابق أي كائن يحمل هذه cnالسمة. إذا كان التطبيق عرضة لهذا الهجوم، فقد يعرض سمات غير مصرح للمستخدم الباحث برؤيتها. [ 29 ]

يتم التخفيف من ثغرات حقن LDAP عن طريق تهريب المتغيرات. ويتم ذلك باستخدام دالتين ترميزيتين مختلفتين - إحداهما للأسماء المميزة والأخرى لسلاسل البحث - لأن كل منهما تسمح بأحرف خاصة مختلفة. وتأتي بعض أطر عمل الويب مزودة بخاصية تهريب مدمجة. [ 30 ]

هجمات الوسيط

على غرار أجزاء أخرى من بروتوكول TCP/IP، تم إنشاء بروتوكول LDAP في الأصل بدون تشفير. وهذا يجعله عرضةً لهجمات الوسيط ، حيث يعترض المهاجمون بيانات الاعتماد أثناء عملية الربط. ويمكن التخفيف من حدة هذه الهجمات من خلال اشتراط استخدام بروتوكول LDAPS أو StartTLS في كل عملية ربط تتضمن بيانات اعتماد. [ 31 ]

الاختلافات

يُترك جزء كبير من تشغيل الخادم للمنفذ أو المسؤول ليقرره. وبناءً على ذلك، يمكن إعداد الخوادم لدعم مجموعة واسعة من السيناريوهات.

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

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

نماذج بيانات أخرى

مع ازدياد شعبية بروتوكول LDAP، بدأ الموردون بتوفيره كبروتوكول وصول إلى خدمات أخرى. ثم يقوم التطبيق بإعادة صياغة البيانات لمحاكاة نموذج LDAP/X.500، ولكن مدى الالتزام بهذا النموذج يختلف. على سبيل المثال، توجد برامج للوصول إلى قواعد بيانات SQL عبر LDAP، على الرغم من أن LDAP لا يدعم ذلك بشكل مباشر. [ 32 ] قد تدعم خوادم X.500 بروتوكول LDAP أيضًا.

وبالمثل، تُنقل البيانات المخزنة سابقًا في أنواع أخرى من مخازن البيانات أحيانًا إلى أدلة LDAP. على سبيل المثال، يمكن تخزين معلومات مستخدمي ومجموعات أنظمة Unix في LDAP والوصول إليها عبر وحدات PAM و NSS . غالبًا ما تستخدم خدمات أخرى LDAP للمصادقة و/أو التخويل (أي تحديد الإجراءات التي يمكن لمستخدم مصادق عليه مسبقًا القيام بها على أي خدمة). على سبيل المثال، في Active Directory، يُستخدم Kerberos في خطوة المصادقة، بينما يُستخدم LDAP في خطوة التخويل.

ومن الأمثلة على نموذج البيانات هذا مخطط GLUE، [ 33 ] والذي يستخدم في نظام معلومات موزع قائم على LDAP والذي يمكّن المستخدمين والتطبيقات والخدمات من اكتشاف الخدمات الموجودة في بنية الشبكة ومعلومات إضافية حول هيكلها وحالتها.

الاستخدام

قد يُحيل خادم LDAP الطلبات التي لا يستطيع تلبيتها بنفسه إلى خوادم أخرى. يتطلب هذا بنية تسمية لمدخلات LDAP، بحيث يُمكن العثور على خادم يحمل اسمًا مميزًا (DN) مُحددًا، وهو مفهوم مُعرّف في دليل X.500 ويُستخدم أيضًا في LDAP. وهناك طريقة أخرى لتحديد مواقع خوادم LDAP للمؤسسة، وهي سجل خادم DNS (SRV).

قد تستخدم مؤسسةٌ ذات نطاق example.org اسمَ LDAP الرئيسي dc=example, dc=org(حيث يشير dc إلى مُكوِّن النطاق). إذا كان اسم خادم LDAP هو ldap.example.org أيضًا، فسيصبح عنوان URL الرئيسي لـ LDAP الخاص بالمؤسسة هو ldap://ldap.example.org/dc=example,dc=org.

يُستخدم نمطان شائعان للتسمية في كل من X.500 [2008] وLDAPv3. وهما موثقان في مواصفات الاتحاد الدولي للاتصالات (ITU) ووثائق IETF RFC. يأخذ النموذج الأصلي الكائن الأعلى مستوى ككائن الدولة، مثل c=US. c=FRيستخدم نموذج مكون المجال النموذج الموصوف أعلاه. مثال على التسمية القائمة على الدولة هو l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR، أو في الولايات المتحدة: cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.

انظر أيضاً

مراجع

  1. ↑ زيلينغا، كورت (يونيو 2006). بروتوكول الوصول إلى الدليل الخفيف (LDAP): خارطة طريق المواصفات الفنية (تقرير). فريق عمل هندسة الإنترنت.
  2. ↑ "خدمات الدليل LDAP" . Oracle.com . تم الاطلاع عليه بتاريخ 2014-04-04 .
  3. ↑ "مقدمة إلى خدمات دليل OpenLDAP" . OpenLDAP . تم الاطلاع عليه في 1 فبراير 2016 .
  4. ↑ ج. سيرميرشيم (يونيو 2006). بروتوكول الوصول إلى الدليل الخفيف (LDAP): البروتوكول . مجموعة عمل الشبكة. doi : 10.17487/RFC4511 . RFC 4511 .معيار مقترح. يلغي المعايير RFC 3771 و 2830 و 2251 . يمكن ربط عمليات البروتوكول الأساسية المحددة في هذه الوثيقة بمجموعة فرعية من خدمة تجريد الدليل X.500 (1993) [X.511]. مع ذلك، لا يوجد تطابق تام بين عمليات LDAP وعمليات بروتوكول الوصول إلى الدليل (DAP) الخاص بـ X.500. 
  5. ↑ "ما هي مصادقة بروتوكول الوصول إلى الدليل الخفيف (LDAP)؟" . ريد هات . 3 يونيو 2022.
  6. ↑ "LDAP - بروتوكول الوصول إلى الدليل الخفيف" . Webopedia.com. 4 ديسمبر 1996. تم الاسترجاع في 5 أبريل 2014 .
  7. ↑ زيلينغا، كورت (يونيو 2006). بروتوكول الوصول إلى الدليل الخفيف (LDAP): نماذج معلومات الدليل (تقرير). فريق عمل هندسة الإنترنت.
  8. ↑ سيبراس، أنيو (يونيو 2006). بروتوكول الوصول إلى الدليل الخفيف (LDAP): مخطط لتطبيقات المستخدم (تقرير). فريق عمل هندسة الإنترنت.
  9. ↑ سلسلة X.500 - توصيات الاتحاد الدولي للاتصالات من X.500 إلى X.521
  10. ↑ هاوز، تيم. "بروتوكول الوصول إلى الدليل الخفيف: X.500 Lite" (ملف PDF) . تم الاطلاع عليه بتاريخ 26 ديسمبر 2012 .
  11. ↑ "تاريخ ما قبل بروتوكول LDAP" . مجلة سايبر ماترز . 9 أبريل 2013. تم الاطلاع عليه في 5 أكتوبر 2014 .
  12. ↑ "سجل اسم الخدمة ورقم منفذ بروتوكول النقل" . هيئة الأرقام المخصصة للإنترنت (IANA) . تم الاطلاع عليه بتاريخ 24 مارس 2021 .
  13. ↑ RFC3494
  14. ↑ تستند هذه المقالة إلى مواد مأخوذة من Lightweight+Directory+Access+Protocol في قاموس الحوسبة المجاني على الإنترنت قبل 1 نوفمبر 2008 وتم دمجها بموجب شروط "إعادة الترخيص" الخاصة بـ GFDL ، الإصدار 1.3 أو أحدث.
  15. ↑ أضف قسمًا من RFC4511
  16. ↑ رموز نتائج LDAP
  17. ↑ آليات SASL في IANA
  18. ↑ RFC4511: طلب الحذف
  19. ↑ مسودة بورهام (عدد المرؤوسين)
  20. ↑ تعديل قسم من RFC4511
  21. ↑ زيلينغا، ك. امتداد التعديل والزيادة في بروتوكول LDAP . IETF . doi : 10.17487/RFC4525 . RFC 4525 .
  22. ↑ زيلينغا، ك. ضوابط إدخال القراءة لبروتوكول الوصول إلى الدليل الخفيف (LDAP) . IETF . doi : 10.17487/RFC4527 . RFC 4527 .
  23. ↑ مسودة معاملات LDAP على الإنترنت draft-zeilenga-ldap-txn-15.txt
  24. ↑ تنبيه أمني من شيبوليث 20120227
  25. ↑ Tools.ietf.org
  26. ↑ Tools.ietf.org
  27. ↑ Tools.ietf.org
  28. ↑ "وصف حقن LDAP" . OWASP . مؤسسة OWASP.
  29. ↑ عبد اللهي، علي (2025). دليل المبتدئين لاختبار اختراق تطبيقات الويب . وايلي. ISBN 9781394295609.
  30. ↑ ورقة غش للوقاية من حقن LDAP (تقرير). مؤسسة OWASP.
  31. ↑ جونسون، ريتشارد (2025). بنية وتنفيذ LDAP: مرجع نهائي للمطورين والمهندسين . دار نشر HiTeX.
  32. ↑ Openldap.org
  33. ↑ منتدى الشبكة المفتوحة  : الصفحة الرئيسية للمشروع

مصادر

للمزيد من القراءة