आपका Mac RDP पर गलत Windows खाता भेज रहा है
स्वस्थ टनल और अस्वीकृत डेस्कटॉप लॉगिन अलग-अलग परतें हैं। कीचेन से कुछ भी हटाने से पहले उस रिमोट पीसी के लिए सहेजा गया खाता जाँचें।
टनल फिर से जुड़ता है, Mac फिर से ऑफ़िस नेटवर्क तक पहुँचता है, और Remote Desktop अब भी लॉगिन विफलता के साथ जवाब देता है। वह त्रुटि VPN की नहीं है। टनल Mac को मंज़ूरशुदा नेटवर्क पर लाती है; रिमोट कंप्यूटर में Windows खाता साइन इन करता है, और कनेक्शन प्रविष्टि कई महीने पहले बंद किया गया खाता भेजती रह सकती है।
कीचेन छूने से पहले प्रविष्टि देख लें।
VPN खाता और Windows खाता अलग-अलग चीज़ें हैं
VPN पहचान टनल गेटवे के सामने डिवाइस या व्यक्ति को प्रमाणित करती है। यह नहीं बताती कि रिमोट होस्ट कौन-सा Windows खाता स्वीकार करेगा, और यह उसका विकल्प नहीं बन सकती। जब टनल स्वस्थ हो और डेस्कटॉप लॉगिन अस्वीकार करे, तो समस्या नेटवर्क परत से आगे बढ़ चुकी है। दोनों प्रमाणीकरणों को अलग लॉग वाली अलग घटनाएँ मानें। गेटवे साफ़ सत्र दिखा सकता है जबकि Windows सुरक्षा लॉग किसी पूरी तरह अलग कारण से विफल लॉगिन दर्ज करता है।
मान लें कि व्यवस्थापक ने आपसे EXAMPLE\alex इस्तेमाल करने को कहा और सहेजी गई प्रविष्टि अब भी खाली alex चुनती है। ये अलग खाते हैं। अयोग्य नाम रिमोट कंप्यूटर के स्थानीय खातों के विरुद्ध हल होता है, और डोमेन से जुड़ी मशीन पर यह डोमेन पहचान में बिल्कुल भी नहीं हल हो सकता।
इसलिए डोमेन उपसर्ग हटाना कोई सामान्य मरम्मत नहीं है। यह बदलता है कि कौन-सा खाता माँगा जा रहा है, और यह ऐसा अस्वीकार पैदा कर सकता है जो पासवर्ड की समस्या जैसा दिखे जबकि पासवर्ड कभी मुद्दा ही नहीं था।
कनेक्शन प्रविष्टि खोलें, पूरी कीचेन नहीं
macOS के लिए मौजूदा Windows App में, डिवाइस के अंतर्गत रिमोट पीसी ढूँढें, उसकी संपादित करें क्रिया खोलें, और उसी खास प्रविष्टि से जुड़ा खाता देखें। ऐप सहेजे गए क्रेडेंशियल के नियंत्रण दिखाता है जिनसे आप दूसरा सहेजा खाता चुन सकते हैं या अप्रचलित हटा सकते हैं। चयन सुधारने की समर्थित जगह यही है। एक बार में एक गुण बदलें, ताकि पता चले कौन-सा संपादन वास्तव में मायने रखता था। क्रेडेंशियल बदलना और होस्टनाम बदलना साथ में करने से ऐसा परिणाम मिलता है जिसे कोई श्रेय नहीं दे सकता।
जिन कीचेन आइटम के नाम में सर्वर का नाम है, उन सबको हटाकर शुरू न करें। कीचेन आइटम ऐप्स के बीच साझा होते हैं, और व्यापक हटाने से Windows पक्ष पर कुछ बदले बिना असंबंधित पहुँच हट सकती है। यह वह सबूत भी नष्ट करता है जो आपको तब चाहिए होगा जब असली समस्या होस्टनाम, रूट या RDP सेवा निकले।
अगर एक सहेजा क्रेडेंशियल कई रिमोट पीसी इस्तेमाल करते हैं, तो हटाने से पहले उन निर्भरताओं को जाँचें। एक पीसी की प्रविष्टि संपादित करना उलटा जा सकता है; साझा क्रेडेंशियल हटाना ज़्यादा व्यापक असर और बदतर ऑडिट ट्रेल वाला बदलाव है।
व्यवस्थापक द्वारा दिया गया खाता स्वरूप इस्तेमाल करें
खाते को ठीक वैसे ही लिखें जैसे जारी हुआ था, उसी रूप में जिसकी परिवेश अपेक्षा करता है: NetBIOS शैली के डोमेन के लिए DOMAIN\user, या user principal name अगर डायरेक्टरी वही इस्तेमाल करती है। फिर इसे इस पीसी के लिए सहेजें और एक जानबूझकर कनेक्शन प्रयास करें।
देखें साइन-इन प्रॉम्प्ट कौन-सा खाता दिखाता है। जिस प्रॉम्प्ट में पहले से अलग नाम है उसका मतलब है कि सहेजा चयन बदला नहीं गया, और अभी किया गया प्रयास फिर पुराना क्रेडेंशियल आज़मा रहा था।
पासवर्ड को नोट्स, टिकट और स्क्रीनशॉट से दूर रखें। इसके बजाय खाते का नाम और सटीक त्रुटि कोड दर्ज करें, क्योंकि कोड खराब क्रेडेंशियल को नीति अस्वीकृति, समाप्त पासवर्ड या ऐसी मशीन से अलग करता है जो RDP बिल्कुल स्वीकार नहीं करती।
साइन-इन से पहले विफल कनेक्शन अलग खराबी है
अगर कोई Windows लॉगिन दिखने से पहले ही व्यूअर विफल हो जाए, तो क्रेडेंशियल संदिग्ध नहीं हैं। जाँचें कि होस्टनाम हल होता है, टनल के ऊपर से होस्ट तक रूट मौजूद है, और RDP सेवा सुन रही है। जो TCP कनेक्शन कभी बनता ही नहीं वह कभी खाता परत तक नहीं पहुँचता।
इसके विपरीत, स्पष्ट खाता अस्वीकृति यह सबूत नहीं है कि DNS टूटा है या प्रमाणपत्र सत्यापन ढीला करना चाहिए। ऐसे बदलाव कनेक्शन कमज़ोर करते हैं और आमतौर पर अस्वीकृति को वहीं छोड़ देते हैं जहाँ वह थी।
जितने छोटे हो सकें उतने चरणों में परखें: पुष्टि करें कि पोर्ट पहुँच में है, साइन-इन प्रॉम्प्ट दिखता है, दिखाया गया खाता वही है जो आप चाहते हैं, फिर पासवर्ड दें। हर चरण की अलग विफलता और अलग समाधान है।
स्वचालित पुनःकनेक्शन को अकेला छोड़ें
स्वचालित पुनःकनेक्शन मौजूदा प्रविष्टि का, उसके सहेजे खाते सहित, फिर से उपयोग करता है। यह सुविधा है, क्रेडेंशियल मरम्मत नहीं, इसलिए इसे बंद करने से गलत चयन ठीक नहीं होता और चालू करने से चयन बनता नहीं। अगर प्रविष्टि में अब सही खाता है, तो पुनःकनेक्शन उसी का उपयोग करेगा।
सुधरी हुई प्रविष्टि सहेजें, एक बार हाथ से जुड़ें और लिखें कि कौन-सा खाता काम कर गया। वही एक पंक्ति अगले व्यक्ति के निदान को पूरी दोपहर की कीचेन पुरातत्व-खोज के बजाय पाँच मिनट बना देती है।