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 चा त्रास नाही, तर डेटा उघड होण्याची समस्या आहे। फर्मवेअर अद्यतन वापरकर्ता खाती जोडत असेल, तर ते स्वस्त दीर्घकालीन उत्तर आहे।

स्वीकारलेले खाते आणि धोरणाची मूल्ये तिकिटात नोंदवा। अन्यथा पुढील व्यक्ती पुन्हा बोगदा चाचणी चालवेल आणि त्याच नकारापर्यंत पोहोचेल।