डोमेन ल्यापटपले अफलाइन पुरानो पासवर्ड किन स्वीकार्छ

पासवर्ड परिवर्तन एकैचोटि सबै ठाउँमा पुग्छ, एक हप्ता अफलाइन रहेको त्यो एउटा ल्यापटप बाहेक। वेबमेलले नयाँ पासवर्ड स्वीकार गर्छ, कार्यालयको डेस्कटपले पनि स्वीकार गर्छ, र VPN बन्द हुँदा टाढाको मेसिनले अझै पुरानो पासवर्डले साइन इन गर्छ। यो दोस्रो पासवर्ड होइन र डाइरेक्टरीमा सिंक बग पनि होइन। यो क्यास गरिएको लगअन प्रमाणकले आफ्नो लागि बनाइएको काम गरिरहेको छ, र समाधान रिसेट होइन, क्रम हो।

ल्यापटपले क्यास गरिएको प्रमाणक जाँचिरहेको छ

डोमेनसँग जोडिएको Windows ले हालैका सफल अन्तरक्रियात्मक लगअनका लागि स्थानीय प्रमाणक राख्छ, ताकि कुनै पनि डोमेन कन्ट्रोलरले जवाफ नदिँदा मेसिन बुट हुन सकोस्। त्यो प्रमाणक त्यो लगअनको समयको पासवर्डबाट व्युत्पन्न हुन्छ। अन्यत्र पासवर्ड बदल्नाले डाइरेक्टरी अद्यावधिक हुन्छ, तर त्यसपछि त्यससँग कुरा नगरेको ल्यापटपको प्रतिलिपि अद्यावधिक हुँदैन।

त्यसैले पुरानो पासवर्ड कुनै पनि नयाँ डोमेन प्रमाणीकरणका लागि अवैध हुँदाहुँदै पनि स्थानीय सत्र खोल्न सक्छ। यी दुई फरक अवलोकन हुन्, र तिनलाई मिसाउँदा बारम्बार रिसेट गर्नुपर्छ।

अरू केही बदल्नु अघि वास्तवमा कुन प्रमाणहरू प्रयोग भइरहेका छन् पुष्टि गर्नुहोस्। Windows Hello PIN, Entra ID साइन-इन र परम्परागत डोमेन पासवर्ड छुट्टाछुट्टै संयन्त्र हुन्, र PIN विशेष गरी डोमेन पासवर्ड होइन, त्यसले त्यही डेस्कटप अनलक गरे पनि।

नेटवर्क प्रमाणीकरण अन्तरक्रियात्मक लगअन होइन

नयाँ पासवर्डले फाइल साझेदारी खोल्नु भनेको नेटवर्क मार्ग काम गर्छ भन्ने प्रमाण हो। तर यसले अन्तरक्रियात्मक लगअन क्यास रिफ्रेस गर्दैन, किनकि Windows ले नेटवर्क र अन्तरक्रियात्मक प्रमाणीकरणलाई छुट्टै अवस्था भएका छुट्टै कार्यहरू मान्छ।

प्रमाणक तब मात्र रिफ्रेस हुन्छ जब अन्तरक्रियात्मक लगअनले वास्तवमै डोमेन कन्ट्रोलरसँग सम्पर्क गर्छ; म्याप गरिएको ड्राइभ वा Outlook सङ्केतले त्यो गर्दैन।

यही भिन्नताले सामान्य गुनासो व्याख्या गर्छ: प्रयोगकर्ताले मेल पढ्न र इन्ट्रानेट खोल्न सक्छ, तर लक स्क्रिनले अझै पुरानो पासवर्ड माग्छ। साइन-इनपछि सुरु गरिएको VPN ले सुरुको लगअनमा किन मद्दत गर्न सक्दैन भन्ने पनि यसले व्याख्या गर्छ, किनकि निर्णय स्थानीय रूपमा भइसकेपछि मात्र सुरुङ आउँछ।

सही क्षणमा एक अनलाइन साइन-इन प्राप्त गर्नुहोस्

