VPN फ़ाइल शेयर को उस Samba खाते से जोड़ना जिसे सर्वर जानता है
Windows या VPN में साइन-इन Samba खाता नहीं बनाता। शेयर को उस पहचान से जोड़ें जिसे फ़ाइल सर्वर जानता है, और सत्र टकराव पर ध्यान दें।
टनल जोड़ें और शेयर अब भी ऐसा पासवर्ड माँग रहा है जिसे उपयोगकर्ता सही मानता है। अलग Samba परिनियोजन में VPN लॉगिन और SMB लॉगिन असंबंधित क्रेडेंशियल हैं: एक टनल को अधिकृत करता है, दूसरे की जाँच फ़ाइल सर्वर करता है। इसलिए VPN खाते से ड्राइव जोड़ना तब भी विफल होता है जब पासवर्ड सही हो और नेटवर्क पथ बेदाग़ हो। यही अंतर VPN के ज़रिए जोड़ने की अधिकांश विफलताएँ समझाता है।
समाधान VPN खाता रीसेट करना नहीं है। समाधान यह है कि ऐसी पहचान का नाम लें जिसे Samba सर्वर वास्तव में जानता है, फिर जाँचें कि उसी पहचान के पास शेयर और फ़ोल्डर पर अधिकार हैं।
VPN लॉगिन और SMB लॉगिन अलग-अलग पहचानें हैं
VPN खाते का मूल्यांकन VPN गेटवे अपनी नीति के अनुसार करता है। यह बताता है कि क्या यह क्लाइंट निजी नेटवर्क में प्रवेश कर सकता है। यह कुछ नहीं बताता कि उस नेटवर्क के भीतर फ़ाइल सर्वर पर कौन-सा SMB खाता मौजूद है।
Samba खाता सर्वर के प्रमाणीकरण बैकएंड में अपने पासवर्ड डेटाबेस और अपने नाम के साथ रहता है। दो मशीनों में दोनों में alice नाम का उपयोगकर्ता हो सकता है बिना पहचान प्रणाली, पासवर्ड या उपयोगकर्ता पहचानकर्ता साझा किए। नाम मेल खाते हैं; खाते नहीं।
डोमेन में एकीकृत Samba सर्वर तस्वीर बदल देता है: पहचान निर्देशिका और Kerberos से आती है, स्थानीय खाता सूची से नहीं। ऐसे में निर्देशिका की पहचान और समर्थित SMB कॉन्फ़िगरेशन का उपयोग करें, स्थानीय नकलें बनाकर डोमेन सदस्यता की नक़ल करने के बजाय। कोई भी खाता बनाने से पहले जाँचें कि सर्वर कौन-सा मॉडल उपयोग करता है।
देखें कि Windows वास्तव में कौन-सी पहचान उपयोग कर रहा है
Windows कनेक्शन को प्रति सर्वर कैश करता है। यदि उसी सर्वर से मौजूदा सत्र किसी दूसरे खाते से खुला था, तो नया जोड़ना उसी सत्र को फिर इस्तेमाल कर सकता है या ऐसी प्रमाणीकरण त्रुटि दे सकता है जो गलत उपयोगकर्ता का नाम लेती है। सही पासवर्ड इसी तरह गलत दिखता है। क्रेडेंशियल बदलने से पहले मौजूदा कनेक्शन जाँचें।
net use
cmdkey /list
klist
पहला कमांड जुड़ी ड्राइव और खुले सत्र दिखाता है, दूसरा सहेजे गए क्रेडेंशियल दिखाता है जो अपने-आप लागू हो सकते हैं, और तीसरा Kerberos टिकट दिखाता है जब डोमेन उपयोग हो रहा हो। सहेजा गया क्रेडेंशियल चुपचाप उस खाते को बदल सकता है जिसे आप लिखना चाहते थे।
केवल वही कनेक्शन या क्रेडेंशियल हटाएँ जो इस समस्या से जुड़ा है। सभी ड्राइव काट देना या सर्वर का नाम IP पते से बदल देना पहचान के चयन को छिपाता है और हस्ताक्षर या नाम-आधारित नीति तोड़ सकता है।
शेयर को उस खाते से जोड़ें जिसे सर्वर पहचानता है
खाता उस रूप में दें जिसकी सर्वर अपेक्षा करता है और Windows को पासवर्ड पूछने दें, ताकि रहस्य कमांड इतिहास या स्क्रिप्ट में न जाए:
net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no
बैकस्लैश से पहले वाला सर्वर भाग Samba सर्वर का पहचान संदर्भ है, VPN गेटवे नहीं। तारा इंटरैक्टिव पासवर्ड संकेत माँगता है, और /persistent:no जोड़ने को अगले साइन-इन से बाहर रखता है। खाली ड्राइव अक्षर चुनें।
यदि सर्वर डोमेन में एकीकृत है, तो उपयोगकर्ता भाग इसके बजाय निर्देशिका नाम या डोमेन-योग्य पहचान हो सकता है। वही रूप उपयोग करें जिसे व्यवस्थापक प्रलेखित करता है; उसी नाम से स्थानीय खाता गढ़ना दूसरी पहचान और रखरखाव के लिए दूसरा पासवर्ड बनाता है।
खाते की वैधता, शेयर तक पहुँच और फ़ाइल सिस्टम के अधिकार तीन जाँचें हैं
Samba जाँचता है कि पहचान प्रमाणित होती है या नहीं, क्या शेयर परिभाषा उसे स्वीकार करती है, और क्या फ़ाइल सिस्टम मांगा गया संचालन देता है। पहली जाँच पार करना बाकी दो के पार होने का मतलब नहीं। शेयर दिख सकता है और फिर भी लिखने से मना कर सकता है क्योंकि फ़ोल्डर की अनुमतियाँ ऐसा कहती हैं।
valid users से सीमित शेयर केवल सूचीबद्ध खाते या समूह स्वीकार करता है। खाता सही प्रमाणित हो सकता है और फिर भी उस पंक्ति से अस्वीकार हो सकता है। पासवर्ड गलत होने का निष्कर्ष निकालने से पहले शेयर परिभाषा जाँचें।
फ़ाइल सिस्टम की ओर Samba प्रक्रिया और जुड़ी पहचान दोनों मायने रखते हैं। root के स्वामित्व वाला 700 मोड वाला फ़ोल्डर सामान्य खाते से लिखना स्वीकार नहीं करेगा, भले ही शेयर परिभाषा अनुमति दे। जिस फ़ोल्डर को खाते ने उपयोग करना है उसमें पहले पढ़कर, फिर लिखकर परखें।
नीति तोड़े बिना टकराव वाला सत्र साफ़ करें
जब कारण पुराना सत्र हो, उस एक कनेक्शन को बंद करें और इच्छित खाते से फिर जोड़ें। यदि सहेजा क्रेडेंशियल बार-बार लौटे, तो पूरी ड्राइव सूची के बजाय वही क्रेडेंशियल हटाएँ। फिर नए सत्र की net use से पुष्टि करें।
अपेक्षित SMB हस्ताक्षर, एन्क्रिप्शन और खाता नीति बनाए रखें। जो सर्वर अहस्ताक्षरित या अनएन्क्रिप्टेड सत्र अस्वीकार करता है वह नीति लागू कर रहा है, पासवर्ड गलत नहीं पढ़ रहा, और जोड़ने की सफलता के लिए उसे कमज़ोर करना सुरक्षा को लक्षण से बदल देता है।
सर्वर का नाम, खाते का सटीक रूप और वे शेयर व फ़ोल्डर अधिकार लिख लें जो काम आए। वरना ड्राइव जोड़ने वाला अगला व्यक्ति पहले VPN लॉगिन आज़माएगा, क्योंकि यही वे क्रेडेंशियल हैं जिनसे वह नेटवर्क तक पहुँचा।