تغيير حساب الخدمة وSPN: كيف تنقل تطبيقًا بدون مشاكل Kerberos أو صلاحيات تبقى للحساب القديم؟

غيّرت حساب تشغيل التطبيق، والخدمة اشتغلت، لكن بعض المستخدمين صاروا يشوفون خطأ مصادقة. غيرهم يدخل عادي. بعد البحث تكتشف أن اسم الخدمة في Active Directory ما زال مربوطًا بالحساب السابق. هنا الموضوع مب مجرد كلمة مرور جديدة؛ عندك علاقة بين اسم يصل له المستخدم، وهوية تشغل الخدمة، وتسجيل SPN الذي يعتمد عليه Kerberos.
خلنا نمسك دورة حياة حساب الخدمة من زاوية تشغيلية وأمنية: كيف توثق الحالة قبل النقل، وتقرأ التسجيل الحالي، وتفرق بين SPN مكرر وSPN موجود على الحساب الخطأ، وتثبت أن الهوية القديمة ما عاد لها دور مخفي. الأمثلة في مختبر lab.test مصرح، والأوامر المعروضة للاستعلام فقط.

المستخدم يطلب خدمة، لكن الدليل يربطها بهوية

Service Principal Name اسم يربط خدمة بهوية داخل الدليل. من أمثلته اسم HTTP لتطبيق ويب، أو MSSQLSvc لخدمة قاعدة بيانات وفق شكل التسجيل المناسب لها. الفكرة أن اسم الوجهة الذي يستخدمه العميل يدخل في تحديد الخدمة المقصودة، ثم يُبحث عن الهوية المرتبطة به. لا تخلط اسم الجهاز واسم التطبيق واسم حساب التشغيل؛ قد تتشابه، لكنها تمثل أشياء مختلفة.
لو المستخدم يفتح reports.lab.test والتطبيق يعمل على WEB01 بهوية svc_reports، تحتاج فهم هذا الربط في تصميم التطبيق الفعلي. وجود سجل DNS صحيح لا يضمن أن SPN صحيح. DNS يساعد العميل يصل للوجهة الشبكية، بينما تسجيل الخدمة يتعلق بالمصادقة. كذلك نجاح اتصال TCP لا يثبت أن المستخدم صودق عبر Kerberos بالطريقة المتوقعة.
توثيق Microsoft لأداة setspn يوضح أنها تقرأ وتعدل وتحذف خاصية SPN لحساب الخدمة. في هذه المراجعة نستخدم خيارات القراءة فقط. الاستعلام عن اسم محدد يكشف أين سُجل، وقراءة قائمة حساب معين تكشف الأسماء المرتبطة به. كلاهما يجيب سؤالًا مختلفًا؛ لا تستبدل واحدًا بالآخر وتفترض أنك غطيت كل الحالة.
النقطة المهمة أن تغيير اسم تسجيل الدخول للخدمة أو بيانات اعتمادها لا يعني تلقائيًا أن كل علاقات التطبيق انتقلت. توجد إعدادات تطبيق، وأذونات ملفات وقاعدة بيانات، وتفويض محتمل، وتسجيلات خدمة. لذلك نحتاج قائمة ارتباطات قبل النقل، وليس اختبارًا واحدًا يقول إن العملية بدأت بدون خطأ.

جهز خريطة صغيرة قبل أي تغيير

