لماذا يحتاج حاسوب Protected Users المحمول إلى VPN قبل تسجيل الدخول

حاسوب محمول وحساب يعمل وشبكة فندق تفضي إلى حلقة تسجيل دخول لا يكسرها أي قدر من إعادة المحاولة. الحساب موجود في Protected Users، وهو ما يمنع Windows من تخزين المُتحقِّق الذي يحتاجه لمصادقة المستخدم دون اتصال. وأي خطة من قبيل «سجّل الدخول أولًا، ثم وصّل النفق بعد ذلك» تعكس الترتيب، والحماية تفعل بالضبط ما وعدت به. ما يلي يفترض حساب Active Directory تقليديًا على مضيف Windows مدعوم.

ما تزيله الحماية في الواقع

يقوم Windows عادةً بتخزين مُتحقِّق مؤقتًا حتى يتمكن حساب النطاق من تسجيل الدخول بينما تكون وحدة تحكم النطاق غير قابلة للوصول. وتمنع Protected Users ذلك للحساب، وهو ما يزيل تسجيل الدخول إلى النطاق دون اتصال كاحتمال بدلًا من جعله غير موثوق.

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

لماذا يجب أن يوجد النفق قبل سطح المكتب

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

استخدم ترتيبًا مدعومًا لما قبل تسجيل الدخول تتفق عليه مع مالكي الأجهزة الطرفية والهوية. فنفق جهاز Always On VPN المُصادَق عليه بشهادة حاسوب يستوفي الشرط عندما يفي الجهاز المُدار بمتطلبات ذلك النشر المسبقة. وتكامل مدعوم من مورّد في شاشة تسجيل الدخول هو بديل آخر. أما ملف تعريف مستخدم عادي بمُشغِّل تلقائي فليس أياً منهما، مهما بدا مشابهًا في واجهة العميل.

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

إمكانية الوصول ليست توافقًا في المصادقة

يمكن للنفق أن يحمل الحزم بشكل سليم بينما تفشل مصادقة النطاق، لأن الآلية التي تُجرَّب هي آلية لا يجوز للحساب استخدامها. وفي نطاق يفرض قيود المجموعة، لا يكون NTLM متاحًا للأعضاء ويحتاج Kerberos إلى حساب وإعداد متوافقين مع AES. ومسار الحزم لا يمكنه إصلاح أي منهما. ولهذا فإن نجاح ping نظيف إلى وحدة تحكم النطاق ليس دليلًا على أن تسجيل الدخول سينجح.

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

اقرأ أدلة المصادقة

اجمع الأحداث من العميل ومن وحدة تحكم النطاق لنفس المحاولة، لا من جانب واحد فقط. تقع سجلات Protected Users تحت Applications and Services Logs\Microsoft\Windows\Authentication، وقد يضطر المسؤول إلى تشغيل سجل قبل أن يسجّل أي شيء. اربط الطوابع الزمنية بسجل اتصال النفق نفسه، لأن خطأ الترتيب يبدو كخلل في بيانات الاعتماد من أي من الجانبين.

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

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

أثبت الحد من إقلاع بارد

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

1. تأكد من أن الجهاز يستطيع العثور على وحدة تحكم نطاق قبل أن يسجل أي شخص الدخول، باستخدام nltest /dsgetdc:corp.example.com.
2. جرّب تسجيل الدخول إلى النطاق، ثم اسأل هل حُصل على تذكرة من الأصل، باستخدام klist.
3. اقرأ سجل المصادقة الذي يسجله الجهاز، بالأمرين أعلاه، ولاحظ الحزمة وشرط الفشل.
4. تأكد من أن بيانات الاعتماد البديلة المعتمدة لا تزال تعمل من شاشة تسجيل الدخول، لأنها السبيل الوحيد للعودة إذا فشل اختبار الحد.

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

يصف توثيق Protected Users كلاً من سلوك المُتحقِّق وقيود النطاق التي يعتمد عليها هذا التصميم. خطّط لعملية الاسترداد قبل أن يسافر أي شخص، لأن اختبار الإقلاع البارد هو المكان الوحيد الذي يُمارَس فيه.