شرح SPN وsetspn بالعربي: ليش الخدمة تفتح باسم وتفشل باسم ثاني؟

تدخل على تطبيق التدريب باسم app01.lab.test ويشتغل، ثم تستخدم الاسم المختصر أو الاسم البديل ويختلف تسجيل الدخول. الاتصال موجود، والحساب نفسه، والخادم نفسه تقريبًا؛ لذلك تبدأ تشك في كلمة المرور أو المتصفح. لكن فيه سؤال أهم: هل الاسم الذي استخدمته يشير إلى هوية الخدمة الصحيحة داخل Active Directory؟ هنا يظهر دور Service Principal Name، أو SPN.

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

SPN يعرّف خدمة، مو مجرد جهاز

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

تخيّل دليلًا داخليًا يقول إن الخدمة المسماة HTTP/app01.lab.test مرتبطة بحساب معين في الدومين. العميل لا يحتاج أن يعرف كلمة مرور ذلك الحساب أو اسمه قبل كل اتصال؛ يحتاج أن تكون العلاقة بين اسم الخدمة والحساب صحيحة. لهذا يظهر SPN في نقاش Kerberos، خصوصًا عند التطبيقات التي تستخدم مصادقة ويندوز.

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

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

اقرأ الاسم قطعة قطعة بدل ما تحفظ شكله

غالبًا تشوف مثالًا مثل HTTP/app01.lab.test، أو cifs/files01.lab.test. الجزء الأول يحدد فئة الخدمة، والجزء الآخر يتصل باسم الجهة التي يتوقع العميل الوصول إليها. بعض أنواع الخدمات تستخدم صيغًا تتضمن منفذًا أو جزءًا إضافيًا. لا تعمم شكل مثال واحد على كل البرامج؛ بناء الاسم يتأثر بنوع الخدمة وكيفية تكوين العميل والخادم.

وجود HTTP في الاسم لا يكفي وحده لتعرف هل اتصال المستخدم مشفر عبر HTTPS، ولا يثبت أن الخدمة تعمل على منفذ بعينه. هذه فئة خدمة في سياق المصادقة، بينما تشفير النقل وإعدادات الاستماع لها أدلتها المستقلة. بالمثل، ظهور cifs ليس قائمة بمجلدات المشاركة ولا وصفًا لحقوق القراءة والكتابة عليها.

في دفتر اللاب اكتب ثلاثة أسطر منفصلة: اسم الاتصال الذي أدخلته، والخدمة التي قصدتها، وSPN المتوقع وفق توثيق تلك الخدمة. إذا اتصلت بالاسم app.lab.test بينما تبحث فقط عن app01.lab.test، فأنت تقارن قيمتين مختلفتين. قد تشير القيمتان إلى الجهاز نفسه عبر DNS، لكن هذا وحده لا يحسم أن إعداد المصادقة يغطيهما بالطريقة نفسها.

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

جهّز تجربة صغيرة لها حدود واضحة

خلنا نفترض لابًا اسمه lab.test، وفيه جهاز تطبيق app01 وحساب تدريب للخدمة اسمه svc-web. نريد قراءة تسجيلات مرتبطة بتطبيق واحد، لا جرد الغابة كلها. قبل تشغيل أي أمر، سجّل أن app01 وsvc-web داخل النطاق المسموح، وأن حساب التدريب مخول بقراءة البيانات المطلوبة. وجود الأداة على جهازك لا يوسع نطاق التصريح.

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

أداة setspn لها وظائف قراءة ووظائف تعديل. توثيق مايكروسوفت يذكر تشغيلها من موجه أوامر مرتفع الصلاحية ومتطلبات توفرها. اتبع تجهيز بيئة التدريب أو اطلب من مسؤولها تنفيذ القراءة المحددة؛ لا تجعل عدم وجود الأداة سببًا للحصول على حساب أوسع مما تحتاجه. ارتفاع صلاحية الموجه المحلي ليس معناه امتلاك حقوق كتابة في الدليل.

قبل التجربة، افتح المساعدة باستخدام setspn /? وسجل أي اختلاف عن المثال الذي تقرؤه. مقصدنا أن تتعرف على الخيارات التي ستستخدمها وتفرق القراءة عن التعديل، لا أن تنسخ سلسلة أوامر من مصدر غير معروف. حتى في اللاب، عادة قراءة المساعدة تمنع خطأ بسيطًا من تحويل ملاحظة إلى تغيير غير مقصود.

ابدأ من الحساب المعروف باستخدام ‎-L

إذا أكد مالك التطبيق أن خدمة التدريب تعمل تحت svc-web، ابدأ بسؤال محدد: ما الأسماء المسجلة على هذا الحساب؟ المثال داخل لابنا:

setspn -U -L svc-web

الخيار -U يوضح أن المقصود حساب مستخدم، و-L يعرض التسجيلات المرتبطة بالحساب. لا تستنتج من اسم svc-web وحده أنه فعلًا حساب التشغيل الحالي؛ نحن بدأنا من معلومة تحققنا منها لدى مالك الخدمة. أسماء الحسابات قد تبقى بعد نقل تطبيق أو تغيير وظيفته.

اقرأ المخرجات على أنها قائمة ارتباطات في الدليل. إذا ظهر HTTP/app01.lab.test، دوّن أن هذا الاسم موجود على الكائن الذي استعلمت عنه. لا تضف تلقائيًا أن التطبيق يستمع الآن أو أن العميل استخدم هذا الاسم أو أن دخول المستخدم نجح. كل واحدة من تلك الجمل تحتاج مشاهدة مختلفة.

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

