آخر تسجيل دخول في Active Directory: الفرق بين lastLogon وlastLogonTimestamp قبل ما تعطل حسابًا

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

التاريخ يجاوب عن سؤال محدد، مو عن كل نشاط الحساب

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

وش يميز lastLogon؟

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

ليش lastLogonTimestamp ممكن يتأخر عن الدخول؟

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

اقرأ القيم الخام أولًا، ثم حوّلها للتوقيت المناسب

داخل لاب مصرح، اقرأ الحساب المحدد من خادم معلوم:
$labUser = Get-ADUser -Identity student -Server dc01.lab.test -Properties lastLogon,lastLogonTimestamp
$labUser | Select-Object SamAccountName,lastLogon,lastLogonTimestamp
القيم الخام قد تظهر أعدادًا كبيرة. توثيق الخصائص يصفها بصيغة زمنية تعتمد على فترات مقدارها مئة نانوثانية منذ بداية سنة 1601 بالتوقيت العالمي. لا تتعامل مع العدد كأنه ثوانٍ منذ 1970 لمجرد أنك اعتدت نوعًا آخر من الطوابع الزمنية.
يمكن تحويل قيمة موجبة إلى توقيت عالمي باستخدام دالة مناسبة:
if ([int64]$labUser.lastLogon -gt 0) { [datetime]::FromFileTimeUtc([int64]$labUser.lastLogon).ToString('o') } else { 'No usable lastLogon value from this source' }
المثال يتعمد عدم كتابة «لم يسجل دخولًا أبدًا» عند غياب قيمة مفيدة. توثيق lastLogon يذكر أن الصفر يعني أن وقت آخر دخول غير معروف. وبين المجهول والنفي المطلق فرق مهم في أي تقرير.
احتفظ باسم الخاصية والخادم مع الوقت المحول. إذا نسخت التاريخ وحده إلى جدول، فقد تضيع المعلومة التي تفسر اختلافه عن قيمة من مصدر آخر. واكتب المنطقة الزمنية في اسم العمود أو وصفه، حتى لا يقارن زميلك وقتًا عالميًا بوقت محلي وكأن بينهما نشاطًا مختلفًا.
هذا المثال لا يعدّل الحساب ولا قيمته؛ هو يقرأ خاصية ثم يغيّر طريقة عرضها محليًا. لا تحاول تصحيح التواريخ داخل الدليل يدويًا لكي تتطابق مع توقعك. إذا وجدت قيمة غير منطقية، راجع المصدر والتحويل والسياق قبل التفكير في أي تغيير إداري.

مثال مقارنة بين خادمين يكشف خطأ الاستنتاج

لدينا لاب افتراضي فيه وحدتا تحكم فقط: dc01 وdc02. نقرأ نفس الحساب من كل واحدة:
Get-ADUser -Identity student -Server dc01.lab.test -Properties lastLogon | Select-Object SamAccountName,lastLogon
Get-ADUser -Identity student -Server dc02.lab.test -Properties lastLogon | Select-Object SamAccountName,lastLogon
بعد تحويل القيم بطريقة واحدة، افترض أن الأولى تشير إلى يوم الاثنين والثانية إلى يوم الخميس من الأسبوع نفسه. النتيجة المناسبة أن أحدث قيمة وجدناها عبر وحدتي التحكم في هذا اللاب هي قيمة الخميس، مع حفظ تفاصيل المصدرين.
لو أخفق الاستعلام الثاني، لا تضع صفرًا بدل الخطأ ثم تأخذ القيمة الأولى كأن المقارنة اكتملت. فشل الجلب حالة مستقلة عن قيمة خاصية صفرية. في جدول العمل، ميز بين «استعلام نجح وقيمة غير معروفة» و«استعلام لم يكتمل» و«استعلام نجح بقيمة زمنية». دمج الثلاثة في خانة فارغة يخفي حدود المراجعة.
افترض الآن أن أحدهم أحضر حدثًا من جهاز تدريبي يشير إلى جلسة في وقت آخر. لا تقل فورًا إن الخاصية خاطئة. افحص نوع الحدث والحساب والجهاز والوقت، ثم راجع كيف يرتبط بالنشاط الذي تسأل عنه. هذه مقارنة بين مصادر مختلفة، وليست مسابقة لاختيار أكبر رقم فقط.
وأثناء كتابة التقرير، لا تجعل مثال الخادمين وصفًا لكل بيئة. إذا كان الدومين الفعلي يحتوي وحدات أخرى، تحتاج تضمينها وفق النطاق والتغطية المطلوبة، أو توضيح ما لم تشملْه. الحساب الصحيح مع مصدر ناقص قد ينتج استنتاجًا ناقصًا مهما كان الأمر مكتوبًا بإتقان.

متى تترك خصائص الدليل وتروح للسجلات؟

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

كيف تبني قائمة مراجعة للحسابات القديمة بدون تعطيل متسرع؟

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

تمرين صغير ومراجع ترجع لها

خذ حسابًا تدريبيًا واحدًا واطلب من مسؤول اللاب تحديد وحدات التحكم التي ستشملها المقارنة. اقرأ القيم الخام واحتفظ باسم الخاصية والخادم والتوقيت. بعد نشاط دخول معروف، أعد القراءة وفسر ما تغير وما لم يتغير بناء على طريقة تحديث كل خاصية، دون توقع أن جميع الأعمدة تقفز فورًا إلى اللحظة نفسها.
اكتب ثلاث جمل في نهاية التجربة: أحدث قيمة وجدتها من المصادر التي اكتملت، وما إذا كانت التغطية كاملة لهذا اللاب، وما الذي لا تستطيع إثباته من هذه القيم وحدها. إذا قدرت تكتبها بوضوح، فقد تعلمت الجزء الذي يحميك من أخطاء التقارير أكثر من حفظ أمر استخراج التاريخ.
الصورة الخارجية مأخوذة من مادة منشورة في Microsoft Q&A عن عرض المستخدمين داخل وحدة تنظيمية ووحداتها الفرعية. تظهر فيها صياغة قديمة تستعمل كلمة Never للحالة الفارغة؛ لا نعتمد هذا التعبير حكمًا على أن الحساب لم يستخدم أبدًا. شرحنا أعلاه يفصل غياب قيمة مفيدة عن نفي النشاط.
مصدر الصورة:
https://learn.microsoft.com/en-us/answers/questions/333569/list-all-users-last-logon-on-specific-ou-%28child-ou%29
تعريف lastLogon وحدود القراءة من وحدة تحكم واحدة:
https://learn.microsoft.com/en-us/windows/win32/adschema/a-lastlogon
تعريف lastLogonTimestamp وآلية التحديث:
https://learn.microsoft.com/en-us/windows/win32/adschema/a-lastlogontimestamp
توثيق التحويل إلى توقيت عالمي:
https://learn.microsoft.com/en-us/dotnet/api/system.datetime.fromfiletimeutc
مرجع حدث الدخول وأنواعه:
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624
التاريخ مفيد عندما تعرف ما يمثله. وكلما صار القرار الذي ستبنيه عليه أكبر، زادت حاجتك لتغطية أوضح ومصدر مناسب وتفسير يحترم ما تقوله البيانات فعلًا.