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 जोडणी मार्गदर्शन व्यवस्थापित-डोमेन कार्यप्रवाहासाठी समर्थित पूर्वअटी सूचीबद्ध करते। ते वरच्या तीन निर्णयांसमोर वाचा, आणि कोणताही विसंगती टाळायचा तपशील नाही तर थांबण्याचे कारण माना।