तुम्ही पॉइंट-टू-साइट 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 पर्यंत पोहोच, सामील होण्याची त्रुटी, पहिल्या लॉगऑनची पद्धत आणि पुनर्प्राप्ती खाते। ती नोंदच पुनरावृत्तीय बिल्ड आणि केवळ कार्यालयात चालणारा लॅपटॉप यातील फरक आहे।

संबंधित लेख