الخلاصة

  • فصل RFC 3062 تغيير كلمة المرور عن افتراضين: أن تُمثَّل هوية المستخدم بصيغة DN، وأن تُخزَّن كلمة المرور في سجل LDAP.
  • لا يجوز للخادم إعلان النجاح إلا بعد تغيير كلمة المرور، وعليه إبقاؤها كما هي عند الفشل. لكن الرد لا يثبت نجاح تسجيل الدخول لاحقاً ولا وصول التغيير إلى كل الخدمات الخارجية.

حين لا يكون هناك سجلٌّ لتعديله

تغيّر عملية Modify في LDAP سمات سجلٍّ محدد في الدليل. ويناسب ذلك حالة مستخدم له اسم مميّز (DN) وكلمة مرور محفوظة، مثلاً، في السمة userPassword. لكن ربط LDAP بخدمات مصادقة خارجية جعل هذا الافتراض غير مضمون: فقد تكون الهوية ليست DN، وقد تُحفَظ كلمة المرور خارج الدليل. لذلك لم يعد تعديل السجل يعني بالضرورة تغيير السر الذي سيُستخدم عند الدخول.

نشر Kurt Zeilenga في فبراير 2001 RFC 3062 ليقدم عملية مختلفة بدلاً من معاملة كل كلمة مرور كسمة. عرّف RFC عملية Password Modify الموسّعة بالمعرّف 1.3.6.1.4.1.4203.1.11.1. ويمكن أن يتضمن الطلب الحقول userIdentity وoldPasswd وnewPasswd، وكلها اختيارية. يحدد البروتوكول كيفية طلب التغيير، لا مخططاً موحّداً لمكان حفظ كلمة المرور.

هوية الجلسة أو هوية تُرسل صراحةً

إذا وُجد الحقل userIdentity فهو سلسلة بايتات قد تكون DN وقد لا تكون. وإذا غاب، ينطبق الطلب على المستخدم المرتبط بجلسة LDAP الحالية. بذلك يستطيع العميل الاعتماد على الهوية التي أُثبتت في الجلسة، أو إرسال تمثيل آخر يعرف الخادم كيف يفسّره. ولا يكشف أي من الخيارين مكان تخزين كلمة المرور أو كيفية ربط الخادم تلك الهوية بالاعتماد الذي يستطيع تغييره.

هذا هو التحول المعماري: يوفر LDAP حداً مشتركاً للطلب، من دون اشتراط أن تكون كلمة المرور سمة في الدليل. فقد يستخدم الخادم سمةً، أو مخزناً آخر، أو خدمة مصادقة خارجية. يسمح RFC 3062 بهذه الترتيبات، لكنه لا يوثق تنفيذاً بعينه ولا يضمن أن تحل جميع الخوادم الهويات بالطريقة نفسها.

نجاح محدود المعنى

لا يجوز للخادم إرجاع النجاح إلا بعد أن يغيّر كلمة مرور المستخدم فعلياً. وفي غير ذلك عليه عدم تعديلها وإرجاع نتيجة غير ناجحة. كما يجب ألا يغيّرها إذا كانت كلمة المرور القديمة المقدمة خاطئة. وإذا لم يرسل العميل newPasswd، فعلى الخادم إما توليد كلمة مرور وإعادتها في genPasswd عند النجاح، أو إخفاق العملية. وعند غياب oldPasswd، يجوز للخادم تطبيق سياسة أخرى لتقرير السماح؛ كما يجوز للمسؤولين تقييد العملية.

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

اكتشاف القدرة يتغير مع سياق الجلسة

يوصي RFC 3062 بأن يعلن الخادم عن المعرّف في السمة supportedExtension ضمن Root DSE، وأن يتحقق العميل من ذلك قبل الإرسال. لكن يجوز للخادم أن يحصر الإعلان في حالة تخويل العميل و/أو قيام الحماية الأمنية اللازمة. لذا قد يتوقف اكتشاف القدرة على سياق الجلسة. وغياب المعرّف من ردٍّ واحد يصف ذلك السياق، ولا يثبت بالضرورة غياب الدعم عن كل مستخدم أو مسار اتصال.

لا توفر العملية نفسها السرية أو سلامة البيانات. يحظر RFC 3062 استخدامها من دون مصادقة، ويشترط حماية السرية مثل TLS. فقد يحمل الطلب كلمتي المرور القديمة والجديدة، وقد يعيد الرد كلمة مرور ولّدها الخادم. ولا جدوى من الوصول إلى مخزن اعتماد بعيد إذا كان المسار نفسه يكشف السر.

عرّف RFC 3062 العملية الموسّعة ضمن إطار LDAPv3 في RFC 2251. ثم حلّ RFC 4511 محل RFC 2251 وشرح الإطار العام لرسائل ExtendedRequest وExtendedResponse. يوضح هذا التطور مكان الامتدادات في البروتوكول، لكنه لا يثبت أن خادماً بعينه نفّذ Password Modify أو أن تنفيذين يتصرفان على نحو متطابق.

يسجل RFC Editor خطأين مصححين ومعتمدين: يستبدل التصويب 340 كلمة “where” بـ “were” في الخلفية التاريخية، ويضيف التصويب 4899 فواصل إلى تسلسل حقول ASN.1. يجعل التصويب الثاني الصياغة الرسمية أوضح، لكنه لا يغير الحدود بين شكل الهوية ومكان حفظ كلمة المرور.

أصبح بوسع LDAP، بفضل RFC 3062، نقل طلب تغيير كلمة المرور من دون افتراض وجودها كسمة في سجل أو تمثيل المستخدم كـ DN. ومع ذلك بقي على الخادم ربط الطلب بالجهة التي تملك سلطة فعلية على الاعتماد. ولا يصف رد البروتوكول سوى النتيجة الموعودة عند ذلك الحد.

المصادر