خطأ Clock Skew في Kerberos: افهم اختلاف الوقت وافحصه باستخدام w32tm

يشتغل لاب Active Directory أمس، وتفتحه اليوم فتفشل مصادقة Kerberos أو تظهر رسالة Clock Skew. أول رد فعل غالبًا إعادة إدخال كلمة المرور، ثم تغيير الأداة، ثم استعادة اللاب من جديد. لكن لو جهازك والدومين لا يتفقان على الوقت، تغيير الأمر ما يحل السبب.

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

ليش الوقت يدخل في مصادقة Kerberos أصلًا؟

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

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

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

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

خمس دقائق: قيمة شائعة، وليست حقيقة لكل لاب

في توثيق سياسة Maximum tolerance for computer clock synchronization تذكر مايكروسوفت خمس دقائق كقيمة افتراضية فعالة وتوصية. لكنها قيمة سياسة، لذلك لا تعاملها كقانون لا يتغير في جميع البيئات. قد يكون اللاب مضبوطًا بطريقة مختلفة، وقد تستخدم جهة أو أداة إعدادات أخرى في سياقها.

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

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

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

فرق المنطقة الزمنية عن الساعة نفسها

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

على جهاز ويندوز في اللاب، اقرأ الوقت المحلي مع إزاحته باستخدام:

Get-Date -Format o

ثم اقرأ تمثيل اللحظة نفسها بتوقيت UTC:

(Get-Date).ToUniversalTime().ToString('o')

هذه قراءات للوقت، لا أوامر تعديل. وإذا احتجت تعرف إعداد المنطقة الزمنية على ويندوز، استخدم Get-TimeZone. لا تغيّر المنطقة لمجرد أن صورة شرح تستخدم بلدًا آخر؛ أولًا اسأل هل الاختلاف في العرض أم في اللحظة الزمنية نفسها.

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

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

من وين يفترض أن يأخذ جهاز الدومين وقته؟

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

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

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

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

ثلاث قراءات تكفي كبداية بدل عشرين تعديلًا

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

ابدأ بهذه القراءات:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

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

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

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

اختبار فرق الوقت يحتاج قياسًا محدودًا

إذا كانت خطة اللاب تسمح بقياس الفرق مع dc01.lab.test وخدمة الوقت عليه متاحة، يمكن استخدام مثال محدود:

w32tm /stripchart /computer:dc01.lab.test /dataonly /samples:5

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

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

ونجاح فحص TCP على منفذ لا يثبت نجاح بروتوكول NTP؛ خدمة الوقت تستخدم UDP في هذا السياق. هذا التفريق مهم إذا كنت تعودت على أدوات اختبار الاتصال التي تفحص TCP فقط. لا تكتب أن منفذ الوقت مفتوح لأنك اختبرت نوع نقل مختلفًا، ولا تعطل جدار الحماية كخطوة تشخيص أولى.

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

اللاب الافتراضي يضيف طرفًا لازم تفهمه

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

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

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

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

تصحيح الوقت مو نفس قراءة الوقت

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

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

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

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

سيناريو تدريبي: كيف تثبت السبب بدون مبالغة؟

تخيّل عميلًا تدريبيًا اسمه ws01، وDC اسمه dc01. محاولة واحدة مصرح بها ترجع رسالة مرتبطة بتفاوت الوقت. ابدأ بسجل يحتوي وقت المحاولة، والنص الكامل، واسم الجهة التي خاطبتها. لا تغيّر الهدف إلى IP أو اسم آخر قبل تسجيل التجربة الأصلية؛ الاسم قد يدخل في تشخيص مختلف عن الوقت.

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

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

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

رتب الزمن في ملاحظاتك مثل ما ترتب خطوات الاختبار

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

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

للتوسع في قراءة التذاكر راجع شرح Rubeus وklist، وإذا كان الاختلاف مرتبطًا باسم الخدمة راجع شرح SPN وsetspn:
https://courses.cyberpts.com/community/76/shrh-rubeus-triage-wklist-aqra-tthakr-kerberos-wafhm-jlsh-hsabk-fy-allab
https://courses.cyberpts.com/community/77/shrh-spn-wsetspn-balarby-lysh-alkhdmh-tfth-basm-wtfshl-basm-thany

مراجع الأدوات والصورة: توثيق Windows Time Service tools and settings، وHow the Windows Time Service works من مايكروسوفت:
https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings
https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/how-the-windows-time-service-works

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