SMB 2240 VPN के ज़रिए: लॉगऑन वर्कस्टेशन सूची जाँचें
त्रुटि 2240 का अर्थ है कि खाता शायद उस वर्कस्टेशन से लॉगऑन न कर सके। विफल लॉगऑन रिकॉर्ड पढ़ें और खाता ठीक करें, DNS या टनल नहीं।
टनल के ज़रिए शेयर खोलने पर त्रुटि 2240 आती है, और पहली प्रवृत्ति राउटिंग देखने की होती है। संख्या उससे अधिक विशिष्ट है। Windows बताता है कि खाता शायद इस वर्कस्टेशन से लॉगऑन न कर सके, जो एक खाते के बारे में नीति का कथन है, पहुँच के बारे में कथन नहीं।
त्रुटि संख्या टिकट में रखें। यह जाँच को एक विशेषता और एक घटना तक सीमित करती है।
2240 वास्तव में किसे दर्शाता है
नेटवर्क प्रबंधन त्रुटि सूची 2240 को NERR_InvalidWorkstation के रूप में पहचानती है, यह नाम शब्दशः पढ़ने योग्य है। खाता अनुमत लॉगऑन कंप्यूटरों के एक समूह तक सीमित है, और क्रेडेंशियल प्रस्तुत करने वाली मशीन उनमें नहीं है। उस परिभाषा में टनल, फ़ाइल शेयर या पासवर्ड का कोई उल्लेख नहीं है। विशेषता खाते पर रहती है और लॉगऑन का प्रयास होने पर इसका मूल्यांकन होता है।
उसी परिवार की अन्य संख्याएँ कुछ और दर्शाती हैं। अनुमत लॉगऑन घंटों का उल्लंघन अलग कोड है, और गलत पासवर्ड भी। सभी को एक पहुँच समस्या के रूप में रिपोर्ट करना उस विशिष्टता को बर्बाद करता है जो ऑपरेटिंग सिस्टम ने अभी दी है।
प्रतिबंध खाते पर रहता है, इसलिए यह पहचान का हर वहाँ अनुसरण करता है जहाँ प्रमाणीकरण होता है। जो उपयोगकर्ता हर दिन दफ़्तर में काम करता है और लैपटॉप घर ले जाता है, उसे यह केवल तब मिलता है जब मशीन का नाम बदलता है, और इसीलिए यह विफलता महीनों तक VPN समस्या जैसी लग सकती है, जब तक कोई पैटर्न न पहचान ले।
दो संबंधित तथ्य इसे समझाते नहीं हैं। NAT उपकरण खाते की विशेषता को छुए बिना देखा गया स्रोत पता बदल सकता है, और DNS प्रत्यय का बदलाव छोटे नाम को ठीक कर सकता है जबकि लॉगऑन प्रतिबंध ठीक वहीं रहता है जहाँ था। दोनों को बाहर करना उचित है, और कोई भी विशेषता पढ़ने का विकल्प नहीं है।
पहले विफल लॉगऑन रिकॉर्ड पढ़ें
निर्धारित करें कि फ़ाइल सर्वर ने किस पहचान को प्रमाणित किया और किस मशीन ने उसे प्रस्तुत किया। डोमेन खाता, मिलते-जुलते छोटे नाम वाला स्थानीय खाता और अलग VPN खाता आपस में बदले नहीं जा सकते, और त्रुटि का अर्थ तभी है जब सटीक खाता ज्ञात हो।
सुरक्षा लॉग प्रयास को खाते और कॉल करने वाले वर्कस्टेशन के नाम के साथ दर्ज करता है, और प्रतिबंध ठीक इसी जोड़ी के विरुद्ध मूल्यांकित होता है:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
Select-Object TimeCreated,Message | Format-List
Get-ADUser -Identity jdoe -Properties LogonWorkstations |
Select-Object SamAccountName,LogonWorkstations पहला आदेश विफलता और सर्वर को मिली वर्कस्टेशन श्रृंखला दिखाता है, और दूसरा खाते पर अनुमत सूची दिखाता है। यह मानने के बजाय कि क्लाइंट के अपने कंप्यूटर का नाम ही सर्वर ने दर्ज किया, दोनों की तुलना करें। लॉग में गलत दिखने वाला नाम आमतौर पर उपयोगी खोज होता है, क्योंकि वह उस मशीन का नाम बताता है जिससे सर्वर वास्तव में बात कर रहा मानता है। प्रतिबंध ठीक उसी विश्वास के विरुद्ध जाँचा जाता है।
VPN गेटवे का नाम न जोड़ें क्योंकि ट्रैफ़िक उससे होकर गुज़रता है। गेटवे प्रमाणित कॉलर नहीं है, और उसे सूची में जोड़ने से कुछ नहीं बदलता, बल्कि खाते की समीक्षा कठिन हो जाती है।
प्रतिबंध को सबसे छोटे दायरे में ठीक करें
अगर मशीन को अनुमति दी जानी चाहिए, तो ठीक वही प्रविष्टि खाते की वर्कस्टेशन सूची में जोड़ें और बाकी सब जैसा है वैसा रहने दें। अगर नहीं, तो सही उत्तर स्वीकृत मशीन है, प्रतिबंध हटाना नहीं, क्योंकि प्रतिबंध इसलिए है कि ये क्रेडेंशियल कहाँ इस्तेमाल हो सकें।
बड़े पैमाने के संपादन यहाँ आम हैं और आमतौर पर गलत हैं। लंबी अनुमत मशीन सूची वाला खाता ऐसा खाता है जिसका प्रतिबंध अब कुछ नहीं कहता।
यह जानना भी उपयोगी है कि पहचान साझा है या नहीं। जब कई लोग कई लैपटॉप से एक सेवा खाता इस्तेमाल करते हैं, तो वर्कस्टेशन सूची तब तक बढ़ती है जब तक नीति अर्थहीन न हो जाए, जो डिज़ाइन की समस्या है, प्रशासन की नहीं।
अगला परिणाम पढ़ें, उसकी अनुपस्थिति नहीं
स्वीकृत बदलाव के बाद इच्छित खाते से नया अनुरोध करें और दर्ज करें कि क्या होता है। अलग त्रुटि प्रगति है, क्योंकि वह पिछले चरण को दोहराने के बजाय अगले चरण का नाम बताती है।
DFS पथ कई सर्वर और कई पहुँच निर्णय ला सकता है। एक खाता विशेषता साफ़ करना उनमें से एक को सुलझाता है। रेफ़रल लक्ष्य अब भी पहुँच योग्य होने चाहिए, और उनमें से प्रत्येक पर शेयर और फ़ाइलसिस्टम अनुमतियाँ अब भी खाते को स्वीकार करनी चाहिए। अगली त्रुटि को भी उसी तरह पार करें, यह मानने के बजाय कि पहले सुधार ने सबको ढक लिया।
Windows के वर्कस्टेशन प्रतिबंध की रिपोर्ट करते समय VPN प्रोफ़ाइल दोबारा बनाने या पासवर्ड रीसेट करने का कोई कारण नहीं है। Microsoft की नेटवर्क त्रुटि सूची ठीक इसी कारण खुली रखने योग्य है: कोड आपको बताता है कि कुछ भी छूने से पहले कौन-सी विशेषता जाँचनी है।