Protected Users वाला लैपटॉप साइन-इन से पहले VPN क्यों ज़रूरी है

एक लैपटॉप, एक काम करता खाता और एक होटल नेटवर्क मिलकर साइन-इन का ऐसा चक्र बनाते हैं जिसे कोई दोहराया प्रयास नहीं तोड़ता। खाता Protected Users में है, जो Windows को वह सत्यापक संग्रहीत करने से रोकता है जिसकी उपयोगकर्ता को ऑफ़लाइन प्रमाणित करने के लिए ज़रूरत होगी। «पहले साइन इन करें, फिर टनल जोड़ें» जैसी कोई भी योजना क्रम उलटा रखती है, और सुरक्षा ठीक वही करती है जिसका वादा करती है। आगे समर्थित Windows होस्ट पर पारंपरिक Active Directory खाता माना गया है।

सुरक्षा वास्तव में क्या हटाती है

आम तौर पर Windows एक सत्यापक कैश करता है ताकि डोमेन खाता तब भी साइन इन कर सके जब डोमेन नियंत्रक उपलब्ध न हो। Protected Users खाते के लिए इसे अवरुद्ध करता है, जो ऑफ़लाइन डोमेन साइन-इन को अविश्वसनीय बनाने के बजाय संभावना के रूप से हटा देता है।

यह पुराने कैश की सामान्य समस्या नहीं है, और सामान्य उपाय यहाँ लागू नहीं होते। बार-बार ऑनलाइन साइन इन करना, फिर से पासवर्ड बदलना या कैश किए गए साइन-इन की संख्या बढ़ाना क्षमता वापस नहीं लाएगा, क्योंकि इनमें से कोई भी क्रिया वह सत्यापक नहीं बनाती जिसे नीति संग्रहीत करने से मना करती है। खाता डिज़ाइन के अनुसार व्यवहार कर रहा है, और डिज़ाइन मानता है कि जब Windows पूछता है तब नेटवर्क मौजूद है। लक्षण को कैश दोष मानना वह रास्ता है जिससे टीमें ऐसी प्रोफ़ाइल फिर से बनाती हैं जो कभी टूटी ही नहीं थी।

टनल डेस्कटॉप से पहले क्यों होनी चाहिए

डिवाइस को डोमेन प्रमाणीकरण तक उसी क्षण पहुँचना होता है जब Windows मांगता है, और वह किसी भी उपयोगकर्ता सत्र से पहले है। जो VPN क्लाइंट डेस्कटॉप दिखने के बाद ही शुरू होता है वह नए साइन-इन को ऐसे रास्ते का इंतज़ार कराता है जो कभी नहीं आता। निर्भरता मशीन की है, उस उपयोगकर्ता की नहीं जिसने अभी लॉग इन नहीं किया।

एंडपॉइंट और पहचान के मालिकों के साथ सहमत समर्थित प्री-लॉगिन व्यवस्था अपनाएँ। कंप्यूटर प्रमाणपत्र से प्रमाणित Always On VPN डिवाइस टनल तब योग्य है जब प्रबंधित डिवाइस उस परिनियोजन की पूर्व-शर्तें पूरी करता है। विक्रेता का समर्थित साइन-इन स्क्रीन एकीकरण दूसरा विकल्प है। स्वचालित ट्रिगर वाली सामान्य उपयोगकर्ता प्रोफ़ाइल इनमें से कोई नहीं है, क्लाइंट इंटरफ़ेस में कितना भी समान दिखे।

उस रास्ते को डोमेन के लिए नाम विश्लेषण, एक पहुँचने योग्य डोमेन नियंत्रक और वे प्रमाणीकरण प्रोटोकॉल चाहिए जिन्हें खाता उपयोग कर सकता है, और «जुड़ा हुआ» संकेतक इनमें से कुछ नहीं देता। उसके रूट और फ़िल्टर पहचान सेवाएँ ले जाने चाहिए और जो आवश्यक न हो वह कुछ नहीं, क्योंकि वही उपसर्ग सूची वह सतह है जो चोरी हुआ लैपटॉप किसी के लॉग इन करने से पहले पा लेता है। उपयोगकर्ता टनल के लिए लिए गए स्प्लिट-टनल निर्णय डिवाइस टनल पर लागू नहीं होते, इसलिए दोनों को अलग-अलग जाँचें।

पहुँचना प्रमाणीकरण अनुकूलता नहीं है

टनल पैकेट बखूबी ले जा सकती है जबकि डोमेन प्रमाणीकरण विफल हो, क्योंकि जो तंत्र आज़माया जा रहा है वह ऐसा है जिसे खाता उपयोग नहीं कर सकता। जिस डोमेन में समूह के प्रतिबंध लागू होते हैं वहाँ सदस्यों के लिए NTLM उपलब्ध नहीं है और Kerberos को AES-अनुकूल खाता और कॉन्फ़िगरेशन चाहिए। पैकेट का रास्ता इनमें से किसी को ठीक नहीं कर सकता। इसीलिए डोमेन नियंत्रक तक साफ़ ping इस बात का प्रमाण नहीं है कि साइन-इन काम करेगा।