قبل النقل اكتب أربعة أشياء: الأسماء التي يستعملها العملاء، الأجهزة التي تقدم الخدمة، الهوية التي تشغل كل مكون، والجهة المالكة لهذه الإعدادات. مثالنا تطبيق تقارير له اسم reports.lab.test، عقدتان WEB01 وWEB02، حساب قديم svc_reports_old، وقاعدة بيانات SQL01. هذه أسماء تعليمية وليست جردًا لشركة فعلية.
اسأل هل العملاء يدخلون بالاسم المستعار أو باسم الخادم المباشر أو الاثنين. قد يختبر فريق التشغيل رابطًا داخليًا مختلفًا عن رابط المستخدمين ثم يعلن نجاح التغيير. عندما تختلف الأسماء، قد تختلف طريقة المصادقة والتسجيل المطلوب. اجمع الاسم من إعداد العميل أو من سيناريو متفق عليه، لا من توقعك وحده.
وثق الخدمات والمهام المجدولة التي تستخدم الحساب القديم. لا تفترض أن اسم الحساب يحدد تطبيقًا واحدًا؛ الحسابات التاريخية كثيرًا ما تتوسع استخداماتها. من ناحية مراجعة، تحتاج دليلًا على الأماكن المعروفة، مع تصريح واضح عن حدود الجرد. إذا قرأت خادمين فقط، لا تكتب أن الحساب غير مستخدم في البيئة كاملة.
أضف اعتماديات التشغيل: عضوية المجموعات، الوصول إلى المشاركات، صلاحيات قاعدة البيانات، وأي تفويض مقيد يعتمد عليه التطبيق. ليست كلها SPN، لكنها تؤثر في تجربة النقل. هذه الخريطة تمنع إصلاح التسجيل ثم اكتشاف أن الحساب الجديد لا يقرأ ملف إعداد أو لا يصل إلى قاعدة البيانات، فيرجع الفريق للحساب القديم بلا تنظيف.

ثلاثة استعلامات، وكل واحد له سؤال

في مختبر Windows مجهز بالأداة، قراءة تسجيلات حساب محدد تكون مثل: setspn -L LABsvc_reports_old. هنا تسأل: ما أسماء الخدمات المسجلة على هذا الحساب؟ احتفظ بالقائمة كما هي مع وقت القراءة. لا تحذف اسمًا لأن شكله غريب؛ قد يكون له عميل أو مكون لم يظهر بعد في خريطتك.
الاستعلام المحدد مثل: setspn -Q HTTP/reports.lab.test يسأل: أين يوجد هذا الاسم داخل نطاق البحث الافتراضي؟ يساعدك تربط الاسم الذي يستخدمه العميل بالحساب المسجل. إذا ظهرت هوية غير متوقعة، لا تقفز مباشرة إلى التعديل. قارنها مع هوية تشغيل التطبيق الحالية ومع تصميم النشر متعدد العقد.
أما setspn -X فيبحث عن التسجيلات المكررة ضمن نطاقه. توضح Microsoft خيار -F لتوسيع الاستعلام إلى مستوى الغابة، لكن لا تستخدمه تلقائيًا إذا كان تصريحك يغطي دومينًا محددًا. البحث الأوسع له تكلفة وحدود بيانات مختلفة. اختر النطاق بناء على المشكلة والتفويض، وسجل ما بحثت فيه كي لا تبالغ في معنى نتيجة نظيفة.
هذه أوامر تشخيص، وليست خطة نقل. لا يوجد هنا أمر إضافة أو حذف أو إعادة ضبط. وجود أداة قادرة على التعديل لا يعني أن كل خياراتها مناسبة للفحص. اقرأ مخرجات الاستعلام، واطلب من صاحب التطبيق تأكيد الهوية المعتمدة، ثم ضع طلب تغيير منفصل يراجعه فريق التشغيل وفق بيئته.

SPN مكرر وSPN على الحساب الخطأ: فرق يستاهل تنتبه له