डोमेन पहुँचयोग्य हुँदा प्रयोगकर्ताले अन्तरक्रियात्मक रूपमा साइन इन गर्दा क्यास रिफ्रेस हुन्छ। टाढाको मेसिनका लागि यसको अर्थ प्रमाणको मूल्याङ्कन अघि नै सुरुङ हुनुपर्छ, डेस्कटप देखिएपछि होइन।

परिनियोजनले लगअन-पूर्व जडान वा यन्त्र सुरुङ समर्थन गर्छ कि जाँच्नुहोस्। ती यही समयका लागि बनाइएका हुन्, र प्रयोगकर्ता सुरुङ तिनको विकल्प होइन:

nltest /dsgetdc:corp.example
klist

यदि अन्त्य बिन्दुमा लगअन-पूर्व मार्ग छैन भने संस्थाले अभिलेख गरेको समर्थित पुनःप्राप्ति प्रक्रिया प्रयोग गर्नुहोस्। केही वातावरणले सुरुङ लक स्क्रिनमा खुला राखेर जडान, लक र अनलकको क्रम प्रयोग गर्छन्; अरूले यन्त्रलाई व्यवस्थित पुनःप्राप्ति चरणमा पठाउँछन्। क्लाइन्टसँग मिल्ने अनुसरण गर्नुहोस्, र त्यसमा भर पर्नु अघि सुरुङ लक स्क्रिन पार गर्छ भनी पुष्टि गर्नुहोस्।

फर्किने बाटो सुरक्षित गर्नुहोस्

टाढाको मेसिनबाट साइन आउट गर्नु अघि अर्को साइन-इनले डोमेनमा कसरी पुग्ने निर्णय गर्नुहोस्। सत्रसँगै खस्ने प्रयोगकर्ता सुरुङले तपाईंले भरोसा गरेको एक मात्र मार्ग हटाउन सक्छ, र त्यसपछि पुरानो वा नयाँ पासवर्डले लक स्क्रिन पार गर्न दिँदैन। विकल्पका रूपमा स्थानीय प्रशासनिक खाता वा ब्यान्ड बाहिरको कन्सोल राख्नुहोस्। पुनःप्राप्ति चरण प्रयोगकर्ताले साइन इन नगरी पुग्न सक्ने ठाउँमा लेख्नुहोस्।

समर्थनका लागि चार तथ्य सङ्कलन गर्नुहोस्: पासवर्ड कहाँ बदलियो, कुन प्रमाण अझै अफलाइन काम गर्छ, सुरुङबाट डोमेन कन्ट्रोलर पहुँचयोग्य छ कि छैन, र ल्यापटपले कुन साइन-इन विधि प्रयोग गर्छ।

यी चार पुरानो प्रमाणकलाई खाता लकआउट वा अस्वीकृत VPN साइन-इनबाट छुट्याउँछन्, जो टिकटमा उस्तै देखिन्छन् तर समाधान फरक छ। लक भएको खाताले नयाँ पासवर्ड अनलाइन पनि अस्वीकार गर्छ, त्यसैले क्यासलाई दोष दिनु अघि त्यो परीक्षण गर्नुहोस्।

एक अनलाइन साइन-इनले चक्र बन्द गर्नुहोस्

लक्ष्य भनेको डोमेन पहुँचयोग्य हुँदा एक समर्थित अन्तरक्रियात्मक साइन-इन, र त्यसपछि ज्ञात अफलाइन अवस्था हो। त्यही एक घटनाले प्रमाणक रिफ्रेस गर्छ र प्रत्येक यन्त्रमा पासवर्ड बदल्ने चक्र अन्त्य गर्छ।

त्यसपछि क्यास गरिएको लगअन सङ्ख्या र डोमेन कन्ट्रोलर खोजीद्वारा अवस्था प्रमाणित गर्नुहोस्:

reg query "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" /v CachedLogonsCount
nltest /sc_verify:corp.example

यदि सङ्ख्या शून्य छ भने, क्यास लगअन नीतिले अक्षम गरेको छ र पासवर्ड जतिपटक रिसेट गरे पनि अफलाइन व्यवहार बदलिँदैन। यो मालिकसँग उठाउनुपर्ने नीति निर्णय हो, स्थानीय रूपमा लागू गर्ने कुनै बाटो होइन।