एक महीने ऑफ़लाइन रहने के बाद डोमेन ट्रस्ट विफल? पहले जाँचें

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

त्रुटि ट्रस्ट जैसी दिखती है, पर तीन स्थितियाँ एक जैसी लगती हैं

उपयोगकर्ता कैश किए गए डोमेन जानकारी से साइन इन कर सकता है, वर्कस्टेशन डोमेन नियंत्रक नहीं ढूँढ पा सकता, या सदस्य और डोमेन मशीन खाते पर सचमुच असहमत हो सकते हैं। केवल तीसरी स्थिति ही सख्त अर्थ में टूटा ट्रस्ट संबंध है।

AD प्रतिकृति स्वास्थ्य चौथा अवलोकन है, और यह इस वर्कस्टेशन से जुड़ा ही नहीं है। यह डोमेन नियंत्रकों के बीच सहमति बताता है, और स्वस्थ प्रतिकृति डैशबोर्ड यह सिद्ध नहीं करता कि इस मशीन का स्थानीय सीक्रेट उसके कंप्यूटर खाते से मेल खाता है।

परिचित 30 दिन का डिफ़ॉल्ट एक परिवर्तन नीति है, ऑफ़लाइन समाप्ति की समय-सीमा नहीं। Microsoft का मशीन-खाता पासवर्ड का स्पष्टीकरण एक समन्वित परिवर्तन प्रक्रिया बताता है, और कोई संगठन भिन्न अंतराल कॉन्फ़िगर कर सकता है।

VPN आइकन सुरक्षित चैनल के बारे में कुछ भी सिद्ध नहीं करता

किसी भी परीक्षण का अर्थ होने से पहले कनेक्टिविटी इतनी अच्छी होनी चाहिए कि डोमेन सेवाओं तक पहुँच सके। इसका अर्थ है इच्छित डोमेन DNS रिज़ॉल्वर, खोजा जा सकने वाला नियंत्रक, पहुँच योग्य प्रमाणीकरण सेवाएँ और Kerberos के लिए पर्याप्त निकट घड़ी।

पूर्ण टनलिंग यहाँ पूरी तरह वैध डिज़ाइन हो सकती है। विभाजित टनलिंग पर जाना स्वस्थ डोमेन संबंध की पूर्वशर्त नहीं है, और इसे पूर्वशर्त मानना निदान को वास्तुकला परिवर्तन में बदल देता है। जाँचें कि वर्कस्टेशन वास्तव में कौन-सा नियंत्रक चुनता है, और वह नाम त्रुटि के साथ रखें।

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

DNS सर्वर, हल किया गया नियंत्रक और त्रुटि का सटीक पाठ लिखें। कनेक्टेड बताने वाला VPN क्लाइंट कहता है कि सुरंग है, यह नहीं कि डोमेन पथ काम करता है। Kerberos पोर्ट पर उत्तर देने वाला पर निर्देशिका पोर्ट पर न देने वाला नियंत्रक फ़ायरवॉल का निष्कर्ष है, ट्रस्ट का नहीं।

सुधारने से पहले सदस्य का परीक्षण करें

अधिकृत Windows डोमेन सदस्य पर, Test-ComputerSecureChannel -Verbose मशीन और डोमेन के बीच चैनल की केवल-पढ़ने योग्य जाँच है। इसे उसी मशीन संदर्भ में चलाएँ जिसकी आप जाँच कर रहे हैं, डोमेन नियंत्रक से नहीं, जिसकी भूमिका और पुनर्प्राप्ति नियम अलग हैं। पास या फेल शब्द के बजाय आउटपुट और एक्ज़िट स्थिति सहेजें। यदि उस बिल्ड में cmdlet नहीं है, तो मॉड्यूल अलग समस्या है।

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

घटना के आसपास सदस्य पर और संबंधित नियंत्रक पर Netlogon घटनाओं को सहसंबंधित करें। मशीन का नाम, स्रोत पता, समय और खाता परिवर्तन का कोई भी प्रमाण सुरक्षित रखें। किसी अन्य उपयोगकर्ता का सफल लॉगिन, या स्वस्थ नियंत्रक डैशबोर्ड, इस मशीन के आदान-प्रदान का विकल्प नहीं बन सकता।

केवल उसी संबंध की मरम्मत करें जिसे आपने सिद्ध किया

एक बार कनेक्टिविटी स्थिर हो और प्रशासक पुष्टि कर दे कि मरम्मत उचित है, तो अधिकृत क्रेडेंशियल के साथ cmdlet का -Repair मोड सदस्य वर्कस्टेशन के लिए एक समर्थित कार्रवाई है। यह संबंध बदलता है, और यह केवल-पढ़ने वाला दूसरा परीक्षण नहीं है।

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

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

विफलता लौटने पर क्या जाँचें

यदि विफलता लौटती है, तो उसी खाते को फिर से रीसेट करने के बजाय रोलबैक, दोहरी पहचान और खाता परिवर्तनों के समय को देखें। बहाल की गई छवि, स्नैपशॉट, क्लोन की गई मशीन पहचान, या कहीं और किया गया कंप्यूटर-खाता रीसेट—सभी जाँच के योग्य हैं।

अस्थायी रूप से सफल रीसेट उपयोगी पुनर्प्राप्ति प्रमाण है, पर यह प्रमाण नहीं कि रुक-रुककर चलने वाले VPN ने मूल असंगति पैदा की। अगली घटना ही बताएगी कि कारण कभी हटाया गया या नहीं।

नियंत्रक, DNS सर्वर और परीक्षण आउटपुट टिकट में लिखें। यही रिकॉर्ड वास्तविक ट्रस्ट विफलता को उस लैपटॉप से अलग करता है जो सीधे डोमेन नहीं ढूँढ पाया।