एक महिना अफलाइन पछि डोमेन ट्रस्ट असफल? पहिले जाँच गर्नुहोस्

एउटा ल्यापटप छ हप्ता 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 सर्भर र परीक्षणको आउटपुट टिकटमा लेख्नुहोस्। त्यही रेकर्डले वास्तविक ट्रस्ट असफलतालाई डोमेन भेट्टाउन नसकेको ल्यापटपबाट छुट्याउँछ।