Azure VM को Entra Domain Services से जोड़ना: पहले तय करें
जोड़ने से पहले तीन निर्णय हैं: वह निर्देशिका मॉडल जो वर्कलोड को चाहिए, डोमेन हल करने वाला निजी DNS, और प्रमाणित कर सकने वाला खाता।
Windows Server VM के सामने तीन निर्णय खड़े हैं जिसे प्रबंधित निर्देशिका का उपयोग करना है, और जोड़ने का आदेश उनमें सबसे छोटा है। गलत निर्देशिका मॉडल चुनें और जोड़ना सफल हो जाता है जबकि अनुप्रयोग अभी भी प्रमाणित नहीं कर सकता। नाम विभेदन गलत हो और विफलता ऐसी जगह दिखती है जो क्रेडेंशियल समस्या जैसी लगती है।
सर्वर को छूने से पहले मॉडल, विभेदन और खाता तय करें, फिर आदेश एक बार चलता है।
तीन जोड़ने में से आप वास्तव में कौन सा चाहते हैं
डिवाइस जोड़ना किसी मशीन को सशर्त पहुँच और एकल साइन-इन के लिए Microsoft Entra ID में पंजीकृत करता है, और यह वर्कलोड को स्थानीय शैली के डोमेन के लिए कोई Kerberos टिकट नहीं देता। पारंपरिक डोमेन जोड़ना किसी कंप्यूटर ऑब्जेक्ट को निर्देशिका में बाँधता है और उसे मशीन खाता, समूह नीति और डोमेन प्रमाणीकरण देता है। प्रबंधित डोमेन वह दूसरा मॉडल सेवा के रूप में देता है। नाम एक जैसे सुनाई देते हैं और परिणाम नहीं।
केवल अंतिम दो में सामान्य अर्थ में डोमेन नियंत्रक शामिल है, और केवल प्रबंधित विकल्प ही सर्वरों को आपकी पैच सूची से हटाता है।
निर्णय आमतौर पर वरीयता पर नहीं बल्कि अनुप्रयोग पर निर्भर करता है। जिस सॉफ़्टवेयर को LDAP बाइंड, SPN वाला सेवा खाता, या समूह नीति ऑब्जेक्ट चाहिए वह डोमेन मॉडल में आता है। जिस सॉफ़्टवेयर को केवल कॉर्पोरेट डिवाइस पर उपयोगकर्ता की पहचान जाननी है वह आमतौर पर नहीं आता।
| Model | What the server gets | Where it appears |
|---|---|---|
| Entra device join | Device identity and conditional access signals | Microsoft Entra ID |
| Managed domain join | Machine account, Kerberos, group policy | The managed directory |
| Self-hosted AD DS | The same, plus every controller you operate | Your own forest |
DNS पथ तय करता है कि जोड़ना पूरा हो सकता है या नहीं
डोमेन जोड़ना डोमेन के नियंत्रक रिकॉर्ड के लिए लोकेटर खोज से शुरू होता है, इसलिए कोई भी क्रेडेंशियल जाँचे जाने से पहले नाम विभेदन को काम करना होगा। VM को प्रबंधित डोमेन के निर्देशिका पतों की ओर इंगित करें, या तो वर्चुअल नेटवर्क की DNS सेटिंग्स के माध्यम से या ऐसे सशर्त फ़ॉरवर्डर के माध्यम से जो केवल वही नामस्थान वहाँ भेजता है। नामस्थान तक सीमित फ़ॉरवर्डर आमतौर पर सुरक्षित विकल्प है, क्योंकि यह VM के बाकी विभेदन को अछूता छोड़ता है।
केवल होस्टनाम नहीं, लोकेटर जाँचें। डोमेन नाम पर पिंग लगभग कुछ सिद्ध नहीं करता, जबकि डोमेन नियंत्रक रिकॉर्ड के लिए SRV क्वेरी या तो अपेक्षित लक्ष्य लौटाती है या तुरंत विफल होती है:
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53डोमेन नाम और दोनों पतों को अपने प्रबंधित डोमेन कॉन्फ़िगरेशन के मानों से बदलें; यहाँ की संख्याएँ उदाहरण हैं। यदि क्वेरी किसी दूसरे ज़ोन के उत्तर लौटाती है, तो VM ऐसा रिज़ॉल्वर उपयोग कर रहा है जो प्रबंधित नामस्थान को फ़ॉरवर्ड नहीं करता, और जोड़ने को कितनी भी बार दोहराएँ वह नहीं बदलेगा।
वर्कलोड को उस सबनेट से बाहर रखें जो प्रबंधित डोमेन अपने सेवा संसाधनों के लिए आरक्षित रखता है, और निर्देशिका पोर्ट निजी पथ पर रखें। उन पोर्टों का सार्वजनिक एक्सपोज़र कोई शॉर्टकट नहीं है; यह अलग जोखिम प्रोफ़ाइल वाला अलग डिज़ाइन है।
खाते की पात्रता मशीन से पहले जाँची जाती है
जो खाता जोड़ना करता है उसे लक्ष्य कंटेनर में कंप्यूटर ऑब्जेक्ट बनाने की अनुमति चाहिए, और उसे प्रबंधित डोमेन के विरुद्ध प्रमाणित कर सकना चाहिए। प्रबंधित डोमेन के अस्तित्व से पहले बनाया गया केवल-क्लाउड खाता उस पासवर्ड-व्युत्पन्न सामग्री से वंचित हो सकता है जो डोमेन को चाहिए, और पासवर्ड बदलने या रीसेट करने पर वह फिर बनती है। यही ब्यौरा जोड़ने की विफलताओं का एक वर्ग समझाता है जो पासवर्ड सही होने पर भी गलत पासवर्ड जैसी लगती हैं। रखरखाव विंडो खुलने से पहले डोमेन के विरुद्ध क्रेडेंशियल जाँचें।
सिंक किए गए हाइब्रिड खातों की अपनी पूर्व-शर्तें होती हैं जिन्हें दृश्य उपयोगकर्ता ऑब्जेक्ट अकेला पूरा नहीं करता। निर्देशिका में सूचीबद्ध होना उससे टिकट पाने में सक्षम होने के बराबर नहीं है, इसलिए खाते को रखरखाव विंडो के दौरान नहीं, उससे पहले जाँचें।
जोड़ने का अधिकार संकीर्ण रूप से सौंपें। एक नामांकन हो सके इसलिए हर भावी सर्वर उपयोगकर्ता को डोमेन प्रशासक सदस्यता देना अस्थायी समस्या के लिए स्थायी अनुदान है।
जोड़ना स्वयं एक ही आदेश है
मॉडल चुना गया, DNS उत्तर दे रहा है और खाता पात्र है, तो क्रिया सामान्य Windows क्रिया है। प्रॉम्प्ट पासवर्ड को स्क्रिप्ट और शेल इतिहास से बाहर रखता है:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThruइस रूप में आदेश मशीन को स्वयं पुनः आरंभ नहीं करता, इसलिए रीबूट रखरखाव योजना के अंतर्गत और रिकवरी पथ अभी उपलब्ध रहते हुए होता है। किसी दूसरे डोमेन से पहले ही जुड़े सर्वर को स्थानांतरण योजना चाहिए, पहले के ऊपर दूसरा जोड़ना नहीं।
जिस कंटेनर में कंप्यूटर ऑब्जेक्ट उतरा और जिस खाते ने उसे बनाया, उसे दर्ज करें। पुनर्निर्माण के बाद मशीन को फिर जोड़ना पड़े तब दोनों मायने रखते हैं, और बाद में सर्वर से कोई भी स्पष्ट नहीं होता।
सदस्यता क्या नहीं देती
डोमेन सदस्यता किसी को स्थानीय प्रशासक नहीं बनाती, और दूरस्थ डेस्कटॉप या फ़ाइल साझाकरण तक पहुँच नहीं देती। वे अधिकार अलग से कॉन्फ़िगर होते हैं, और प्रबंधित डोमेन पर वे उसके समर्थित प्रशासनिक दायरे में ही रहते हैं।
नेटवर्क पथ सेटअप चरण नहीं, चलती निर्भरता है। यदि निजी कनेक्शन गायब हो जाए, तो सर्वर कैश किए गए क्रेडेंशियल के साथ चलता रहता है जब तक किसी चीज़ को निर्देशिका की ज़रूरत न हो, और तब विफलता बदली हुई कॉन्फ़िगरेशन के बगल में नहीं, अनुप्रयोग लॉग में आती है।
Microsoft का Windows Server जोड़ने का मार्गदर्शन प्रबंधित-डोमेन वर्कफ़्लो के लिए समर्थित पूर्व-शर्तें सूचीबद्ध करता है। इसे ऊपर के तीन निर्णयों के सामने पढ़ें, और किसी भी असंगति को टालने की बात नहीं, रुकने का कारण मानें।