दो क्रेडेंशियल प्रणालियाँ भी चल सकती हैं। VPN किसी पहचान प्रदाता के विरुद्ध प्रमाणित हो सकता है जबकि Windows को अलग से डोमेन लॉगऑन चाहिए, और पहले की स्वीकृति दूसरे के बारे में कुछ नहीं कहती। «VPN जुड़ गया» और «उपयोगकर्ता साइन इन हो गया» अलग-अलग प्रेक्षण हैं, और एक ठीक करने का अर्थ दूसरा नहीं है।

प्रमाणीकरण के साक्ष्य पढ़ें

एक ही प्रयास के लिए घटनाएँ क्लाइंट और डोमेन नियंत्रक दोनों से इकट्ठा करें, केवल एक पक्ष से नहीं। Protected Users के लॉग Applications and Services Logs\Microsoft\Windows\Authentication के अंतर्गत हैं, और प्रशासक को कुछ भी दर्ज होने से पहले लॉग चालू करना पड़ सकता है। समय-चिह्नों को टनल के अपने कनेक्शन लॉग से सहसंबंधित करें, क्योंकि क्रम की गलती दोनों ओर से क्रेडेंशियल दोष जैसी दिखती है।

नीचे पहला आदेश उपकरण द्वारा उजागर हर प्रमाणीकरण लॉग सूचीबद्ध करता है, इसलिए आप वह पढ़ते हैं जो मौजूद है, वह नहीं जिसका नाम किसी ब्लॉग पोस्ट ने रखा। दूसरा नाम जानने के बाद हाल की प्रविष्टियाँ पढ़ता है। प्रमाणीकरण पैकेज, खाता और विफलता की शर्त देखें, क्योंकि अनुपस्थित नेटवर्क मार्ग और अस्वीकृत तंत्र अलग साक्ष्य छोड़ते हैं और उनमें से केवल एक VPN समस्या है। यदि टनल प्रयास के बाद ऊपर आई, तो क्रम गलत था, चाहे वे प्रविष्टियाँ कुछ भी कहें।

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

ठंडे बूट से सीमा सिद्ध करें

परीक्षण साइन आउट या ताज़ा बूट हुई स्थिति से सीमित खाते के साथ चलाएँ, और विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए कुछ भी बदलने से पहले स्वीकृत पुनर्प्राप्ति मार्ग खुला रखें। पहले से चल रहे डेस्कटॉप पर परीक्षण महत्वपूर्ण कोड मार्ग का कोई भाग नहीं आज़माता, और यही अगली रीस्टार्ट तक टिके सुधार की अधिकांश रिपोर्टों की व्याख्या करता है। फिर चार चरण इसी क्रम में पूरे करें।

1. पुष्टि करें कि डिवाइस किसी के साइन इन करने से पहले डोमेन नियंत्रक खोज सकता है, nltest /dsgetdc:corp.example.com से।
2. डोमेन साइन-इन का प्रयास करें, फिर klist से पूछें कि क्या टिकट मिला ही था।
3. उपकरण जो प्रमाणीकरण लॉग दर्ज करता है उसे ऊपर के दो आदेशों से पढ़ें, और पैकेज तथा विफलता की शर्त नोट करें।
4. पुष्टि करें कि स्वीकृत पुनर्प्राप्ति क्रेडेंशियल अभी भी साइन-इन स्क्रीन से काम करता है, क्योंकि सीमा परीक्षण विफल होने पर लौटने का यही एकमात्र रास्ता है।

दिए गए क्रेडेंशियल से फ़ाइल शेयर खोलना भी ऑफ़लाइन इंटरैक्टिव लॉगऑन नहीं बनाता, इसलिए यह ऊपर के किसी भी चरण का विकल्प नहीं है। यदि संगठन को सचमुच बिना कनेक्शन के साइन-इन चाहिए, तो उत्तर जानबूझकर चुना गया अनुकूल खाता और एंडपॉइंट डिज़ाइन है। खाते को समूह से बाहर निकालना, या हर लैपटॉप पर एक अप्रतिबंधित आपातकालीन लॉगिन रखना, पहचान नीति का निर्णय है जो VPN परिवर्तन आपकी ओर से नहीं ले सकता।

Protected Users का दस्तावेज़ सत्यापक के व्यवहार और उन डोमेन प्रतिबंधों, दोनों का वर्णन करता है जिन पर यह डिज़ाइन निर्भर है। किसी के यात्रा करने से पहले पुनर्प्राप्ति प्रक्रिया की योजना बनाएँ, क्योंकि ठंडे बूट का परीक्षण ही एकमात्र जगह है जहाँ इसका अभ्यास होता है।