ولقراءة حساب جهاز التدريب بصورة صريحة يمكن استخدام setspn -C -L app01. المقارنة بين الحسابين مفيدة إذا كانت هوية التشغيل غير محسومة، لكنها لا تمنحك حق تجربة كل حساب في البيئة. اختَر الحساب الذي له علاقة بالسؤال، ثم اسأل عن تفسير الاختلاف بدل جمع أسماء ما تحتاجها.

ابحث عن الاسم المطلوب باستخدام ‎-Q

بعد قراءة الحساب، اعكس السؤال: أين يسجل الاسم الذي يفترض أن العميل يطلبه؟ مثال قراءة محدد داخل الدومين التدريبي:

setspn -Q HTTP/app01.lab.test

هنا أنت لا تسأل عن كل ما يخص svc-web، بل عن SPN بعينه. هذا الفرق مهم. قد تكون قائمة الحساب تبدو منطقية، لكن الاسم الذي يستخدمه المستخدم مختلف. وقد تجد الاسم على حساب لم يكن ضمن توقعك أصلًا. احتفظ بالمخرج الذي يحدد الكائن المرتبط بدل الاكتفاء بعبارة «لقيته».

إذا كان الاسم البديل المصرح به app.lab.test، نفذ استعلامًا منفصلًا عنه: setspn -Q HTTP/app.lab.test. لا تستبدل الاستعلام المحدد بنمط واسع يبحث في كل الخدمات إلا إذا كان ذلك جزءًا من خطة الجرد المعتمدة. البحث الصغير أسهل في التفسير والمراجعة، ويقلل احتمال تسريب تفاصيل غير لازمة إلى ملاحظاتك.

النتيجة الفارغة تعني أن القراءة لم تجد تسجيلًا مطابقًا في نطاق بحثها وظروفها. هذه صياغة أدق من «ما فيه SPN في المؤسسة». الدومين والغابة ومسار الاستعلام وحدود الوصول تؤثر في معنى النتيجة. الخيارات -T و-F توسع أو تحدد سياق البحث، ولذلك يجب تحديدها بموافقة النطاق لا إضافتها تلقائيًا لأن أول نتيجة لم تعجبك.

خل مقارنة الاسم الأصلي والبديل مكتوبة في سجل واحد: الاسم، وقت البحث، سياق الدومين، والحساب الذي ظهر. بعدها يصبح النقاش مع مسؤول التطبيق محددًا. بدل السؤال العام «ليش Kerberos خربان؟»، تسأل «هل العميل يتوقع هذا الاسم البديل، وهل حساب الخدمة الحالي هو صاحب تسجيله؟».

DNS الصحيح لا يكفي لحسم المصادقة

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

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

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

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

التسجيل المكرر يحتاج مراجعة، لا حذفًا سريعًا

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

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

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

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

وجود SPN مو ثغرة تلقائيًا

حين تبدأ دراسة Active Directory وCRTP أو CRTE، تشوف SPN مرتبطًا بنقاشات أمن حسابات الخدمات. هذا الربط مفيد، لكن اختصاره إلى «كل حساب عنده SPN ضعيف» يضيع الفكرة. تسجيل اسم خدمة وظيفة طبيعية في بيئات Kerberos، وقد يكون ضروريًا لتطبيق مهم. تقييم الخطر يتطلب معرفة حماية الحساب وصلاحياته وإدارة أسراره وسياق الخدمة.

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

ولا تعتبر اسم svc-admin دليلًا على حقوق إدارية، كما لا تعتبر اسم svc-readonly ضمانًا على محدودية الصلاحيات. الاسم وصف اختاره أحدهم؛ الحقوق الفعلية تحددها العضوية والتفويضات وإعدادات الخدمة. إذا لم تراجع هذه الجوانب، اكتب أن تقييم الصلاحيات لم يشمله الاختبار بدل سد الفراغ بالتخمين.

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

تمرين يخليك تربط الأدلة بدل تجمع أوامر

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

نفذ قراءة -L على الحساب الصحيح، ثم قراءة -Q لكل اسم متوقع بصورة منفصلة. احفظ النتائج في سجل اللاب مع الوقت وسياق الدومين. جرّب الوصول المعتاد الذي يصرح به سيناريو التدريب، وسجّل هل المشكلة في الوصول إلى التطبيق أم في تسجيل الدخول أم بعد الدخول إلى وظيفة محددة. لا تضع كل النتائج تحت عنوان «رفض» واحد.

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

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

وش تكتب في التقرير، ووين تكمل بعدها؟

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

لا ترفق عشر صفحات تسجيلات لتطبيق واحد، ولا تقترح إصلاحًا عامًا من نوع «أعد ضبط SPN لكل الأجهزة». اربط التوصية بالاسم والحساب اللذين يحتاجان مراجعة لدى المسؤول، ثم اطلب اختبار المصادقة بعد أي تغيير معتمد. إذا كان الأثر لم يثبت، قل ذلك بوضوح. دقة الحدود تزيد قيمة الملاحظة، ما تنقصها.

للربط بين هذا الشرح وقراءة جلسة Kerberos، راجع مقال Rubeus triage وklist في المجتمع:
https://courses.cyberpts.com/community/76/shrh-rubeus-triage-wklist-aqra-tthakr-kerberos-wafhm-jlsh-hsabk-fy-allab

ومرجعا القراءة الأساسيان هما توثيق setspn وتعريف Service Principal Names من مايكروسوفت:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setspn
https://learn.microsoft.com/en-us/windows/win32/ad/service-principal-names

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