لماذا يعرض Windows كلمة مرور VPN لخادم ملفات

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

حدّد أي حساب رُفض

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

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

اضبط UseRasCredentials على ملف تعريف واحد

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

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

حرّر دفتر الهاتف الذي يملك الاتصال

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

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

Get-ChildItem "$env:APPDATA\Microsoft\Network\Connections\Pbk"
Get-ChildItem "$env:PROGRAMDATA\Microsoft\Network\Connections\Pbk"
Copy-Item "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk.bak"
Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials"

داخل القسم الذي يحمل اسم الاتصال الدقيق، يكون المفتاح سطرًا واحدًا. غيّر تلك القيمة فقط واترك كل قسم آخر كما كان.

UseRasCredentials=1   becomes   UseRasCredentials=0

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

تحقق بمحاولة جديدة

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

Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials=0" -Context 4,0

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