एक महिना ऑफलाइन राहिल्यानंतर डोमेन ट्रस्ट अयशस्वी? आधी तपासा
सदस्य वर्कस्टेशन मशीन-पासवर्ड अंतरापलीकडे ऑफलाइन राहिले तरी ट्रस्ट गमावत नाही. खाते रीसेट करण्यापूर्वी सुरक्षित चॅनेल सिद्ध करा.
एक लॅपटॉप सहा आठवडे VPN बाहेर असतो, परत येतो, आणि वापरकर्ता डोमेन खात्याने लॉग इन करू शकत नाही. त्रुटी ट्रस्ट संबंधाचा उल्लेख करते, म्हणून कोणीतरी संगणक खाते रीसेट करते, किंवा वापरकर्त्याला पूर्ण टनेलिंगवर भाग पाडते, आणि समस्या दूर झाल्यासारखी वाटते. दोन्हीपैकी कोणत्याही कृतीने काय तुटले होते हे सिद्ध केले नाही. Windows सदस्य सामान्य मशीन-पासवर्ड अंतराच्या खूप पुढेही ऑफलाइन राहू शकतो आणि आपोआप ट्रस्ट गमावत नाही, म्हणून पहिले काम म्हणजे पोहोचण्याची अयशस्वीता आणि खऱ्या सीक्रेटची विसंगती वेगळी करणे.
त्रुटी ट्रस्टसारखी दिसते, पण तीन अवस्था एकसारख्या वाटतात
वापरकर्ता कॅशे केलेल्या डोमेन माहितीने साइन इन करू शकतो, वर्कस्टेशनला डोमेन कंट्रोलर सापडू शकत नाही, किंवा सदस्य आणि डोमेन संगणक खात्याबाबत खरोखर असहमत असू शकतात. कठोर अर्थाने तुटलेला ट्रस्ट संबंध फक्त तिसरा आहे.
AD प्रतिकृती आरोग्य हे चौथे निरीक्षण आहे, आणि त्याचा या वर्कस्टेशनशी काहीही संबंध नाही. ते डोमेन कंट्रोलरमधील सहमतीचे वर्णन करते, आणि निरोगी प्रतिकृती डॅशबोर्ड हे सिद्ध करत नाही की या मशीनचे स्थानिक सीक्रेट तिच्या संगणक खात्याशी जुळते.
परिचित 30 दिवसांचे डीफॉल्ट हे बदल धोरण आहे, ऑफलाइन कालबाह्यता मुदत नाही. Microsoft चे मशीन-खाते पासवर्डचे स्पष्टीकरण समन्वित बदल प्रक्रियेचे वर्णन करते, आणि संस्था वेगळा अंतराल कॉन्फिगर करू शकते.
VPN चिन्ह सुरक्षित चॅनेलबद्दल काहीही सिद्ध करत नाही
कोणतीही चाचणी अर्थपूर्ण होण्यापूर्वी कनेक्टिव्हिटी डोमेन सेवांपर्यंत पोहोचण्याइतकी चांगली असली पाहिजे. याचा अर्थ इच्छित डोमेन DNS रिझॉल्व्हर, शोधण्यायोग्य कंट्रोलर, पोहोचण्यायोग्य प्रमाणीकरण सेवा आणि Kerberos साठी पुरेशी जवळची घड्याळ.
पूर्ण टनेलिंग येथे पूर्णपणे वैध रचना असू शकते. विभाजित टनेलिंगवर जाणे निरोगी डोमेन संबंधाची पूर्वअट नाही, आणि ते पूर्वअट मानणे निदानाचे स्थापत्य बदलात रूपांतर करते. वर्कस्टेशन प्रत्यक्षात कोणता कंट्रोलर निवडते ते तपासा, आणि ते नाव त्रुटीसोबत ठेवा.
nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -VerboseDNS सर्व्हर, सोडवलेला कंट्रोलर आणि त्रुटीचा नेमका मजकूर नोंदवा. कनेक्टेड असल्याचे सांगणारा VPN क्लायंट टनेल अस्तित्वात आहे हे सांगतो, डोमेन मार्ग कार्यरत आहे हे नाही. Kerberos पोर्टवर उत्तर देणारा पण डिरेक्टरी पोर्टवर न देणारा कंट्रोलर फायरवॉलचा निष्कर्ष आहे, ट्रस्टचा नाही.
दुरुस्तीपूर्वी सदस्याची चाचणी करा
अधिकृत Windows डोमेन सदस्यावर, Test-ComputerSecureChannel -Verbose ही मशीन आणि डोमेनमधील चॅनेलची फक्त-वाचन तपासणी आहे. तुम्ही तपासत असलेल्या मशीनच्या संदर्भात ती चालवा, डोमेन कंट्रोलरवरून नाही, कारण त्याची भूमिका आणि पुनर्प्राप्ती नियम वेगळे आहेत. पास किंवा फेल शब्दाऐवजी आउटपुट आणि एक्झिट स्थिती नोंदवा. त्या बिल्डमध्ये cmdlet नसल्यास, मॉड्यूल वेगळी समस्या आहे.
निकालाला अजूनही संदर्भ लागतो. मशीन निवडलेल्या कंट्रोलरपर्यंत पोहोचू शकत नसेल किंवा तिथे प्रमाणीकरण करू शकत नसेल, तर अयशस्वी चाचणी ऑफलाइन पासवर्ड कालबाह्य झाल्याचा स्वतंत्र पुरावा नाही. प्रत्यक्ष त्रुटी आणि वापरलेला कंट्रोलर ठेवा, आणि मार्ग ज्ञात चांगला झाल्यावर चाचणी पुन्हा करा.
घटनेभोवतीच्या सदस्यावरील आणि संबंधित कंट्रोलरवरील Netlogon घटना एकमेकांशी जोडा. मशीनचे नाव, स्रोत पत्ता, वेळ आणि खाते बदलाचा कोणताही पुरावा जपून ठेवा. दुसऱ्या वापरकर्त्याचे यशस्वी लॉगिन, किंवा निरोगी कंट्रोलर डॅशबोर्ड, या मशीनच्या देवघेवीची जागा घेऊ शकत नाही.
तुम्ही सिद्ध केलेला संबंधच दुरुस्त करा
कनेक्टिव्हिटी स्थिर झाल्यावर आणि दुरुस्ती योग्य आहे असे प्रशासकाने पुष्टी केल्यावर, अधिकृत क्रेडेन्शियलसह cmdlet चा -Repair मोड हा सदस्य वर्कस्टेशनसाठी एक समर्थित ऑपरेशन आहे. तो संबंध बदलतो, आणि ती अजून एक फक्त-वाचन चाचणी नाही.
बदलापूर्वी मंजूर स्थानिक पुनर्प्राप्ती खाते आणि व्यवस्थापन मार्ग उपलब्ध ठेवा. डोमेन कंट्रोलरची पुनर्प्राप्ती भूमिका वेगळी आहे आणि ही प्रक्रिया त्यांना सामान्य वर्कस्टेशन मानू नये. अनेक रीसेट साधने क्रमाने चालवून त्यातील एक बरोबर असेल अशी अपेक्षा करण्याऐवजी संस्थेचा पुनर्प्राप्ती कार्यप्रवाह वापरा.
दुरुस्तीनंतर नवीन सुरक्षित-चॅनेल चाचणी आणि मूळ डोमेन ऑपरेशन सत्यापित करा. वापरकर्ता प्रोफाइल आणि अॅप्लिकेशन स्थिती जपून ठेवा, आणि काढून-पुन्हा-जोडणे ही पहिली अस्पष्ट कृती करू नका.
अयशस्वीता परत आल्यावर काय तपासावे
अयशस्वीता परत आली, तर तेच खाते पुन्हा रीसेट करण्याऐवजी रोलबॅक, दुहेरी ओळख आणि खाते बदलांची वेळ पाहा. पुनर्संचयित प्रतिमा, स्नॅपशॉट, क्लोन केलेली मशीन ओळख, किंवा दुसरीकडे केलेले संगणक-खाते रीसेट—सर्व तपासण्यायोग्य आहेत.
तात्पुरते यशस्वी रीसेट हा उपयुक्त पुनर्प्राप्ती पुरावा आहे, पण अधूनमधून येणाऱ्या VPN ने मूळ विसंगती केली हा पुरावा नाही. कारण कधीही दूर झाले का हे पुढील घटना सांगेल.
कंट्रोलर, DNS सर्व्हर आणि चाचणीचे आउटपुट तिकिटात लिहा. तोच नोंद खऱ्या ट्रस्ट अयशस्वीतेला डोमेन सापडू न शकलेल्या लॅपटॉपपासून वेगळा करतो.