جهاز Mac يرسل حساب Windows الخطأ عبر RDP

يُعاد اتصال النفق، ويصل جهاز Mac إلى شبكة المكتب مرة أخرى، ومع ذلك يرد Remote Desktop بفشل في تسجيل الدخول. هذا الخطأ ليس خطأ VPN. النفق يوصل جهاز Mac إلى شبكة معتمدة؛ وحساب Windows هو الذي يسجّل الدخول إلى الكمبيوتر البعيد، وقد يواصل إدخال الاتصال إرسال حساب توقفت عن استخدامه منذ أشهر.

افحص الإدخال قبل أن تلمس سلسلة المفاتيح.

حساب VPN وحساب Windows شيئان مختلفان

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

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

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

افتح إدخال الاتصال، لا سلسلة المفاتيح بأكملها

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

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

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

استخدم صيغة الحساب التي وفّرها المسؤول

اكتب الحساب تمامًا كما صدر، بالصيغة التي تتوقعها البيئة: DOMAIN\user لنطاق على طراز NetBIOS، أو user principal name إذا كان هذا ما يستخدمه الدليل. ثم خزّنه لهذا الكمبيوتر وقم بمحاولة اتصال واحدة متعمدة.

لاحظ أي حساب تعرضه نافذة تسجيل الدخول. نافذة تحتوي بالفعل على اسم مختلف تعني أن الاختيار المحفوظ لم يُستبدل، وأن المحاولة التي أجريتها للتو اختبرت بيانات الاعتماد القديمة مرة أخرى.

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

فشل الاتصال قبل تسجيل الدخول عطل مختلف

إذا فشل العارض قبل ظهور أي تسجيل دخول Windows، فليست بيانات الاعتماد هي المشتبه بها. تحقق من أن اسم المضيف يُحل، وأن المسار إلى المضيف موجود عبر النفق، وأن خدمة RDP تستمع. اتصال TCP لا يُنشأ أبدًا لا يصل أبدًا إلى طبقة الحساب.

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

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

اترك إعادة الاتصال التلقائية كما هي

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

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