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

इन चरणों को अलग रखना ही प्रोजेक्ट को ऐसे लैपटॉप पर खत्म होने से रोकता है जो सफलतापूर्वक जुड़ गया और जिसका उपयोग नहीं किया जा सकता।

कनेक्ट करने से पहले: संस्करण, स्थानीय प्रशासक, DNS

मशीन को ऐसा संस्करण चाहिए जो डोमेन जॉइन का समर्थन करता हो और एक स्थानीय प्रशासक जो इसे करने के लिए अधिकृत हो। VPN उसी सत्र में चालू होना चाहिए, क्योंकि जॉइन उसी सुरक्षा संदर्भ में चलता है जिसका आप उपयोग कर रहे हैं।

क्लाइंट को संगठन के डायरेक्टरी DNS पर इंगित करें, किसी सार्वजनिक रिज़ॉल्वर पर नहीं और hosts फ़ाइल की किसी प्रविष्टि पर नहीं। जॉइन को सेवा रिकॉर्ड खोजने होंगे और फिर उन रिकॉर्ड द्वारा नामित होस्ट तक पहुँचना होगा। पुराना सफ़िक्स या सार्वजनिक रिज़ॉल्वर खोज को पूरी तरह कहीं और भेज देते हैं।

घड़ी भी जाँचें। Kerberos समय के अंतर को सहन नहीं करता, और एक महीने ऑफ़लाइन रहा लैपटॉप भ्रमित करने वाली जॉइन त्रुटियों का आम स्रोत है।

पुष्टि करें कि डोमेन खोजा जा सकता है, केवल पिंग नहीं

जॉइन का प्रयास करने से पहले डोमेन का LDAP SRV रिकॉर्ड हल करें। ad.corp.example नाम के एक उदाहरण एक-डोमेन वातावरण के लिए, क्वेरी यह है:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

लौटाया गया रिकॉर्ड आवश्यक है पर्याप्त नहीं। इसके द्वारा सूचीबद्ध हर DC नाम हल करें और पुष्टि करें कि आप टनल के माध्यम से आवश्यक सेवाओं तक पहुँच सकते हैं। डोमेन नाम पर पिंग खोज के बारे में लगभग कुछ भी सिद्ध नहीं करता।

दस्तावेज़ित AD निर्भरताओं की अनुमति दें: प्रमाणीकरण, SMB और RPC ट्रैफ़िक, तथा समय सिंक। हर एक को उन फ़ायरवॉल नियमों के विरुद्ध जाँचें जो आपने वास्तव में तैनात किए। डोमेन कंट्रोलर के पोर्ट इंटरनेट पर प्रकाशित करना कोई ऐसा शॉर्टकट नहीं है जिस पर विचार करना उचित हो।

जॉइन चलाएँ और त्रुटि पढ़ें

समर्थित जॉइन कमांड या सिस्टम डायलॉग का उपयोग करें और सटीक त्रुटि पाठ कैप्चर करें। «निर्दिष्ट डोमेन या तो मौजूद नहीं है या उससे संपर्क नहीं किया जा सका» खोज या पहुँच की ओर संकेत करता है, क्रेडेंशियल की ओर नहीं।

यदि उसी नाम की कोई वस्तु पहले से मौजूद है, तो उसे प्रतिक्रियावश न हटाएँ। यह पूर्व-तैयार खाता हो सकता है, और netjoin कठोरता स्वामित्व और नीति के अनुसार कुछ पुनःउपयोग मामलों को सीमित करती है। डायरेक्टरी स्वामी से वस्तु की जाँच या सुधार करने को कहें।

सफल जॉइन मध्यबिंदु है, अंतिम रेखा नहीं। अगला कदम वही है जिसे उपयोगकर्ता वास्तव में परखता है।

पहले डोमेन साइन-इन की योजना बनाएँ

पूर्ण जॉइन हर डोमेन उपयोगकर्ता के लिए कैश किए गए क्रेडेंशियल नहीं बनाता। पहली साइन-इन स्क्रीन पर, किसी भी उपयोगकर्ता के लॉगिन से पहले लैपटॉप को DC तक पथ चाहिए। यदि आपका उपयोगकर्ता VPN साइन-इन के बाद ही शुरू होता है, तो वह पथ अनुपस्थित है। यह डिज़ाइन की कमी है, क्लाइंट की बग नहीं।

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

उपयोगकर्ता बदलना और VPN की दृढ़ता क्लाइंट के अनुसार भिन्न होती है। यह न मानें कि स्थानीय प्रशासक के रूप में शुरू किया गया कनेक्शन किसी दूसरे उपयोगकर्ता के सत्र में बना रहेगा।

स्थानीय पुनर्प्राप्ति पहुँच बनाए रखें

लैपटॉप सौंपने से पहले स्वीकृत स्थानीय पुनर्प्राप्ति पथ सुरक्षित रखें। यदि पहला डोमेन लॉगऑन विफल हो जाए, तो आपको वापस आने का ऐसा रास्ता चाहिए जो उसी टनल पर निर्भर न हो जो अभी विफल हुआ।

जो आपने सिद्ध किया उसे लिखें: SRV रिज़ॉल्यूशन, DC तक पहुँच, जॉइन त्रुटि, पहले लॉगऑन की विधि और पुनर्प्राप्ति खाता। वही रिकॉर्ड दोहराने योग्य बिल्ड और केवल कार्यालय में चलने वाले लैपटॉप के बीच का अंतर है।

संबंधित लेख