التكرار يعني أن الاسم المقصود يظهر على أكثر من كائن داخل نطاق الفحص. أما التسجيل على الحساب الخطأ فيمكن أن يكون فريدًا تمامًا. لهذا نتيجة فحص التكرار النظيفة لا تثبت صحة الربط. قد يكون HTTP/reports.lab.test مسجلًا مرة واحدة، لكن على svc_reports_old بينما التطبيق يعمل الآن بحساب مختلف.
في المقابل، تعدد الأسماء على الحساب نفسه ليس تكرارًا بذاته. الخدمة قد تقدم أسماء معتمدة متعددة، وكل واحد له سبب. لا تقارن عدد سطور SPN بعدد العمليات وتتوقع تطابقًا مباشرًا. الأهم هو مطابقة الاسم الذي يطلبه العميل مع الهوية الفعلية والتصميم المعتمد.
تصف Microsoft في مثال SQL حالة SPN صريح موجود على حساب لا تستخدمه الخدمة، وتقترح الاستعلام عن الاسم لمعرفة موضعه. هذه زاوية تشخيصية مفيدة: ابدأ من اسم الاتصال الفعلي، ثم ابحث عن التسجيل، ثم قارن بحساب الخدمة. لا تبدأ بتغيير الأذونات العامة لأن رسالة المصادقة واسعة أو لأن مستخدمًا اقترح منح الحساب الجديد عضوية قوية.
اكتب الحالات منفصلة في ورقة العمل: اسم غير موجود في القراءة، اسم مكرر، اسم فريد على هوية غير متوقعة، واسم مطابق يحتاج متابعة طبقة أخرى. الفصل يوفر وقتًا؛ لأن كل حالة لها مسار تحقق مختلف. وضعها جميعًا تحت «Kerberos لا يعمل» يجعلك تتنقل بين DNS والوقت والصلاحيات دون معرفة أي فرضية تختبر.

نقل الهوية ليس نقلًا تلقائيًا لكل الصلاحيات

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

اختبار النقل: افصل هوية المستخدم عن هوية الخدمة

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

الحساب القديم: لا تترك وراءك بابًا بلا صاحب

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

كيف تكتب نتيجة مفيدة لفريق التطبيق؟

لو وجدت اسمًا على الحساب الخطأ، اكتب الاسم والهوية الحالية والمتوقعة والدليل التشغيلي الذي ربطهما. مثال تعليمي: «اسم HTTP/reports.lab.test ما زال مسجلًا على حساب سابق، بينما إعداد الخدمة الحالي يشير إلى الهوية الجديدة؛ يحتاج الربط مراجعة ضمن خطة نقل التطبيق». لا تقل إن التكرار موجود إذا كانت المشكلة تسجيلًا فريدًا في مكان غير مناسب.
إذا المشكلة بقاء صلاحيات، صغها حول الحقوق التي ثبتت وحاجة الحساب الحالية. قد تكون نتيجة أمنية مستقلة عن عطل المصادقة. فصل النتائج يساعد كل مالك يعالج الجزء الذي يخصه، ويمنع اختزال كل شيء في تغيير واحد يبدو أنه أصلح الصفحة لكنه لم يزل التعرض.
في إعادة الاختبار قارن أسماء العملاء المستخدمة، وموضع SPN، وهوية التشغيل، وسلوك الموارد الخلفية، وحالة الحقوق السابقة. احتفظ بجدول قبل وبعد داخل المشروع. الصور الخارجية إن استُخدمت في شرح عام لا تمثل دليل بيئتك؛ الدليل يجب أن يأتي من القراءة والاختبار المصرح نفسه.
الدرس العملي أن حساب الخدمة جزء من علاقة مستمرة بين التطبيق والدليل والموارد، وليس خانة تُستبدل مرة وينتهي الموضوع. إذا ضبطت هذه العلاقة قبل النقل، يصير التشخيص أهدأ والمعالجة أوضح. وإذا ركزت على نجاح تشغيل العملية فقط، قد تفوتك مشكلة مصادقة أو صلاحية زائدة تظهر لاحقًا تحت ضغط الإنتاج.
مراجع القراءة: أداة setspn الرسمية https://learn.microsoft.com/windows-server/administration/windows-commands/setspn وتشخيص التسجيل على هوية غير مناسبة في SQL https://learn.microsoft.com/en-ie/troubleshoot/sql/database-engine/connect/explicit-spn-is-misplaced . استُخدمت لفهم خيارات الاستعلام والفرق بين موضع التسجيل وهوية الخدمة؛ خطة النقل الفعلية تعتمد على التطبيق وتصميمه المعتمد. واحتفظ باسم وحدة التحكم المستخدمة في القراءات حتى تقدر تفسر اختلافًا مؤقتًا بين نقطتين بعد تعديل معتمد، بدل اعتبار كل اختلاف فشلًا نهائيًا للنقل.