VPN मार्फत SMB अतिथि लगइन: Windows अझै पनि पहिचान माग्छ

कार्यालयको VPN मा जोडिँदा फाइल सर्भर पहुँचयोग्य हुन्छ र तैपनि साझेदारीले पहुँच अस्वीकार गर्छ, जसले सुरुङ बिग्रिएको छ भन्ने निष्कर्षतर्फ लैजान्छ। सामान्यतया त्यस्तो हुँदैन। SMB ले प्रत्येक सत्र अलगै प्रमाणित गर्छ, र Windows ले अनाम लगइनका रूपमा के स्वीकार्ने भन्ने कुरा निरन्तर कडाइ गर्दै छ। नेटवर्क मार्ग र प्रयोगकर्ता पहिचान दुई फरक आवश्यकता हुन्, र त्रुटि दोस्रोसँग सम्बन्धित छ।

सुरुङले SMB पहिचानको ठाउँ किन लिन सक्दैन

सर्भरसँग सबनेट साझा गर्नु भनेको कहिल्यै त्यसका फाइल पढ्ने अनुमति थिएन; यसले राउटिङको समस्या मात्र हटाउँछ। क्लाइन्टले असुरक्षित अतिथि लगइन अवरुद्ध गर्दा Windows ले घटना 31017 अभिलेख गर्छ, र त्यो सर्भरमा होइन, तपाईंको मेसिनमा लिइने निर्णय हो। सुरुङले SMB प्याकेट इमानदारीसाथ ओसार्छ, तर अतिथि सत्र अस्वीकार गरिन्छ। त्यसैले एउटै जस्तो घरेलु नेटवर्कमा एउटा ल्यापटप चल्छ र अर्को चल्दैन।

घटनालाई नेटवर्क खराबी होइन, नीतिको प्रमाण मान्नुहोस्। सुधार पहिचानमा वा उपकरणमै छ।

क्लाइन्ट नीति र अस्वीकृति घटना पढ्नुहोस्

दुई आउटपुटले प्रश्न छिटो टुंग्याउँछन्: प्रभावकारी क्लाइन्ट कन्फिगरेसन र हालैका अस्वीकृति घटनाहरू।

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

गलत अतिथि सेटिङ र हस्ताक्षरको आवश्यकता मिलेर कुनै पनि थप अनुसन्धानअघि विफलता व्याख्या गर्छ। घटना लगले क्लाइन्टले सत्र अस्वीकार गरेको पुष्टि गर्छ, सर्भरले प्रमाणपत्र अस्वीकार गरेको होइन। अर्को मेसिनमा सफल प्रयासमा प्रयोग भएको साझेदारी मार्ग र खाता टिप्नुहोस्, किनकि क्यास गरिएको सत्रले दुई परीक्षण एकै जस्तो देखाउन सक्छ, जबकि ती त्यस्तो हुँदैनन्। भइरहेका जडानहरू net use ले खाली गर्नुहोस्, त्यसपछि तुलना गर्नुहोस्, पुरानो सत्रले नयाँको सट्टा जवाफ नदिन।

नाम भएको खाता प्रयोग गर्नुहोस् र हस्ताक्षर कायम राख्नुहोस्

दिगो समाधान सर्भरले चिन्ने खाता हो, स्पष्ट रूपमा दिइएको, र हस्ताक्षर तथा इन्क्रिप्सन नीति जस्ताको तस्तै रहन्छ। डायलगमा कुनै नाम टाइप गर्नुको सट्टा जडानमै प्रमाणपत्र दिनुहोस्।

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

नाम भएको लगइनले सर्भरले अडिट गर्न सक्ने सत्र बनाउँछ, र Get-SmbConnection ले डायलेक्ट र हस्ताक्षर सक्रिय छ कि छैन देखाउँछ। अतिथि सत्रले हस्ताक्षर वा इन्क्रिप्सनका आवश्यकता पूरा गर्न सक्दैनन्, त्यसैले अतिथि झन्डा सक्रिय गर्दा ती माग गर्ने नीति जोगाउन सकिँदैन। जहाँ पुरानो उपकरणमा खाता मोडेल छैन, त्यहाँ अतिथि पहुँचलाई प्रतिस्थापन योजनासहित स्पष्ट रूपमा अभिलेखित अपवाद मान्नुहोस्। एउटा उपकरणका लागि हरेक जडानमा हस्ताक्षर कमजोर नगर्नुहोस्।

जब उपकरणले अतिथि मात्र चिन्छ

केही उपभोक्ता NAS बाकसमा खाताको अवधारणा बिना साझेदारी हुन्छ, जसले दुई इमानदार विकल्प छोड्छ: उपकरण अलग गर्नु वा बदल्नु। यसलाई संवेदनशील कुनै चीजतर्फ मार्ग नभएको खण्डमा राख्नुहोस्, र सुविधाको अपवाद पूरै क्लाइन्टको पूर्वनिर्धारित बन्न नदिनुहोस्। ब्याकअप वा प्रमाणपत्र राखिएको अतिथि साझेदारी Windows को झन्झट होइन, डेटा खुलासाको समस्या हो। यदि फर्मवेयर अपडेटले प्रयोगकर्ता खाता थप्छ भने त्यो सस्तो दीर्घकालीन उत्तर हो।

स्वीकृत खाता र नीतिका मानहरू टिकटमा अभिलेख गर्नुहोस्। नत्र अर्को व्यक्तिले फेरि सुरुङ परीक्षण चलाउनेछ र उही अस्वीकृतिमा पुग्नेछ।