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 को कागजात ले प्रमाणकको व्यवहार र यो डिजाइन अवलम्बित डोमेन प्रतिबन्ध दुवैको वर्णन गर्छ। कसैले यात्रा गर्नुअघि पुनःप्राप्ति प्रक्रियाको योजना बनाउनुहोस्, किनकि चिसो-बुट परीक्षण त्यो अभ्यास हुने एउटै ठाउँ हो।