पासवर्ड बदल एकाच वेळी सर्वत्र पोहोचतो, फक्त तो एक लॅपटॉप वगळून जो आठवडाभर ऑफलाइन होता. वेबमेल नवीन पासवर्ड स्वीकारते, कार्यालयातील डेस्कटॉपही तो स्वीकारतो, आणि 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

संख्या शून्य असल्यास, कॅशे लॉगऑन धोरणाने अक्षम आहे आणि पासवर्ड कितीही वेळा रीसेट केला तरी ऑफलाइन वर्तन बदलणार नाही. हा मालकासमवेत मांडायचा धोरण-निर्णय आहे, स्थानिक पातळीवर लागू करायचा कोणताही मार्ग नाही.

संबंधित लेख